SamSam - The Evolution Continues Netting Over $325,000 in 4 Weeks

This post was written by Vitor Ventura


Talos has been working in conjunction with Cisco IR Services on what we believe to be a new variant of the SamSam ransomware. This ransomware has been observed across multiple industries including Government, Healthcare and ICS. These attacks do not appear to be highly targeted, and appear to be more opportunistic in nature.

Given SamSam’s victimology, its impacts are not just felt within the business world, they are also impacting people, especially if we consider the Healthcare sector. Non-urgent surgeries can always be rescheduled but if we take as an example patients where the medical history and former medical treatment are crucial the impact may be more severe. Furthermore, many critical life savings medical devices are now highly computerized. Ransomware can impact the operation of these devices making it very difficult for medical personnel to diagnose and treat patients leading to potentially life threatening situations. Equipment that might be needed in time-sensitive operations may be made unavailable due to the computer used to operate the equipment being unavailable.

The initial infection vector for these ongoing attacks is currently unknown and Talos is investigating this in order to identify it. The history of SamSam indicates that attackers may follow their previous modus operandi of exploiting a host and then laterally moving within their target environment to plant and later run the SamSam ransomware. Previously, we observed the adversaries attacking vulnerable JBoss hosts during a previous wave of SamSam attacks in 2016. Although the infection vector for the new variant is not yet confirmed, there is a possibility that compromised RDP/VNC servers have played a part in allowing the attackers to obtain an initial foothold.

There are no differences between the encryption mechanism used by this current SamSam variant compared to older versions. However, this time the adversaries have added some string obfuscation and improved the anti-analysis techniques used to make detection and analysis marginally more difficult.

This new variant is deployed using a loader which decrypts and executes an encrypted ransomware payload, this loader/payload model represents an improvement in the anti-forensic methods used by the malware. Samples containing this loader mechanism have been found as far back as October 2017. The wallet used by SamSam for this wave is shared by multiple infected victims as observed by monitoring the wallet at 1MddNhqRCJe825ywjdbjbAQpstWBpKHmFR. We are also able to confirm the first payment into this wallet was received on 25th December 2017 - a nice holiday gift for this adversary. This can be confirmed by observing the first wallet transaction found on the Bitcoin blockchain here. There is a possibility that other Bitcoin wallets are also used but currently Talos is currently unaware of any others.

Similar to the previous variants, we believe the deployment of this SamSam variant to be highly manual, meaning an adversary must take manual action in order to execute the malware. The symmetric encryption keys are randomly generated for each file. The Tor onion service and the Bitcoin wallet address are hardcoded into the payload whilst the public key is stored in an external file with the extension .keyxml.

Additionally, code analysis didn’t find any kind of automated mechanism for contacting the Tor Service address which means that the victim identification with the associated RSA private key must be done either manually or by another adversary tool.

Ransom note displayed by SamSam new variant

In most ransomware the attackers try to convince affected users that they have the ability to decrypt the data after the payment is made. SamSam is no different here and even displays a disclaimer as seen in the above screenshot, stating ‘we don’t want to damage our reliability’ and ‘we are honest’.

To this end SamSam adversaries offer free decryption of two files and an additional free key to decrypt one server. Once again SamSam actors show their ability to monitor and laterally move through the network by pointing out they will only provide a key if they believe the server is not an important piece of infrastructure. As with previous versions of SamSam they are advising that messaging the attackers can be performed via their site.

The "Runner"

The adversary has changed their deployment methodology and now they use a loader mechanism called “runner” to execute the payload. Upon execution, the loader will search for files with the extension .stubbin in its execution directory, this file contains the SamSam encrypted .NET Assembly payload. Upon reading the file, the loader decrypts the payload with the password supplied as the first argument and executes it, passing the remaining arguments.

The loader is a very simple .NET assembly with no obfuscation. Comparing both the Initialization Vector (IV) and the code structure it seems like it may have been derived from an example posted on the website.

As you can seen in the images below, the IV used for the Rijndael encryption is the same in both implementations (posted code in hexadecimal, reversed code in decimal due to decompiler implementation).

Posted code Reversed code

At the code level looking specifically at the function ‘Decrypt’, it is obvious that the code structure in the Codeproject source and the latest SamSam runner sample is the same (comments from the posted code were removed).

Encryption routine source code comparison

The Payload

Previous versions of SamSam put some effort into the obfuscation of the malware code by encrypting strings with AES. The new version also obfuscates functions, class names and strings, including the list of targeted file extensions, the help file contents and environment variables, this time using DES encryption with a fixed hard-coded key and the IV.

Once again, the adversary has put more effort into preventing the forensic recovery of the malware sample itself rather than only relying on the obfuscation the running malware code, which allowed us to reverse engineer this sample.

As mentioned before, the password to decrypt the payload is passed as a parameter to the loader, which reduces the chances of obtaining the payload for analysis.

Previous versions of SamSam had an equivalent method for making payload access difficult by launching a thread that would wait 1 second before deleting itself from the hard disk.

The comparison of the main encryption routines between the old and the new samples indicates that this version of SamSam is similar enough to have high confidence that it belongs to the same malware family.

Encryption Routine Comparison

While previous SamSam versions used the API call DriveInfo.GetDrives() to obtain the list of available drives, this new version has the drive letters hardcoded. After checking that a drive is ready it starts a search for targeted files on the non-blacklisted folder paths.

The new variant keeps the same list of targeted file extensions as some of the previous ones. It adds a few new entries to the list of paths not to encrypt, which includes user profiles “All Users”, “default” and the boot directory.

This is in tune with most ransomware which attempt to preserve the operability of the victim’s machine. If the machine operation is so damaged that the system cannot be booted then the victim will be unable to pay, whereas if they keep the machine able to function, with limited access to files/folders, then they have a greater chance of a victim paying for recovering their important files and documents.

Just like previous versions of SamSam the new version is especially careful to make sure that there is enough space on the current drive to create the encrypted document, thus avoiding any corruption that would lead to irrecoverable encryption.

Unlike most ransomware, SamSam does not delete Volume Shadow Copies and creates an encrypted version of the original file which is then deleted using the regular Windows API. Although unlikely, due to block overwriting, recovery of the original files from the versions of affected folders saved by the operating system may be possible.


In identifying the scope of this SamSam campaign, Talos analyzed the Bitcoin wallet addresses used by the attackers in each of these attacks. As of the time of this writing, the attackers have received approximately 30.4 BTC which equals $325,217.07. As previously mentioned, it is possible that the attackers are leveraging multiple bitcoin wallets, however Talos has not observed any other than the one listed here being used in these attacks.


As the specific initial threat vector is not known at this time, best practices should be implemented to minimize risk to organizations. Talos has outlined several best practices that should be considered in a previous blog related to defending against ransomware related threats. In accordance with best practices protocols like SMB or RDP should never be internet facing.




BTC Wallet


Tor onion service




Snort Rules: 45484-45486

AMP for Endpoints: Ensure the TETRA engine and ‘Command Line Capture’ are enabled and client is v6.05+

Article Link: