SamSam

SamSam ransomware is a custom infection used in targeted attacks, often deployed using a wide range of exploits or brute-force tactics. Attacks were made on targets via vulnerable JBoss host servers during a previous wave of SamSam attacks in 2016 and 2017.

In 2018, SamSam used either vulnerabilities in remote desktop protocols (RDP), Java-based web servers, or file transfer protocol (FTP) servers to gain access to the victims’ network or brute force against weak passwords to obtain an initial foothold.

A common thread tying all of these attacks together was the use of the word “sorry” in ransom notes, URLs, and even infected files. It’s made hundreds of thousands of dollars so far, and has caused no end of trouble in the US for cities like Atlanta.

All the files were encrypted with RSA-2048 encryption where RSA is an asymmetric cryptographic algorithm; you need one key for encryption and one key for decryption, so you need private key to recover your files. It’s not possible to recover your files without private key.

Here’s what a typical ransom splash screen looks like:

The ransom note is quite interesting, giving the option of randomly-selected file encryption (if you don’t pay the full amount). They’ll also unlock one file for free as a token of trust that they will give your files back after payment.

The SamSam group have been making waves since late 2015, causing trouble in 2016, and starting to regularly increase the cost of their ransom in 2017. Colorado and Atlanta have both had run-ins with SamSam in 2018.

SamSam has been around long enough for organizations to be able to deal with it effectively, but it’s still here, and still locking up machines in targeted attacks.

Hospitals, city municipalities, and many more from Indiana to New Mexico were all struck down by SamSam in varying degrees of severity. A hospital in Indiana, in particular, was reduced to working with pen and paper in stormy weather. They decided to pay the ransom and get systems back up and running, given the cost of the fix was more than the ransom. This is an organization that had backups in place, unlike many other ransomware victims. All the same, by attacking a service offering life-saving treatment to patients, staff were left with few options.

In February 2018, the Colorado Department of Transportation had to shut down 2,000 (non critical) systems as they, too, were hit by a SamSam outbreak. Bitcoin was once again what the hackers were after; the CDT (Center for Democracy and Technology) decided that they weren’t going to pay up, but restore their backups instead.

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 loader file. It is a .NET exe that looks in the current folder for the ransomware payload to decrypt.

Next the SET password line, which receives the password via command-line parameter..

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 batch 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.

Fig: The loader file 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 (Advanced Encryption Standard) 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[0], while Arg_4E_0 is the encrypted byte stream. It then initiates the decrypted file for execution.

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

SOURCE: https://malware.wikia.org/wiki/SamSam

SOURCE: https://blog.malwarebytes.com/cybercrime/2018/05/samsam-ransomware-need-know/

SOURCE: https://aves.co.za/msil-samas/