Two years ago, we alerted our readers to two new ransomware variants: Samsam and Maktub Locker. Interestingly, both ransomware variants were “self-contained”—without the need to “call home” via a command and control server. “Maktub” reportedly translates into “it is written” or “it is fate.” But, the meaning of “Samsam” less certain. In certain languages, “Samsam” means “sharp” or “sword.”
There have been spikes of ransomware activity during the weeks of January 11th and 18th. (Interestingly, the ransomware attacks have been reported to occur on such dates and times as Wednesday, January 3rd (municipality victim in New Mexico), Thursday, January 11th at about 9:30PM (hospital victim by way of compromised vendor credentials from a hardware supplier; compromised Internet-accessible and enabled remote desktop protocol (“RDP”) server; “old” variant of Samsam) and another one that same day (another hospital victim) (both of these 1/11 events occurring in Indiana), and Thursday, January 18th at about 2AM (North Carolina; “new” variant of Samsam affecting an electronic health records (“EHR") vendor; incident response teams from Microsoft and Cisco have reportedly been providing assistance). In fact, the first Bitcoin wallet transaction (which is reportedly tied to the attackers) occurred on Christmas Day—namely, December 25, 2017. This Bitcoin wallet appears to be still active with transactions as recent as January 20, 2018. Over $300,000 has been gained over the course of four weeks. Traditionally, analysts have thought of such monetary gain to be the work of cybercriminals (perhaps even organized cybercriminals). But, is this smoke and mirrors? Many victims of the Samsam ransomware have been in the United States. Some reports indicate that victims are located in Canada and India as well. In terms of who may be behind the cyber-attack, some have attributed such attacks to threat actors in Eastern Europe—but, it is likely too early to determine who is actually behind these attacks.
A common theme, for at least some of these recent Samsam ransomware attacks, has been attributed to compromised vendor credentials. We, in the healthcare sector and in other sectors, have observed many cyber-attacks and compromises occur by way of this “style” of breach. Indeed, it has been over four-years since cybercriminals “discovered” that this technique as being a highly effective one. Thus, there could be a “window of opportunity” for the attacker who wants to compromise “equipment vendors” and other types of vendors who have “trusted access” to a healthcare provider or other entity (for example). As we highlighted in our recent comments to the NIST Cybersecurity Framework, supply chain risk management (and security and integrity) is something we all need to be more cognizant of. (But, do know that using stolen vendor credentials is just one way of “getting in.” Another way is by exploiting vulnerability vendor products and services. Running the exploit can be very quick and easy, by using automated exploitation tools or scripts in just a matter of minutes and you could be “in” the victim’s environment—potentially with elevated privileges (without the need to escalate). This is why it is very important to be vigilant about upgrading (or patching) your security solutions, as appropriate.)
The initial attack vector has not yet been determined by analysts. However, Samsam traditionally has been “manual” in that Samsam malware has been uploaded to compromised victim machines. Various analysts, however, have noted that remote desktop (“RDP”) and/or virtual network computing (“VNC”) servers have played some role in recent cyber-attacks involving the new Samsam variant. In addition, the new Samsam variant is said to be more obfuscated and thus less likely to be detected.
Yes, some recent Samsam victims have reported that they were affected by the “old” version of Samsam. Thus, one still needs to be cognizant of how the “old” Samsam has worked as well. A detailed analysis of this may be found here.
Some indicators of compromise may be found here. Information on preventing and mitigating ransomware attacks may be found here. As with all plans, tests, training, and exercises are all good practices to explore. Don’t wait until a nightmarish situation actually occurs to test your contingency (and other) plans. Remember to test your assumptions (as well as your backups). Make sure that the time to recover your data, too, is realistic for your organization. (And, if it is not, investigate alternate means for reliably and securely backing up your data.) Don’t put all of your eggs in one basket.
Of course not. Attackers can and do “stockpile” useful and effective exploits (and zero days as well). We have all kinds of malware which is being generated all of the time. It is not unusual for hospitals (and others) to be constantly under attack. We all need to be vigilant and appropriately (and proactively) manage risk.
Carefully consider whether you will pay the ransom. Generally speaking, some ransomware is not programmed with the decryption module (although, some are). Something else to know, too, is that you might not necessarily get your data back even if you do pay the ransom. (To be clear, some cases you may and in other cases you may not. There is no set “honor system.”) But, even if you do resort to paying the ransom, you might get an additional gift (or two) on your system—namely, additional malware on your system (e.g., backdoors for persistent access to your machine(s), courtesy of the attacker).
This is why it is good to know what is “normal” for your systems and networks and what is not. Are there any unusual processes running on your system? Are there unusual ports open? Odd IP addresses? Unusually high amounts of traffic? Obfuscated traffic? Etc. It pays dividends to be cognizant of what is normal (and not normal) for your systems and devices—including both information technology and operational technology assets. Last, but not least, do consider contacting law enforcement in your jurisdiction, as appropriate.