Home Renewal Samsam Ransomware Analysis

Samsam Ransomware Analysis


An In-Depth Analysis of Samsam Ransomware and BOSS SPIDER


This analysis gives an in-depth look at the Samsam ransomware. It is created and operated by CrowdStrike(r), Falcon Intelligence(TM), as BOSS SPIDER. This write-up explains how the infection chain and execution flow differ depending on the variant of malware. To aid in ransomware propagation and cleanup, the malware uses external tools like batch scripts, Mimikatz, and Sysinternals utilities including PsExec, Sdelete, and Mimikatz. Sometimes, ransomware is delivered encrypted with a runner file. This is used to load the malware and execute it in memory. The ransomware also has anti-forensics capabilities, making it difficult to recover the ransomware payment from infected systems. Falcon Prevent can detect the malware and stop it from encrypting any files.

Infection Process

There have been many variations of ransomware delivery methods that have been observed in the wild. An earlier version of ransomware required credentials to Active Directory through a credential dumper like Mimikatz. This generated public RSA keys and deployed the payload with the following files.

  • PSExec is a legitimate utility that is part Sysinternals suite and can be used to execute remote applications
  • Backup-Delete File: This file lists all drives that are connected to the victim’s machine. A detailed analysis is provided in the BackupDelete Helper File subsection
  • Here’s a list of compromised accounts
  • A folder containing unique RSA keys public keys for each account
  • There are four batch scripts responsible for copying files to victims’ computers and loading the payload.
    • First file: copies the Samsam payload along with the public key to %WINDIR%system32. Issues the command “vssadmin delete shadows /all /quiet
    • Second file: Copy the backup-delete file to C: Windows
    • Third file: Uses psexec remotely to execute the delete helper files
    • The fourth file Uses psexec remotely to execute the payload. Provides the public key to the payload.

