Wednesday, June 21, 2017

Analysis of .Net malware: ransomware SamSam

SamSam is a ransomware that is written in C#. It’s not an interesting malware, it hasn’t new interesting features or tricks to comment, however I wanted to write a post about the tools that I use to analyze .Net malware since long time ago, and this was a good opportunity to do it.

Deobfuscating .Net executable

All the .Net malware that I have analyzed they were obfuscated. The first step to analyze a .Net malware it’s to deobfuscate it. The best tool that i know for this purpose it’s de4dot:

de4dot.exe <path to .Net executable>

It will leave other executable in the same directory of the target executable with the additional extension .clean.

Decompiling .Net executable

In the case of .Net malware it’s much easier to decompile the executable with specific tools than reading MSIL code with a disassembler like IDA.


IlSpy it’s a .Net decompiler that works fine.

JetBrains dotPeek

Other good decompiler. It’s slower, but you can generate a visual studio project with the decompiled sources.

Debugging .Net executables

Dotnet IL Editor

Dile it is an editor and MSIL debugger for .Net. Working with it I found it usually crashes suddenly. Anyway there are not too much debuggers and it works well.

Analyzing SamSam ransomware

Using the tools that we have commented in the previous sections we are going to analyze a sample of SamSam ransoware: bda230a18d42aabca4b6b9ccdd62dedd.

After deobfuscating and decompiling it with IlSpy we can start to explore the code easily.

Encrypted strings

The most important strings used by the ransomware are encrypted with AES and key SALT.

They are decrypted with the key “SALT” and the algorithm in the function myff11:

With Jetbrains dotPeek it is easy to create a visual studio project and compile the code of the ransom. In this way we can leave it to decrypt the strings and see easily the decrypted content of these strings. Here you can find a compilable visual studio project:


(I have renamed the original Main function to MainOriginal and i added a empty Main. If you want to debug the full behaviour of the ransom you should call MainOriginal).

We compile the code and we can debug the code that we are interested on, and we can see the content of decrypted variables. For example here we can see the list of extensions that malware will encrypt:

Interesting info in the encrypted strings

Extensions list





















.design,.dgc,.djvu,.dng,.db,.db-journal,.db3,.dcr,.dcs,.ddd,.dbf,.dbx,.dc2,.pbl, .sql,.mdf

Rescue html message

Here you can find the content of the html message:


File encryption

The encryption of files is done with the function encc.myff1 and encc.EncryptFile.

It will write the encrypted contents to a file with <originalname> + “.breeding123” extension:

After encrypting a file, it will delete the original file, leaving the encrypted one. However i can’t see a point of the malware calling vssadmin or bcdedit, or cleaning removed file sectors. So it could be possible to recover file contents or a part of them. But i have not tested it.

It creates a random key for encrypting file content with AES. After that it encrypts the AES key with a public RSA that the malware carries with itself. Finally, it writes the encrypted content with a header containing the encrypted AES key to the .breeding123 file.


No comments:

Post a Comment