Petya ransomware is quickly becoming a household name and in typical cyber-criminal fashion, copycat families are starting to emerge.

In this post, we have the benefit of analyzing “malware-in-development” and can observe its growth over the coming weeks. The ransomware is called Satana (devil/satan in Italian) and similar to the Petya and Mischa bundle, Satana works in two modes.

The first mode behaves like Petya, a dropper (that is a typical PE file) writes to the beginning of the infected disk a low-level module which is a bootloader with a tiny custom kernel.

The second mode behaves like typical ransomware and encrypts files one by one (just like Mischa).

Contrary to the Petya and Mischa bundle, these modes are not used as alternatives, but are both utilized, one after the other, to infect the system.

Analyzed samples

Behavioral analysis

After being executed, the sample disappears and installs a copy of itself in %TEMP% under a random name:

dropped

At the beginning of the execution (if started from a normal user account) – the application triggers a UAC notification which is executed repeatedly until the user click “Yes”:

uac

Once executed, the malware writes the malicious code to the beginning of the disk (low-level attack). Then it proceeds with encrypting files.

Contact data chosen for a particular client are also saved in the Windows Registry:

set_keys

One really curious thing about this ransomware is that it announces everything it does:

log

Including the progress in encrypting files:

debug_info

It may suggest, that the product is still at the early stage of development. The sample that we encountered is most likely experimental. Usually malware authors don’t want to leave debug code in their final product.

Low-level attack

Satana installs itself silently and does not throw any BSOD prompts (contrary to Petya), but just write it’s malicious modules at the beginning of the disk and patiently waits for the reboot.

After the system boots back up, it shows a screen with the ransom note:

boot_screen

Contrary to Petya, the kernel is not capable of performing any low-level encryption.

High-level attack (like typical ransomware)

The malware encrypts files one by one, and in each folder drops a ransom note: !satana!.txt. All encrypted files are renamed to: <email_address>__<original_name> (e-mail is randomly chosen from the hardcoded pool):

encrypted1

Example of the note:

ransom_note

NOTE: The generated Bitcon Wallets are invalid. It can be a bug or a symptom that this sample was not intended to be released.

All files are encrypted with the same unique key (the same input produces the same output).

Comparison of unencrypted and encrypted file content:

enc_square1 enc_matusik11@techemail.com___square1.bmp

Visible and regular patterns suggests, that the encryption algorithm is either a block cipher or custom XOR based.

Inside

A dropper is packed in a FUD/crypter. After defeating this layer we can see a payload that is another executable. Authors left many strings making their intentions clear and the analysis easier:

logs

Debug strings are printed generously during the malware’s execution, giving away interesting information:

print_debug

This payload contains all the functions necessary for the infection process.

What is attacked?

In the first (low-level) mode, only the MBR is encrypted (and stored in Sector 6). Recovering the original MBR from a backup allows for the system to boot again.

In the second mode, Satana encrypts files on local disks as well as on unmapped network shares.
Attacked extensions:

.bak .doc .jpg .jpe .txt .tex .dbf .db .xls 
.cry .xml .vsd .pdf . csv .bmp .tif .1cd .tax 
.gif .gbr .png .mdb .mdf .sdf .dwg .dxf .dgn 
.stl .gho .v2i .3ds .ma .ppt .acc .vpd .odt 
.ods .rar .zip .7z .cpp .pas .asm 

It deletes shadow backups by deploying VSSADMIN.EXE with parameters:

Delete Shadows /All /Quiet

Encryption

Satana divides file content into 32 byte long chunks – each chunk is encrypted separately. That’s why patterns of the original file are reflected in the encrypted content.

Before the encryption is executed, ransomware prepares a random buffer. As a random number generator it uses RTDSC (Read Time-Stamp Counter) – the output of the function is processed and the full key is composed.

rtdsc
Content of this buffer is converted to ASCII (DWORD by DWORD):

generated_key

Example key:

ASCII "59E18B50B822020294A8EA0A4154C7597847B3A6359A08194F4865D804BD7E6"

The key generation takes place only once in a single run (the buffer is same for all the files).

The content of this buffer is used during file encryption:

using_generated_buffer

Compare the content of above buffer with the content of the printed buffer (mind endians):

0040F128  50 8B E1 59 02 02 22 B8 0A EA A8 94 59 C7 54 41
0040F138  A6 B3 47 78 19 08 9A 35 5D 86 F4 04 E6 D7 4B 80

ASCII representation:

59E18B50 B8220202 94A8EA0A 4154C759 7847B3A6 359A0819 4F4865D 804BD7E6

