SamSam ransomware has been involved in some high profile attacks recently, and remains a somewhat elusive malware. In its time being active, SamSam has gone through a slight evolution, adding more features and alterations into the mix. These changes do not necessarily make the ransomware more dangerous, but they are added to make it just a bit more tricky to detect or track as it is constantly changing.
When comparing early samples to more recent samples, one thing remains constant: the ransomware payload (the code that actually does disk encryption) is run-time decrypted. This is the most distinguishing trait about this ransomware, the single feature that makes it unique. This encrypted payload scheme explains why it is extremely difficult to find a sample of the actual payload code.
The main differences between the new and old versions of SamSam (which we will cover moving forward) are simply:
- The modules used
- Their interactions with one another
Rather than covering the old version and then talking about the new one, we will go through the newer SamSam code, and draw some comparisons to the older versions so we can understand its evolution.
Recent SamSam analysis
SamSam’s attacks have five main components to it in order for the compromise to take place. Four of them are actual files, and the fifth is the direct human involvement aspect.
Component one is a batch file that contains some settings for the ransomware and is the only portion that the actor is actually executing manually. It runs a .NET exe, which eventually decrypts an encrypted stub file. The attacker executes the bat file on the compromised computer with a password as its command-line parameter. This is the password that gets passed down the chain until the .NET file uses it for decryption. On older versions, it seems that this bat file was not in the chain. The attacker possibly executed the .NET component directly.
Details on each portion below:
In this case, mswinupdate is the “runner,” as they call it here. Basically, the “runner” is the loader file. It is a .NET exe that looks in the current folder for the ransomware payload to decrypt.
Next, you see the SET password line, which receives the password via command-line parameter as we spoke about above.
This is the whole reason there is so much difficulty in getting an analysis on the main payload. This password is entered without the use of a file. We may have trouble reconstructing the full manual attack scenario because some files and logs are wiped afterward by the attacker. Because of this, the only way we can theoretically get the password is if it’s intercepted at the time of the attack.
Moving forward to the rest of the contents of the bat file, the remaining parameters are self-explanatory. The next line of interest executes the “runner” and then deletes itself, the runner, and the encryption DLL.
Above is component two, the “runner,” aka the payload decryptor and launcher. This file is not obfuscated and is quite simple in functionality. It searches directories for a file with an extension of .stubbin that will have been placed there by the attacker. The stubbin file is the encrypted ransomware. It immediately reads the bytes from the file and then deletes the file from the disk. The contents of the file are AES encrypted so even having the stubbin file does not help us in analysis unless we obtain the password manually entered by the attacker.
The stubbin file calls the assembly.Load function, which loads up a .NET file dynamically. The function receives a parameter, which is the output of the decryptor method. This means that it decrypts the stub file, turning it into a proper PE, and then loads it dynamically. The password turned in from the bat file is args, while Arg_4E_0 is the encrypted byte stream. It then initiates the decrypted file for execution.
On to component three. In the recent versions of SamSam, the decryption code is contained in a separate DLL, while in the older versions, it was all contained within the runner EXE. The older versions therefore had only three components, rather than four.
Here is a screenshot of the decryption code:
Throughout the program code you will see the following:
This is something that was also added in the recent version. These arrays are unused, perhaps just garbage code inserted for obfuscation or to throw off signatures.
And finally, component four, the contents of the encrypted malware payload, *.stubbin
The goal of SamSam: targeted attacks
In this analysis, we spoke a lot about the password and the fact that it was entered manually by the attacker. This is the most important point about this ransomware campaign. As analysts, without knowing the password, we cannot analyze the ransomware code. But what is more important to note is that we cannot even execute the ransomware on a victim or test machine. This means that only the author, (or someone who has intercepted the author’s password) can run this attack.
This is a major difference from the vast majority of ransomware, or even malware, out there. SamSam is not the type of ransomware that spreads like wildfire. In fact, this ransomware quite literally cannot spread automatically and naturally.
A victim who accidentally downloads and executes this malware will not be harmed at all because a password is required for the payload to run. It requires the human involvement of the creator, which means it was developed for a single purpose: targeted attacks. The author attacks victims he has specifically chosen. And this is what makes this ransomware so interesting. The author is not just after a quick buck; instead, he prefers to have his payload remain a secret so he can continue to take down only the people he chooses.
Researchers Dorka Palotay and Peter Mackenzie from Sophos Labs also covered SamSam in a recent paper, to see their take, check it out here.
Indicators of compromise