MABR 0x02 | Diving into VIDAR's vengeance

Analysis of VIDAR Stealer.

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

In the last article, we analysed STOP ransomware and discovered all its features. We saw that it is dropping VIDAR to steal data on victims computers prior to encrypt them. We will now see how VIDAR works. But first, let take a quick look of the executable that STOP dropped before VIDAR.

Quick analysis of a Defender disabler

We saw previously that STOP downloads and drop an executable named « updatewin1.exe ».

After a bit of unpacking, we can step through shell code :

These 2 functions are responsible of loading APIs. The first one will load standard APIs (GetProcAddress & LoadLibraryA, needed to load other functions). The other one will load a bunch of APIs to unpack the final payload :

Here, VirtualAlloc and VirtualProtect are essential for unpacking.

First, the malware will try to run as admin :

RunAs is used to run as admin

We can see all commands that the malware will perform, all related to Windows Security. It will for example :

  • Disable Windows Defender Monitoring
  • Delete Local Malware Definitions
  • Disable Task Manager

All commands to be run to disable Windows protection

Disabling TaskManager

To conclude, this script will help malware to stay undetectable, it is an helper to drop before an infection. But it needs to be run as an admin. If we do some threat attribution with Intezer, we can see that different Threat Actors use this helper :

Intezer Analyse report

Unpacking VIDAR

The first thing we see is that the packer code is obfuscated, like STOP’s packer :

Obfuscation to evade detection and slow analysis

Anti debugging

We also have a similar anti-debugging technique than STOPs, abusing memory APIs to block the debugger if the sample is being analysed.

This technique has the same behaviour than the LocalSize one. If you want more informations I invite you to read the first part of MABR 2 and check this link : https://search.unprotect.it/technique/localsize0/

We can add the name of the API in the capa rule to cover this technique.

Process hollowing

In the next part, it uses stack strings to load APIs to perform process hollowing.

Stack strings to load CreateFileA API

I recognised the flow of process hollowing thanks to these calls :

Process Hollowing flow

You can see the full flow of process hollowing in the first article of MABR 2.

During the analysis of shellcode dropped by VIDAR, I noticed that it was the exact same packer & loader as STOPs. The anti debugging technique is the same, it uses the same type of obfuscation, process hollowing and the exact same shellcode. I think that STOP lend his packer to VIDAR. We will intimately name this loader MemLoader (in reference to the anti debugging technique that abuses memory related APIs)

VIDAR’s core

Anti-debugging & sandbox

Once we unpacked the sample, we are welcomed by a debugger check (access to fs segment 30)

Most common debugger detection technique

If a debugger is detected, this piece of code will be executed, causing the crash of the program. I currently don’t know what this code does exactly :

The first function will be detecting an eventual sandbox environment by checking username and hostname of the machine:

Username check

Machine name

At first at thought that « HAL9TH » was the name of VIDAR’s developer and this function was used to check if the malware was run inside of test env. But after checking, I realised that it was the name of Microsoft Defender’s emulation sandbox as we can see in this article : https://i.blackhat.com/us-18/Thu-August-9/us-18-Bulazel-Windows-Offender-Reverse-Engineering-Windows-Defenders-Antivirus-Emulator.pdf

The next function is a debugger check as we saw earlier. But I noticed that if we modified the value of eax to 0 previously, the function doesn’t trigger anything. I conclude that this function isn’t working.

Pseudocode of function

If any of the 2 functions detects a debugger or a sandbox, the program exits :

Main function

Flow graph of the main function

String encryption

As we can see we hit the main function, it starts by an interesting string decryption routine as we can see here :

This routine is called 304 times

Function args and return

The function works as follow :

  • The first arg pushed is the size of the string to be decrypted
  • The second arg is the encrypted string
  • The third arg is the key

It returns then after the other function arguments the decrypted results, as we see eax being moved into a dword.

The encryption routine is simple XOR, each byte of the key is XORed against the byte of the string.

So I decided to build an IDA Python script that decrypts all strings automatically : https://github.com/lordtmk/vidar_string_decryptor

Log file produced by the script

I will explain the script in the bonus part of this MABR 2.

API loading

We then encounter a simple API loading routine that loads different APIs in different libraries :

API loading routine

Failed connection to tumblr

VIDAR has an interesting way to stay active, it usually gather the IP of a C2 server by gathering a legitimate webpage. In my sample, the malware tried to contact a Tumblr profile (that was deleted), and access the about page, where the operator put the IP of the C2.

That’s a good way to avoid the death of a sample because its C2 is down. But in this case, the page was also down and the malware decided to contact the C2 by an hardcoded IP in the binary.

C2 gathering function

Data theft

As we know, VIDAR is a stealer. A malware that was created to collect passwords, credit card information, cookies, and send them to the operator.

Let’s see how it works :

  • First, it will create a folder in C:\ProgramData with a random name, where it will store all the data temporarly :

  • Then, it sends an ID based on the MAC address of the PC to C2, which responds with configuration, that describes type of files to steal:

Configuration received

Machine UID

  • Again, it tries to download several dlls from the C2. Theses DLLs are legitimate Firefox DLLs used to interact with the browser to steal data inside of it (cookies, autofill, passwords) :

  • The malware then steals as much data as described in the configuration file, for example, wallets (Etherum, Bitcoin), cookies, autofill, passwords stored in browser.. and gather informations on the machine, here is an extract of the informations.txt file :

It gathers software installed on the machine too

  • Finally, the stolen content (a file containing all passwords, wallets, and other data, informations.txt) is zipped and sent to c2. The malware should delete all tracks with a script but unluckily it doesn’t execute :

Command that should delete ProgramData directory

End

That’s all for this analysis ! It takes me a lot of time to do because I wanted to stay concise and explain a lot of things at the same time.

We will see in better details how VIDAR works because I found the builder and the admin panel.

But that’s not the end of this Malware Analysis By a Rookie 0x02, I have some other fun things to show you in a bonus episode related to these 2 malwares, stay protected !

comments powered by Disqus
Généré avec Hugo
Thème Stack conçu par Jimmy