The payload does not contain the public key or the backup deletion commands, as shown above. Other Samsam variants include both the key command and the backup deletions command embedded in the payload. The delivery mechanism in these cases is different from the one above. Instead of deploying the payload with multiple files, the payload can be encrypted and deployed using a runner and batch script.

  • Runner File: Responsible for loading and decrypting the payload. A detailed analysis can be found in the Runner File subsection.
  • Batch script: Loads the runner file, and gives the following arguments(It is important to note that the ransomware variant can have a different number of arguments. So far, we have seen up to four arguments.
    • : Used to decrypt encrypted payload
    • : Used by the decrypted payment load to drop additional files
    • : Used by the decrypted payment load to dynamically generate splash screens
    • : Used by the decrypted payment load to dynamically generate splash screens

Other cases have seen standalone Samsam payloads without any helper files or arguments.

There are many ways that the payload can arrive at a system. The payload and some of these helper files will be described in detail in the sections that follow.

Technical Analysis

Backup-Delete Helper File

This file is responsible to traverse the file system of a victim’s computer and target specific file extensions that are associated with data backup. These extensions are listed in appendix A: Targeted Extensions of Backup. This program is designed to make sure that no backups are available for file restoration after encrypted files have been deleted. It is important to note that the helper file will delete any files from connected shared drives.

This file is loaded by the batch script and recursively lists all directories on the victim’s drive. If the string “is present in a directory name, it will be recursively e numerated. Backup“The program will list all files in the directory and perform the following actions.

  • Set the file attributes to FILE_ATTRIBUTE_NORMAL. This will ensure that the file can be deleted easily without throwing an exception.
  • Once the file attribute has been set, delete each file.
  • After all, files have been deleted from the computer, you can delete the directory.

The program can also delete files from other directories by performing the following actions once it has found a target file:

  • Verify that the file has not been locked. Also, ensure that the file is not being accessed by any process. If this check passes, you can delete the file.
  • If the above-mentioned check fails, then the program terminates the associated process.
    • The following command is used to invoke tasklist.exe and generate a list of all running processes on the system. tasklist /v /fo CSV.
    • It will list all processes in the list and attempt to locate the one with the same file name. It invokes taskkill.exe to kill it if it is found. Taskkill /f/pid.
  • After the process is finished, the file associated with it will be deleted.

Here is a small sample of the output from the tasklist command.

Figure 1 – Output of tasklist command

Runner File

The runner file decrypts and loads the payload into memory. This file needs a password to be used in the encryption process. After the batch script has been loaded, the runner searches for files with the extension “.stubbin” in the current working directory. This file contains the actual encrypted payload. Once it is located, the runner reads its contents in memory and immediately deletes the encrypted. stubbing file. It is difficult to recover ransomware payload encrypted in memory because it is decrypted.

After the content has been read, the Rijndael algorithm is used to decrypt it. To generate an IV and decryption key, the algorithm needs the password and salt. This algorithm uses the salt value “Ivan Medvedev”, which can be seen in many binaries, both benign and malicious. These two inputs allow the runner to generate a 32-byte key and a 16-byte IV which can be used to decrypt the payload. Important to remember that additional arguments passed from the batch file are passed to the encrypted payload. The runner file then invokes the payload’s entry point and executes it in memory.


There were many variants of the payload that were analyzed. One of the most significant differences was whether or not the RSA public keys were embedded in the payload. As we mentioned, the batch script that loads the payload sends the public key to it as an argument. This is then converted to a variable that can be used later in execution. This section will detail the ransomware’s steps to encrypt files on victim machines.

Extracting Resources

Samsam extracts resource names from the loaded resource section. It checks for each name to ensure that it has the extension “.exe” and then looks for a file in the current directory with the same name. It will delete the file from the disk and read the contents of the resource section in chunks measuring 4096 bytes. If it does, it will write it to the current directory. This extraction has resulted in the detection of two files: selfdel.exe, and del.exe. This activity of dropping two files into the current directory with a static name can be used to detect the activity early in the kill chain.

After the files are written to disk, the payload starts a new thread that executes selfdel.exe. This is further explained in the Cleanup section. The payload will then recursively list all directories on each drive that is connected to the victim’s computer.

Enumeration of File Systems

When enumerating files, the payload ensures that these directories are not skipped:

  • C: Windows
  • Reference Assemblies\Microsoft
  • Recycle.bin

This is necessary to ensure smooth execution. Since system files reside in C:\Windows, and files necessary for the .NET framework are in Reference Assemblies\Microsoft, those files must be left intact. The reason you might not want to delete files in the Recycle.bin directory could be because it is often among the first to be enumerated and used by ransomware families. Several security solutions rely on this behavior to detect and stop ransomware early in the execution process. Samsam can bypass that directory and continue to encrypt files by skipping it.

Samsam’s list of file extensions is listed hereAppendix A: Targeted Extensions. If a file that matches one of these extensions is found, the payload immediately calls the encryption subroutine if it is less than 100MB (104857600 bytes). If the file is larger, however, the following steps are taken:

  • It adds the file’s path to the list if the file is larger than 100MB or less than 250MB.mylist250
  • It adds the file’s path to the list if the file is larger than 250MB or less than 500MB.mylist500
  • It adds the file’s path to the list if the file is larger than 500MB or less than 1GB.mylist1000
  • It adds the file’s full path and file size to the list if it is larger than 1GB.mylistbig.

Once all files with a size less than 100MB are encrypted, the payload encrypts them. This is done to make sure that all files are encrypted in the event of ransomware. The encryption subroutine is called from these lists in the order of file size. Files in the in-between are not encrypted.mylist250They are encrypted first, then followed bymylist500And so on. After each file in a list is encrypted, the payload clears it in memory.

This behavior of categorizing files by size is absent in other versions of Samsam. These variants use only one list to compile a complete list of files on all drives that are connected to the victim machine. The file encryption subroutine will be invoked next to encrypt target files.

File encryption wrapper

The following checks are performed on each file by the payload:

  • The file’s length is greater than the free space on the drive. If the check fails the payload will move on to the next file. This is done to make sure that enough space is available to write the encrypted file onto the disk.
  • The current file’s length is greater than 0.
  • The public key variable does not contain NULL. The public key variable is not NULL. Without it, encryption wouldn’t take place.

If any of these checks fails, the payload is moved to the next file.

Next, two variations are observed in how encryption occurs; these depend upon the version of Samsam that is running on the system.

Variation A

The subroutine checks for each file to see if it has the name…The current directory already contains the value of the encrypted extension. “The encrypted extensions value has always been “.encryptedRSA“. The following steps will be taken if you are positive:

  • Verifies the file’s length. The subroutine will delete the target file if it is larger than the target one and move on to the next. The program assumes that the file is already encrypted with Samsam, and deletes the target file.
  • The subroutine will delete the. encrypted RSA files whose size is less or equal to that of the target file. The actual encryption will result in the file size being larger than the original. Therefore, the. encrypted RSA must be larger than the target file. It assumes that the file. encrypted RSA is not the encrypted file and removes it from the disk. The target file will be encrypted once the. encrypted RSA files are deleted.
Variation B

If the subroutine locates a file with the name skips the target file immediately by typing. encrypted RSA The file’s length is not checked and there is no attempt to delete it. Important to remember is that the subroutine will move onto the next file and leave the target file unchanged. This is a serious oversight by the malware author. It implies that any files with the extension. encrypted RSA would be encrypted, even if they were of different lengths. The ransomware will simply skip over any file and assume that all files are encrypted. This was confirmed by analysis.

File encryption

Samsam uses the AES standard for encryption. It generates a random 64-byte signature key for each file, as well as a 16-byte key and a 16-byte IV. It can also create an empty file.encrypted RSA, to which it writes 3072 NULL bits. This is used as a placeholder to store the encrypted file header, which will be generated later in the execution process. Utilizing Restart Manager APIs, the payload determines whether there are currently running processes or services that have an open handle to the target file. These are the details of the steps:

  • Invoke to create a new session manager.RmStartSessionThis is a session handle for the new session.
  • This handle is used byRmRegisterResourcesRegister the target file to be used as a resource in the new session.
  • The handle can then be used byRmGetListTo see a list (target file) of current processes using the resource in question,
  • The session manager has been terminatedRmEndSession.
  • Each process ID is added to the file. This file then gets passed to a subroutine that kills those processes.

After the target file handle has been freed from all processes, the encryption subroutine will read its contents in memory buffer chunks of 10KB (10240 bytes) each. The subroutine then uses AES in CBC to encrypt the buffer’s contents. These are then written to the. encrypted RSA files starting at the 3073rd-byte position after the header placeholder. The file header is created once the file content has been encrypted.

Save Header

This randomly generated signature key is used for generating a Hash-based message authentication code (HMAC), a hash of encrypted content. This value, called inArray, is encoded using base64 and then written to the file head. Here is the structure for the file header.

  • Contains the random 16-byte key generated with the RSA Public Key and encrypted using base64.
  • The random generated 16-byte IV is encrypted and encoded in this way:
  • : includes the aforesaid inArray
  • The random generated 64-byte signature key is encrypted and encoded in this way:
  • The file size of the original target files is contained in :

The RSA private key that corresponds to the file header would decrypt each value and, in turn, would decrypt the contents of the file. Here is an example file header from a file encrypted using Samsam.

Figure 2 – File header for a file encrypted using Samsam

After the file has been encrypted, it is deleted from the disk.

After Encryption

Once each file is encrypted, the payload will drop an executable file calledHELP_DECRYPT_YOUR_FILESIn the current directory. Figure 3 shows the contents of the file.

Figure 3 – Ransomware note

In some instances, HELP_DECRYPT_YOUR_FILES.html with the same contents is dropped in the current directory. The ransomware note for each file encrypted is dropped in every variant of Samsam. This is odd behavior. Multiple copies of the ransomware note can be dropped in directories that contain multiple encrypted files.


As we have already mentioned, the payload extracts two executables from the resource section. These executables are then written to the current directory. These are the properties of each file:

Do not forget to saveSelfdel.exe
MD5: 710A45E007502B8F42A27EE05DCD2FBA
SHA256: 32445C921079AA3E26A376D70EF6550BAFEB1F6B0B7037EF152553BB5DAD116F
Compilation: Wed, Dec 2 2015, 22:24:42 – 32 Bit .NET AnyCPU EXE

Do not forget to save: del.exe
Size: 155736
MD5: E189B5CE11618BB7880E9B09D53A588F
SHA256: 97D27E1225B472A63C88AC9CFB813019B72598B9DD2D70FE93F324F7D034FB95
CompilationSat, January 14, 2012, 23.06:53 – 32 bit EXE
Version: 1.61
SubjectMicrosoft Corporation
IssuerMicrosoft Code Signing PCA
InternalName: sdelete
ProductNameSysinternal Sdelete

The legitimate Sysinternals utility file del.exe can be used to delete files from your hard drive. The payload invokes the file selfdel.exe in a new thread. It first checks that the process samsa.exe has stopped execution. It will exit immediately if it is not. The file then waits for three seconds before issuing the following command.del.exe –p 16 samsam.exe. This invokes del.exe, which can be used to delete samsam.exe. The MFT table simply marks a file as deleted, and the clusters that were assigned to it are freed up. These clusters would still contain the file contents. The utility overwrites these clusters to overcome this problem.-p 16. An argument ensures that 16 clusters are overwritten, rendering it impossible to recover the payload. This only works for standalone payloads. It does not work with variants that use a runner file to execute the payload in memory.

Selfdel.exe will sleep for 30 seconds after the payload has been deleted. Then, it deletes.del.exert can be accessed from the disk, but it doesn’t delete itself.

How CrowdStrike(r) Falcon Prevent(TM) Stops Samsam

Samsam’s delivery method is unique. An organization would need to pay each user infected to decrypt files if they gather user credentials. It is also difficult to collect the payload from memory or disk due to the use of cleanup files. Falcon Prevent(TM), next-gen antivirus, is capable of detecting and preventing malware from encrypting files.

Figure 4 – Samsam stopped by Falcon Prevent

Falcon Prevent can also detect and stop selfdel.exe from being executed once it has been loaded with the payload, as shown below.

Figure 5 – Selfdel.exe stopped by Falcon Prevent

These preventions are based upon the behavior patterns of Samsam and CrowdStrike’s machine learning algorithm.


Please enter your comment!
Please enter your name here