The Runner: a key component of the SamSam ransomware campaign – An analysis by Quick Heal Security Labs

In Jan 2018, Greenfield, Indiana-based Hancock Health (healthcare network) was attacked by SamSam ransomware. It encrypted the files containing patients’ data which disrupted their critical services. Even though SamSam is not a new ransomware, it has evolved over a period of time. We had observed its first variant in Feb 2016 that used the RSA algorithm to encrypt targeted users’ files. However, this time, we have observed a significant change in the way this ransomware was launched. The major difference between the old and new variants is the use of the executable ‘runner.exe’ – it decrypts the ‘.stubbin’ extension file and executes the decrypted content. The result of the decryption is a SamSam ransomware file.

Fig 1 below depicts the attack chain of the current SamSam ransomware campaign.

Fig 1. SamSam Ransomware attack chain

The technique of deployment makes the ‘Runner’ a key component in the SamSam ransomware campaign. However, we are not aware of the source of infection for ‘runner.exe’. In this post, we will be taking a deeper look into ‘runner.exe’ – a key component of this campaign.

The Runner

We have seen different variants of ‘runner.exe’ in the last few months. With every variant, we noticed a change in the number of arguments passed to ‘runner.exe’. The first argument is used as a password to decrypt the ‘.stubbin’ file and the remaining arguments are passed to decrypt the payload which is the SamSam ransomware.

Fig 2. Execution sequence of the Runner

Let’s look at the details of the .NET compiled executable (runner.exe) of the variant with three command line arguments.

Fig 3. Execution sequence code

‘Runner.exe’ searches for files with the ‘.stubbin’ extension in its current working directory. The first file found is the desired encrypted file. It then copies the content of the file into an array (arg_4E_0) and deletes the original ‘.stubbin’ file. The array of encrypted bytes and the first argument from the command line (password) is passed to the ‘Decrypt’ function. The Runner then loads the decrypted bytes into the memory and executes it by passing its remaining command-line arguments as the input.

Decryption of ‘.stubbin’ file

‘Runner.exe’ uses the Rijndael algorithm to decrypt the bytes passed as Cipher data. This is a symmetric key cryptographic algorithm. Here, it uses a 32 bytes key and 16 bytes of Initialization Vector (IV) to decrypt the ‘.stubbin’ file.

Figure 4 below shows the generation of key and IV using password.

Fig 4 .IV and Key generation

‘PasswordDeriveBytes’ class is used to generate a key and IV. It is a pre-defined .NET constructor which takes a password and salt as an input to generate a key. Salt is a random data used as an additional input to a function that “hashes” the password and used to make a common password uncommon.

Fig 5 below shows the decryption routine which decrypts the SamSam ransomware file.

Fig 5 .Decryption routine of core .stubbin file

‘CryptoStream’ constructor and Rijndael decryptor are used for cryptographic operations which are performed on CipherData. Using IV, the key to Rijndael algorithm on Cipher data will result in the ransomware payload.

The runner variants

In the oldest version of SamSam ransomware, no ‘runner.exe’ was observed. Only the payload got executed with an RSA symmetric key as a command-line argument. But, the latest variant uses ‘runner.exe’ with 4 arguments.

Fig 6 below shows the difference between the arguments passed in different variants of ‘runner.exe’.

Fig 6 .Variants of ‘runner.exe’

We are also observing a few variants using obfuscation in their code and function names.

Fig 7 .Obfuscation in ‘runner.exe’

The deployment techniques used in the SamSam ransomware campaign makes the retrieval of the core ransomware difficult. It thus hinders the process of providing static detections on the SamSam ransomware file. A timedatestamp trait in the variants depicts the arrival of fresh variants of ‘runner.exe’ every month. So, in the coming days, we may see new variants with more obfuscation and with some advanced functionalities.

Indicator of compromise

D8469E625AE90AB64D4AEF0B63F42150

7A25B0D43047552CBDAD17CFB488317D

038FB413F51B0AB7EB088E0F3EA7BE90

A82DB52BC6F1E5477EB1809CD5F23489

Subject Matter Experts

Dhwanit Shrivastava, Yogesh Bane | Quick Heal Security Labs

Amar Patil