Evolution of SamSa Malware Suggests New Ransomware Tactics In Play

This post is also available in: 日本語 (Japanese)

Ransomware is often in the headlines as new families are discovered on an almost weekly basis. Historically, these families have shared one similarity – they have all been deployed by attackers casting a wide net and largely being victim-agnostic. In most cases, the adversaries have used phishing emails and exploit kits in a ‘spray and pray’ style tactic.

However, in recent months, a new trend seems to be emerging: targeted attacks where ransomware is deployed by threat actors after successfully gaining unauthorized access to an organization’s network. One malware family seen in such attacks is known as ‘SamSa’, ‘Samas’, ‘samsam’, or most recently, ‘MOKOPONI’. Reports on this malware family have previously been published by both Intel Security and Microsoft.

Palo Alto Networks has collected over 20 samples of this particular malware family, and we have identified over $70,000 USD in Bitcoin payments to the attacker (Cisco Talos yesterday reported this figure to be closer to $115,000 USD). This blog details the evolution of this malware family, which was first witnessed in December 2015, as well as provides various indicators of compromise (IOCs) that can be used by the security community.

How the Malware Is Installed

As reported by both Microsoft and Intel Security, the malware is installed in a very targeted manner and appears to be in use post-compromise. First, the attacker will gain unauthorized access to a victim network, then begin mapping out the network in order to move laterally and discover more potential victim hosts. Once the attacker has sufficiently found enough victim systems, SamSa is deployed manually, using common system administrator utilities, such as PSExec.

After deploying the malware on various victim hosts, it will be installed using a RSA public key that is generated specifically for that particular attack. Additionally, a batch script is deployed that is responsible for deleting volume shadow copies on the victim machine to prevent restoration of files, executing SamSa, and finally self-destructing after successful encryption.

Malware Details

With the exception of the earliest known samples of SamSa, the malware expects an RSA public key file to be provided manually as a command-line argument. This is quite different from other ransomware families that retrieve the public keys automatically from command and control servers. The initial samples of SamSa actually embedded the public RSA key within the malware itself. More information on these changes can be seen in the ‘SamSa Evolution’ section below. In the event a public key is not provided as a command-line argument, the malware will exit, which provides minimal contextual evidence when run in a sandbox environment.

Figure 1 SamSa code looking for RSA Public Key

The malware proceeds to create a directory that will subsequently be used to store a batch script that is responsible for removing the SamSa executable after it completes its operation.

The following folders have been identified over the 23 analyzed samples:

%APPDATA%\FontCachedManager
%APPDATA%\MacroReder
%APPDATA%\SystemAccountManager

These folders will eventually contain an embedded file that is dropped by the malware called either ‘selfdel.exe’ or ‘del.bat’, which is responsible for removing SamSa.

The malware then seeks out a number of files based on an embedded list of file extensions. Presumably for performance reasons, SamSa will ignore the Windows directory, paths containing ‘Reference Assemblies\\Microsoft’ and the recycle bin.

Figure 2 Malware ignoring certain directories

The number of file extensions changes slightly over the course of the malware’s evolution. It averages between 327 to 345 different file extensions.

After identified files are discovered, they are encrypted using the supplied RSA public key and have the ‘.encryptedRSA’ file extension appended to them.

Figure 3 SamSa encryption routine

The malware then writes a ‘HELP_DECRYPT_YOUR_FILES’ file with an extension of either .html or .txt. This file contains instructions on how the victim may recover their files.

Each sample has a unique bitcoin address where the victim must provide payment. Payments vary based on the victim. Some instances require the victim to pay per machine, while others require the organization to pay a lump sum. A breakdown of payments is shared later in this post.

SamSa Evolution

Since witnessing the first sample with a compile time of December 9, 2015, we’ve observed that the malware author has made a number of small changes to the code base. The oldest sample actually appears to be a test executable, where the author placed a number of obviously fake placeholders instead of actual data, as seen below:

Figure 4 Snippet of ransom page from initial test SamSa file

Only a day after this first executable was compiled, we saw the attacker create two unique samples with actual bitcoin addresses, blog addresses, and demands for 37 BTC and 50 BTC respectively.

Code Changes

As the malware continued to evolve, the author included simple code obfuscation routines, such as hex-encoding sensitive strings, adding underscores in variable and function names, and in some cases, inclusion of garbage code.

Figure 5 Code obfuscation added by the malware author

File Extension Changes

