Samas ransomware (also known as “Samsam”) has been around since 2016. This ransomware has received a lot of attention, behind highly publicized incidents affecting Allscripts Software Company and the city of Atlanta.

Unlike other prevalent ransomware like WannaCry and NotPetya, Samas does not spread using traditional methods such as email exploit delivery or by attacking vulnerable computers directly. While Samas actors have been known to attack vulnerable JBoss hosts, they often break into exposed perimeter systems, brutally forcing RDP and successfully gaining access to machines with weak or shared local admin passwords. They then move laterally using captured administrative credentials.

Samas stands out for its persistence and lateral movement techniques, typically associated with non-ransomware campaigns, designed to exfiltrate data. Tracking bitcoin transactions reveals that this campaign was incredibly profitable, with many victims paying ransom without reporting the crime.

While Samas actors are clearly adaptable and ready to change tactics as needed, they managed to compromise their victims due to insufficient firewall and antivirus protection and the use of non-random local admin passwords.

Samas actors start by using disposable, low-reputation verification servers to look for RDP servers with weaknesses, such as those not behind network-level authentication (NLA) or a multi-factor authentication (MFA) gateway. They then forcefully force local administrator passwords from exposed RDP servers.

After gaining local admin access to an RDP server, Samas actors switch to a server that has a clean record with major reputation services and is often hosted by small commercial vendors. They use this new server for the rest of the attack to avoid attribution and the consequent disruption of their other operations.

Samas actors typically continue to use RDP, mapping or sharing local drives to insert their tools into the compromised environment and persist. From that starting position, they use credential-stealing tools like Mimikatz and raw memory capture, taking advantage of overprivileged service accounts, including those with domain administrator privileges.

During an attack, Samas actors typically gain access to multiple accounts, but do not use all of them. Actors may be intentionally setting aside these "backdoor" accounts to regain access after victims have paid the ransom and undertaken recovery efforts.

After securing privileged credentials, Samas actors scan the internal network for other machines, using commercially available tools such as Masscan or their own custom tools. They are known to eliminate additional backdoors, including SOCKS proxy tools. They also seem to take advantage of misconfigured SQL servers and have shown interest in compromising SQL Server Agent (sqlagent) service accounts.

By examining the service principal name (SPN) queries and server name lookups performed by actors, as well as the appearance of extracted data, actors appear to look for specific data before dropping their ransomware payload. They also often stay on the network for days or even weeks before deploying ransomware.

Deployment of the ransomware itself is done in phases. Microsoft researchers have discovered test files appearing on systems before the ransomware is dropped and launched, which often requires direct actor interaction. To ensure the ransomware payload is effective, actors clean backups using volume shadow copy utilities.

Microsoft researchers believe that there are multiple individuals behind the Samas campaign, mainly due to the variation in RDP unit mapping artifacts and attack behaviors during the different stages of the campaign. We saw the actor's activity between 12:00 and 18:00 UTC, possibly indicating his location.

Samas actors appear to be expanding and utilizing other ransomware technologies, including Gandcrab ransomware as a service and possibly Bitpaymer.

Mitigations
Apply these mitigations to reduce the impact of this threat. Check the recommendations card for the implementation status of monitored mitigations.

• Use Windows Defender Firewall and network firewall to prevent RPC and SMB communication between endpoints whenever possible. This limits lateral movement as well as other attacking activities.
• Secure internet-facing RDP services behind a multi-factor authentication (MFA) gateway. If you don't have an MFA gateway, enable network level authentication (NLA) and verify that the server machines have strong random local administrator passwords.
• Apply strong, random local admin passwords. Use tools like LAPS.
• Practice the principle of least privilege and maintain credential hygiene. Avoid using domain-wide and administrator-level service accounts.
• Monitor brute force attempts. Check for excessively failed authentication attempts (Windows Security Event ID 4625).
• Understand and control perimeter exposure. Samas attacks often start with machines that are not in the asset inventory but are still members of the primary Active Directory domain and often have corresponding local administrator passwords or service accounts with highly privileged domain credentials that log on to them.
• Enable cloud-delivered protection and automatic sample submission in Windows Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.