Chunks of the file are XORed – (in DWORD sized units) with first 4 DWORDs of the random buffer.  They are then passed to the another cipher (crypt2):
crypto_loop

Crypt2 is a block crypto – (probably slightly modified) 256 bit AES in ECB mode. It process again the same 4 DWORDs that were XORed – using the random key that was generated at the beginning.

Network communication

The sample includes a hard-coded C&C address and uses it to send information about the client:

cnc_add

It also sends the randomly generated key used in the encryption process. Example of the posted data:

id=7&code=102&sdata=6.1.7601 0 1 TESTMACHINE tester 0
&name=mzbfevkz.exe
&md5=59E18B50B822020294A8EA0A4154C7597847B3A6359A08194F4865D804BD7E6
&dlen=7EA61278DFBAD65AE31E707FFE019711

It seems to be the only way in which the malware stores this key. So, although it can perform encryption offline, without connection to the C&C this key is lost. If this observation is true, it means a serious flaw in design. As a result, even victims who pay may not get their files back if they (or the C&C) went offline when encryption happened.

Execution flow

The sample follows several execution paths. At the beginning, it checks whether it has been deployed with any parameters.

choose_run

If not, it installs itself and deploys the dropped version – giving the GUID and the original path as runtime arguments. It also checks if it is deployed with administrative rights – using the function setupapi.IsUserAdmin.

If the malware is running under an account with administrative rights, it just runs the sample again, but this time with an argument – using a command open. Otherwise – it executes with the argument runas to try and get the user to provide admin rights to the malware:

deploy_dropped_with_param

Once this happens, a UAC notification may pop up. However, because the execution is executed in loop, choosing “No” will just make the UAC prompt appear again. The authors called this feature “AdminFlood”:

admin_flood

When Satana is deployed with parameters, it validates them, deletes the original sample and proceeds with the infection.

infect_disk_bgn

The GUID’s MD5 sum is used as a unique hardware ID, that is mentioned in the ransom note. Example:

MD5("{e29ac6c0-7037-11de-816d-806e6f6e6963}") ->
7EA6 1278 DFBA D65A E31E 707F FE01 9711

First, Satana drops the ransom note in %TEMP%, then reads it to the memory and pastes inside the part that it is going to be written on the disk’s beginning. Then it infect the disk with the low-level code. Below – Satana opening hard disk:

open_drive

Contrary to Petya, executing the low-level mode is not an alternative to high-level mode. Regardless, if writing the bootable code succeeds or fails, the program continues with the standard type of the infection.

First, it deletes the shadow copies from the disk then deploys a new thread that is used to encrypt victim files.

disk_encryption

Enumerating disks:

attack_disks

It is common among ransomware to delete dropped samples after the successful execution. Usually, they use tiny batched scripts to achieve this goal. But Satana does things the hard way and injects the module for this purpose to another process.

First, a remote process – rundll32.exe – is created and a new memory area is allocated in it’s context. Then, a small bootstraper is written inside that memory:

writemem_1

The next part of the code is written exactly after that:

write_2

Execution of the injected code starts from the bootstrapper at the beginning of the added memory page. For the purpose of deploying the added code, the malware made use of the function QueueUserAPC:

set_new_ep

Next, the remote thread is resumed. Below, we can see the code that is executed inside rundll32.exe:

inject_delete

Low-level code

Satana, just like Petya, overwrites the disk beginning with it’s own code. In case of this ransomware the low level part looks much simpler.

Bootloader of Satana:

satana_bootloader

Bootloader reads first sector (MBR) and copies it into memory addresses: 0x600-0x800. Then, performs deobfuscation of the code (starting from the offset 0x62C till 0x7FB) using XOR with a value stored at address 0x7FC. In the described case, the value is 0x39 (ASCII ‘9’):

decrypting_code

After decryption, execution is redirected to the revealed code:

decrypted_code

The malware captures input from the keyboard:

receive_input

read

It then calculates a checksum based on the keyboard input and stores it in the memory at 0x2900. It makes a comparison of that checksum with another checksum. But makes no further use of this data. Instead, it leads to an infinite loop:

unfinished_code

Additional sections of the code reveal a password prompt that is never used, based on this and other observations, it seems apparent that the code is not finished and the authors are probably planning to develop it further in the future.

Conclusion

Satana seems to be a ransomware at an early stage of development. It displays some interesting features, but also contains flaws. The low-level attack code looks unfinished – but authors show an interest in developing the product in this direction and we can expect that in the next version it will be improved. We don’t expect this malware is going to be distributed on a large scale yet – it is rather a work in progress, but what we observed now is likely going to be the base for additional threats down the line.

We will keeping an eye on Satana and its evolution and update you as it grows.


This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.