SamSam explained: Everything you need to know about this opportunistic group of threat actors
What is SamSam?
The first version of the SamSam (a.k.a. Samas or SamsamCrypt) ransomware was developed and released in late 2015 by a group of threat actors believed to reside in Eastern Europe.
The group itself is mostly a mystery, but the code it developed and the resulting pain from its usage isn't. SamSam is a serious threat to organizations of all sizes, and we've seen a spike in SamSam-related attacks this year.
Here's a breakdown of the malware and the group using it.
SamSam vs. other ransomware families
Most turnkey ransomware crews or authors don't really know who they're targeting. They spread their payloads (Locky, Cerber, Dharma, Spora) via drive-by downloads, direct downloads, or malicious emails, and if there's a successful infection, they'll ask for a fee to decrypt files, say $500-$1,000 in Bitcoin (BTC).
It's a numbers game for these criminals. Infect enough people and eventually someone will pay. Usually, one or two payments is enough to cover the entire cost of the campaign; the rest is pure profit.
The group behind SamSam is focused, which makes its brand of extortion more lethal on the network. SamSam isn't commodity ransomware. You can't find it on a criminal forum, and it isn't sold as a service. It's developed privately and updated frequently, in order to avoid antivirus detection and other endpoint defenses. This is why most victims are discouraged when they are infected, as none of their usual endpoint defenses are able to stop it.As Salted Hash previously reported, some ransomware authors and sellers are clearing upwards of $100,000 a year. But the SaaS model of ransomware is a cutthroat business, so most of the players in that game aren't making much from their efforts. The real money is in customization and private ransomware development. This is where SamSam stands out form the rest.
It should come as no surprise if proof emerges that the group behind SamSam monitors the web for mentions of their work, because as soon as one attack hits the press or security vendors publish a report (or update signatures) a new build of SamSam hits the streets.
Lately the group has targeted healthcare organizations, but they've also targeted governments, schools, and private businesses. In February, the Colorado Department of Transportation was infected twice in two weeks by SamSam, creating an administrative nightmare for the agency. [Note: After this story was written in early March, the group also targeted the City of Atlanta.]
An opportunistic approach to infection
"We see this group more as an opportunistic attack vector," explained Jeremy Koppen, principal consultant at Mandiant, a FireEye company.
When it comes to SamSam, opportunity doesn't knock, it scans and exploits.
Once they have a foothold on a system, the group will compromise a network and elevate privileges. The vulnerabilities targeted will depend on the victim, but if there is an exposed server or asset that's vulnerable, they'll hit it.
In 2015 and 2016, the compromise usually started with JBoss vulnerabilities. However, the group also targeted Microsoft's IIS, FTP vulnerabilities, and RDP (Remote Desktop Protocol) instances exposed to the public. Lately, the group has started to focus on single-factor external access such as RDP or VPN.
In the most recent string of healthcare attacks from the SamSam group — including Hancock Health and Allscripts — RDP was singled out as the likely point of entry onto the network.
In a statement, Hancock Health confirmed RDP as the initial point of entry. An administrative account created by a Hancock Health vendor was compromised by the SamSam group, which enabled it to pivot into the hospital's information systems.
When asked, Allscripts would not discuss how the SamSam group gained access to its environment. However, Allscripts customers use RDP to access services, and the company has login portals publicly exposed to the internet. Given the SamSam group's recent obsession with RDP, this is likely the avenue of attack.
Compromising the network
Early on, the SamSam group used JexBoss (an open source JBoss exploitation tool). In fact, they'll still use it if needed, but recent investigations have observeda wide range of applications used to compromise and conduct reconnaissance on a victim's network.
These observations confirm that SamSam attacks are manual, so someone is sitting behind a keyboard.
According to forensic experts who have worked casesinvolving SamSam, the group will use any or all of the following tools:
- Mimikatz – A tool to extract passwords, hash, PINs, and Kerberos tickets from memory
- reGeorg – A reverse proxy / web shell script
- PsExec – Used to launch interactive command prompts on remote systems
- PsInfo – Used to gather information about local or remote systems
- PaExec – An alternate, redistributable version of PsExec
- RDPWrap - Allows console and remote RDP sessions at the same time
- NLBrute – An exploit tool for public-facing RDP instances
- Impacket – A collection of Python classes that enable security teams to work with network protocols. (SamSam was observed using wmiexec.py in January of 2017.)
- CSVDE – An Active Directory tool, ships with Windows Server. Used to import or export entries from Lightweight Directory Access Protocol (LDAP); Active Directory; Active Directory Application Mode (ADAM); Active Directory Lightweight Directory Services (ADLDS); and Active Directory Domain Services (ADDS)
- PowerSploit – A collection of PowerShell scripts used for reconnaissance and persistence
The reconnaissance phase also includes testing to ensure control. One investigator discovered that a simple file — text.txt — was written on systems throughout the victim's environment.
Pay up, or hope your backups work
Once the network is compromised, the SamSam group will launch the ransomware. Just before that happens though, the group will determine a ransom price that's commensurate with the level and volume of data they're going to encrypt and the victim's ability to pay.
A victim who doesn't appear to be able to pay high amounts will be presented with a smaller ransom. But a large company, such as Allscripts, will need to pay considerably more.
"Originally, we saw a group that charged roughly 1 BTC per infected system, but that's also back in that late 2015 time period, where Bitcoin was obviously less valuable. I think recently, we've seen about 0.7 BTC [per system], so it's dropped a little bit, and a higher Bitcoin value to decrypt all systems. A recent one we saw was 3 BTC to decrypt all systems," Koppen said.
By pricing the ransom at an affordable level (as well as targeting critical systems and forcing a halt to operations), the SamSam group is encouraging payment, especially if the cost of recovery is higher than the ransom.
This is exactly what happened with Hancock Health in Greenfield, Indiana. When the hospital was infected with SamSam earlier this year, they opted to pay the ransom demand in order to restore operations quickly.
Examining one of the Bitcoin wallets used by the SamSam group and comparing the transaction data to the public reports of Hancock Health's payment, you can see the hospital's record.
Hancock Health paid the ransomat 2:31 a.m. on Saturday, January 13, 2018; within two hours its systems were restored. In all, it paid 4 BTC, or $56,707.40, based on the price of Bitcoin at the time. News reports pegged the payment at $55,000 even.
In an interview with local media, Hancock CEO Steve Long said those responsible for infecting his network made it easy to pay, adding "they price it right."
The SamSam group's wallet also shows two other payments, one for 4 BTC and another for 5 BTC, made on January 19, 2018.
This is around the time Allscripts was recovering from its attack.
Did Allscripts pay the ransom in order to speed up the recovery effort?
Salted Hash asked the company for details, but Allscripts declined to answer. In a statement, a company spokesman cited security reasons and said, "we cannot provide additional information about our specific recovery efforts."
If the company did pay, it isn't clear if the payment helped at all. As previously reported, some Allscripts customers were without access for at least a week in most cases, longer in others. If the payments are unrelated to Allscripts, then there are two additional SamSam victims in Q1 2018 that the public doesn't know about.]
Stopping SamSam and others like it
If the SamSam crew is successful in its efforts to encrypt your systems, your problems started long before any ransomware infection. As mentioned, the crew behind SamSam is opportunistic when it comes to victims, looking for easily exploited systems and services. Once it finds them, the clock starts ticking.
It isn't an easy task to stop dedicated attackers like the SamSam group, and while the processes below will certainly help, they'll require a certain amount of dedication on your part. For groups like this, a "set it and forget it" mentality simply will not do.
Detection:
The first step, according to many incident response professionals Salted Hash spoke with is detection. It isn't easy, but the quicker you can detect a problem and react to it, the better off you are. It took Allscripts four hours to detect SamSam and declare a ransomware event and start the incident response process. Can you do it faster?
Being able to spot anomalies like the use of common administration tools like PsExec by users who have no reason to use such things will aid in quicker detection. The challenge, though, with anomalous behavior detection is the fact that the SamSam group will often use whitelisted tools and valid credentials in order to avoid tripping any alarms.
Patch management:
Exploiting vulnerabilities in FTP software, Microsoft's IIS, Windows Server, JBoss and more, the SamSam crew has proven it isn't too picky when it comes to the initial point of entry. Having a solid patch management program and working towards shortening the time between a patch's release and its deployment into the production environment will go a long way towards hurting the SamSam crew's efforts.
AV and other endpoint protections:
Don't ignore endpoint defenses; they're still a vital layer to your organization's overall security posture. Make sure you're taking advantage of all the features in the software, including cloud-based protections, as long as they make sense to your organization. But at the same time, don't count AV and other endpoint defenses to consistently stop groups like SamSam. They're not a silver bullet.
As mentioned, the group behind SamSam constantly updates its ransomware to avoid endpoint defenses. The group also takes the necessary steps to circumvent those defenses during the network compromise or reconnaissance phase of the attack.
Least privilege:
This is key. Keeping users on the least privileged level for their account not only limits the hijinks the SamSam crew will get up to, but helps lower the impact for almost any other attack against the organization. If a user requires administrator access, it should be stressed that it only be used as needed, and such access should always be monitored.
Authentication:
Using multifactor authentication, particularly for VPN and remote services, is key. Single-factor authentication paths have been hard hit by the SamSam crew, but aside from the risk on that front, using multiple layers of authentication just makes sense and should be encouraged when possible.
Access controls:
The Department of Justice, in their guidance on ransomware, stresses configuring access controls with least privilege in mind. Such controls include file, directory, and network share permissions, with a focus on restricting write access to identified files, directories, and shares.
Likewise, implementing Software Restriction Policies to prevent execution in temporary folders is also a smart move. Whitelisting, too, is a strong recommendation.
Limited functionality:
Limiting the functionality of systems to only the essentials needed for core operations is another step that helps throttle the actions of the SamSam group and others like it. If SMB isn't needed, disable it. The same can be said for RDP and other network services.
Editor's note: This is the third story in our series on the Allscripts ransomware attack. Monday we published a timeline of the attack and lessons learned. Tuesday we followed with a look at the customer impact when a SaaS provider is hit with ransomware. Tomorrow's final installment in the series will look at where organizations go wrong with incident response.
Comments