Initially, the malware authors included 344 file extensions. Starting in mid-December 2015, this number changed to eventually settle on 327 extensions. The following file types were added and removed during this transition:

Added:

'.kbx', '.php5', '.phtml', '.xml', '.tif', '.tib'

Removed:

'.vmsn', '.vmsd', '.gif', '.chm', '.nvram', '.vb', '.bin', '.cnf', '.vmem', '.cab', '.dat', '.log', '.vbs', '.data', '.js', '.jse', '.xls', '.vmdk', '.jin', '.vmx', '.vmxf', '.gz', '.conf'

Another change occurred in mid-February 2016, when the attacker added the ‘.xls’ file extension. Finally, starting in mid-March 2016, the following three extensions were added:

'.config', '.asmx', '.vb'

Figure 6 Number of file extensions in SamSa over time

Ransom Notice Changes

Over the course of SamSa’s lifetime, the ransom notice changed from a simple txt file to HTML files. These changes can be seen below:

Figure 7 Ransom page version 1

Figure 8 Ransom page version 2

Figure 9 Ransom page version 3

Domain Changes

Over the past four months, the attacker has changed hosting providers for the victim’s payment website. Initially, the attacker made pages using the anonymous ‘www.anonyme[.]com’ web service. Starting in January 2016, the attacker switched tactics to instead use web pages hosted by wordpress[.]com. Finally, starting in mid-February 2016, the anonymous TOR network was used to host these web pages.

Figure 10 SamSa domain changes over time

Bitcoin Demands

Unlike other ransomware families, the attacker behind SamSa will either demand a large lump sum for the decryption key for all infected machines in an organization, or will demand a smaller amount for each infected machine. Initially, in December 2015, the attacker favored a lump sum. In January 2016, the attacker changed tactics and instead asked for either 1 or 1.5 Bitcoin (BTC) per infected machine. Finally, since February 2016, the attacker appears to have returned to requesting a large sum of BTC. The breakdown can be seen below:

Internal Filename

Another curious development occurred in mid-March 2016, when the malware author changed the internal name of the malware from ‘samsam’, which is likely how the malware was originally named, to ‘MOKOPONI’. It’s unclear why this change was made. It is worth noting that all samples named ‘MOKOPONI’ have been observed using the same C2 address of ‘roe53ncs47yt564u[.]onion’ with unique URIs.

SamSa Attacker Profits Gained

By tracking the unique BTC addresses found within all of the collected samples, we were able to determine when victims made specific payments. The following table shows payments made to the various BTC wallets:

By adding up the paid amounts, we get a total of 166.422305 Bitcoin, which, based on the current Bitcoin exchange rate, amounts to roughly $70,000 USD made by the attacker since December 2015. (A report by Cisco Talos yesterday put this figure as high as $115,000 USD.)

The two payments of 40 BTC are particularly interesting, as they took place on February 3 and 5 respectively. These payments were made at roughly the same time that reports came out of the Hollywood Presbyterian Medical Center meeting demands for 40 BTC to ransomware that hit their organization. While evidence is circumstantial, it is possible that SamSa was directly responsible for this particular incident.

Another interesting piece of evidence comes in the form of public notes attached to the payments made to 1KwgwwWdoL9VFcg9VuCDGBiVZ2LNzGnrov. Specifically, the following notes are present for payments of 22 BTC and 18 BTC respectively:

Public Note: For HPMISDTJRTJBM1 and HPMGPS01
Public Note: For HPMISDTJRTJBM1 AND HPMGPS01 FOR ALL AFFECTED PC

Again, this is purely speculative, but it’s certainly possible that these strings are hostnames, and the ‘HPM’ characters may stand for Hollywood Presbyterian Medical.

Conclusion

Overall, SamSa has been a serious threat that has stayed under the radar until recently. The malware has been seen since December 2015, and is likely responsible for a number of large ransomware infections across organizations. While the malware itself is not terribly sophisticated, the tactics used by the attackers, such as the lack of command and control infrastructure, the ability to compromise external facing systems to gain unauthorized access, and movement towards more obfuscation, make SamSa a serious threat.

IOCs for SamSa collected by Palo Alto Networks can be found here.

Palo Alto Networks’ customers are protected from this threat in the following ways:

1. WildFire accurately identifies all SamSa malware samples as malicious.
2. Domains used by SamSa have been flagged as malicious in Threat Prevention.
3. AutoFocus users can view malware related to this attack using the SamSa