Cet article a été originellement écrit en anglais, il n’est donc pas disponible en français.

During the previous article, we saw the process of unpacking the first stage of the malware. Aside a fairly new anti-debugging technique and process hollowing, this step wasn’t hard. Now that we have successfully unpacked the first stage, let’s jump into it to see its main behaviour.

I will try to be as consice as possible, but trust me, this malware is full of interesting functions.

Welcome in the core

First of all, let’s see the flow chart of this WinMain function :

This is a very long function, we can eventually assume that it will contain a lot of junk code or unused subroutines.

The first thing that appeals to me is that condition. We have a function, and based on the return, either the program continues, or it ends. Let’s dive into this function :

Don’t touch to Russia !

The function starts with a Internet connection to this URL. As you might expect, this function is going to get informations about our geographical position.

Then, it will parse the return and gather our country code in this chunk of data :

Most interesting, the malware will check or country code against many, hardcoded inside the binary. They are plenty of eastern countries but my sample appears to check only for the RU (Russian) string. I think that the actual operator of the ransomware can choose which country to not target when buiding it. This is a technique that Russian malware operators uses to evade sanctions, or maybe for patriotism, who knows.

And if we dare touch to Russia, the malware will execute a panic cleaning function and stop itself. We will not dive into this one because it is just deleting all persistence related data.

Dealing with commands

The next step is to parse commands passed to the malware, first checking if there is more than one (the program path) arguments given:

We have 3 commands in this malware, all hardcoded and not obfuscated, that will define the flow of the program :

• –Admin, when ran with Administrator priviledges
• –Task, when ran by a scheduled task
• –Autostart, when ran at the start of Windows
• –ForNetRes, not used in this sample, probably used to check if domains are responding

Don’t worry about this list, the arguments does’nt make something special, this is just a way to insure the malware will re-execute even if it was killed.

Anti-debugging?

The next function will check if another instance of the program is actually running, by trying to opening it. It is used to see if his parent process (the one which injected the actual program using process hollowing) is still being debugged. Which makes me say this is, during its execution, the malware will have multiple instances and nothing happends, but it crashed when i still had my debugger opened with the first sample.

Honestly, i don’t think it is an anti-debugging technique, or maybe just to trick the very beginners.

URL Obfuscation

Again, we does’nt have so much obfuscation or encryption in this sample. APIs, string and others are hardcoded and not obfuscated in any way. But, the malware implements a simple UnXOR function to decrypt the C2 related strings, with an hardcoded (80) key.

Little flavour of persistence

The next main function for the program will be establishing persistence. The program uses the MITRE ATT&CK T1547.001 technique, which consist in a registry key that will launch the program at the start of Windows :

Then, it will call icacls.exe, a Windows PE used to set rights on folders or files. This step is pretty common to malwares to insure that the executable cannot be deleted if the user finds it.

The command is as follow :

• /deny : Deny for
• *S-1-1-0: : Everyone
• (OI)(CI) ; Inherited folders and files
• (DE,DC) : Delete & Delete Childs

With this call, the folder containing the exe in AppData folder cannot be deleted by anyone. Anyway, we can change the permissions back to default in order to delete it.

Persistence via Task Scheduler

Next, the malware will add another layer of persistence, by insuring that the malware will be run another time even if we terminate it.

The use of COM objects is not new. Malware often use it to evade API detection, or, like in this case, because no API is available to interact with Task Scheduler.

When analysing COM objects use in malwares, we must figure out what the CLSID is representing. I personnaly use COMView which regroups a lot of CLSIDs, after gathering the ID in IDA Pro :

For the rest, i don’t understand much how COM objects works, so i just stepped through the different calls and refreshed the Task Scheduler to see if something was added.

The task will repeat each 5 minutes and launch this payload

Privilege escalation

Every malware needs Admin rights to fully carry out their tasks, and STOP is no exception to the rule. It will prepare a command to be run as Administrator :

An UAC window will pop-up. If we answer yes, the actual malware will stop and start a new one with Administrator privileges. If we answer no, the malware will continue, ignoring a function that must be ran with Administrator rights :

This is the only function specific to the –Admin sample. I don’t know its goal but it can be related to antivirus evading or to stop event logging software.

Contacting C2

The malware starts by unXORing an URL, apparently containing other exe payloads :

Note that this thread will recover 2 payloads, the first one, pretty inoffensive, and Vidar Stealer. We will cover these 2 in details in the next part of Malware Analysis By a Rookie.

Getting public key to perform encryption

The malware will gather some unique informations about our PC to create an unique hash to represent our ID. It will gather IPV4 address and MAC:

Encryption

Final job of this malware is obviously to perform encryption. It first starts to load all ransom related strings to create a readme.txt file :

It will then add all browser paths to a safe list to prevent their content to be encrypted, first for the user to use them to buy bitcoin, but also because Vidar will have stuff to do with them.

The safe list is as follow :

When encrypting, it will compare file extension or path against these ones to prevent their encryption.

Our personal ID is written to this file :

The malware will next loop through all drives and find the principal OS drive (C in most cases) :

The last thread before encryption will be net adapters recognition, this thread will run aside the encryption one to target all network shares :

The thread responsible of encryption will loop through all folders, copying the readme.txt everywhere, and then encrypts all files with Salsa20 algorithm.

End of the 2nd part

That was fun to make ! This malware is full of interesting capabilities for beginner analysts like me to understand.

In the next part, i will analyze the 2 other malwares dropped by the ransomware. I haven’t touched them actually so this may be a little bit longer to post an article on that.

See you in last part !