Unfolding Vapo (djvu) Multi-staged Ransomware

9 min readNov 13, 2023

4de2d00f758ece9e388f390616b66ca6581376cc674a6c2448f1bd9301246e8b

Executive Summary

Vapo is a version of the Djvu ransomware family. It encrypts the victim’s files and demands a ransom in exchange for decryption tools/key. The virus was detected during a Virus Total analysis of newly submitted samples. It should be noted that Vapo might be delivered alongside other viruses, such as Redline or Vidar stealers. If infected, users may notice symptoms such as occasional beaconing to certain URLs, strange blue screen popups, and the appearance of an executable, which steals browser secrets and makes persistent connections inside the system.

YARA signature rules are attached in Appendix. Malware behavior samples and hashes have been submitted to Virus Total for further examination.

High-Level Technical Summary

Vapo malware consists of three major parts. The first part/stage is ransomware which encrypts system files using symmetric and asymmetric encryption, if the system is not connected to the internet it uses SALSA20 with the local key and when the internet is connected, it gets the public RSA key to encrypt the local key. The second part/stage part is persistence which uses the task scheduler of Windows to start this exe after every 1 minute. The third part/stage is so complex and does a lot of malicious activities like browser secrets stealing, network device information and injection of shellcode.

Malware Composition and Analysis

1st main — binary.exe — X32

4de2d00f758ece9e388f390616b66ca6581376cc674a6c2448f1bd9301246e8b

Build2.exe — X32

C8b5119160d3301fc69657f1c23c8561e6290b953ec645298f436431d41bbd70

Build3.exe — X32

8d7f0e6b6877bdfb9f4531afafd0451f7d17f0ac24e2f2427e9b4ecc5452b9f0

Main binary

The initial executable that runs after a successful spear phishing / dropper is main.exe, I collected the malware from [1] malware bazar.

After running the malware on the system in a few minutes it encrypts all the system files and the extension of files becomes .vapo.

Figure 1 First detonation

The first behavior is GetStartupInfoW which is called after startup persistence occurs of malware in the system.

Figure 2 Calling getstartupinfo after persistence.

If we look more at it, the malware also queries registries for startup information. Usually exploit uses three basic persistence behavior [2]. One of the persistence is a registry, in which the exploit turns on the registry startup value of it and at the start of the system, it is called automatically.

After making persistence successfully inside the system using the registry, it locks the AppData Local folder so that even the admin could not delete it.

Figure 5 Locking folder so that no one can delete it.

Let’s break down this safe lock which is achieved by ransomware. The following command is used by the ransomware to lock the folder to be safe from deletion in the future.

Path: C:\Windows\SysWOW64\icacls.exe

Command: icacls “C:\Users\user\AppData\Local\b5bf24e0-e54b-4604–9033- 3e66b124bbc6” /deny *S-1–1–0:(OI)(CI)(DE,DC)

The file “icacls.exe” is an executable program that is included with the Windows operating system. It stands for “Integrity Control Access Control List” and is used to manage permissions and access control lists (ACLs) for files and directories.

After that, it starts encrypting files immediately and even tries shared folders to encrypt files. This binary does not do privilege escalation technically but if it is executed as non-admin it will ask for permission.

Figure 6 Ransomware asking for permission from UAC.

But if it is executed as admin, it executes smoothly and performs all tasks.

In the future, this binary will be executed from the app data folder.

Figure 8 Copying itself to a safe location for future detonation.

It also behaves as a dropper but first, let’s look at some network indicators and encryption type.

At the start of encryption, this malware creates a connection on a remote server and gets the encryption key.

This request returns the encryption public RSA key which can be seen in Figure [7]. It makes a request to [hxxp://zexeq.com/raud/get.php?pid=DD54DCE69C3A273ED3BE1B2F8AC23E65&first=true]. In this request, the PID in the Get request identifies the victim system and on the domain zexq.com, there is a full database of all victims and their encryption keys. Now by looking at the response of this URL, we can say this is an RSA key that will encrypt the local key. Because the ransomware did all encryption even if it is not connected to the internet.

This public RSA key is saved in the [C:\Users\%USERNAME%\AppData\Local\bowaskkedestx.txt] location. The ransomware uses this key to encrypt the local key of SALSA20 [9]. In this screenshot, I can’t show the key because I have isolated network activities, but this is the exact location of the key. This public RSA key is saved in this location when the internet is connected to the device.

Figure 11 RSA key location in local device.

While encrypting the files in folders it also drops _readme files which tells about the contact of authors and ransom for recovery.

As I mentioned earlier, this first exe also behaves as a dropper, it downloads two different malwares from two different locations.

At first, it downloads build2.exe from [hxxp://colisumy.com/dl/build2.exe] and build3.exe from [hxxp://zexeq.com/files/1/build3.exe]. These both exploits have different malicious behavior from the previous main malware. So far, we have only collected host-based and network-based indicators for analysis because I could not store the assembly screenshots but for these two exploits, we will look in more detail.

Build3.exe

This is stage 2 which is downloaded by its parent malware from [hxxp://zexeq.com/files/1/build3.exe]. The main purpose of this binary was to maintain the whole persistence mechanism. Let’s see how persistence is achieved.

This exploit uses the task scheduler functionality of Windows for the auto start of malicious activity after specific time and it use the name Azure-Update-Tak to look more legitimate.

Figure 14 Malicious command for presistance.

Figure 15 Task Tree.

The following command is used to achieve the goal.

: /C /create /F /sc minute /mo 1 /tn “Azure-Update-Task” /tr “C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Network\mstsca.exe”

Now if we visit the task scheduler from Windows, we can trace down the task which is present by the name Azure-Update-Task. If we see the action, we can see the location of the file which will be executed, and we can also go to triggers to see what condition is used to trigger the task.

So far if we understand the behavior of build3, it only creates the task for running a file in the network, but we did not see any file on that location so let’s dive into that.

Build3 also queries for the global path of \\Microsoft\\Network which is C:\Users\%USername%\AppData\Roaming\Microsoft\Network\ It checks if this path is not present then create a folder on this location. By default, there is no Network in Roaming\Microsoft.

After creating the network folder, it copies itself to the network folder with the name of mstsca.exe. CopyFileW, which is window function is used in assembly for copy file to destination.

This build3.exe did not show any other malicious behavior other than making it persistence in the system and it gets the clipboard data. But it did not send to any remote location, this happen maybe because it was running on VM. We don’t see any behavior other than this on Sandboxes also.

Build2.exe

This is stage2 exploit but for unique name we will say it stage3 which was downloaded from main malware. It uses interesting malicious behaviors involving network discovery for lateral movement, shellcode injection and browser session stealing techniques.

Stage 3 firstly inject shellcode in the thread using RtlAllocateHeap and VirtualAlloc.

There is VM detection and Debugger detection filters implemented here, which checks if the debugger is running or not.

CreateToolhelp32Snapshot is used which is the default function and it creates a snapshot for running processes.

Module32First is also used which takes snapshots of modules running.

IsDebuggerPresent determines whether the calling process is being debugged by a user-mode debugger.

After all these checks it resume the injected thread using NtResumeThread function.

Figure 22 Start injected shellcode.

The real detonation starts after this point. It fetches the cache [3] of available browsers from [C:\Users\burgo\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content].

It did not stop at cache; it steals the sessions also. For this analysis, I had only Microsoft edge that’s way I am only showing its paths. For those who don’t know the session stealing, if attacker steals all your session or even from one domain, he/she can do all actions of that domain without authentication/ logins. Even if that domain has multi factor authentication, if the attacker has the cookies, he/she can bypass all authentication checks.

It also steals users browsing internet history from History.IE5 folder. The system stores all the history of browsing in History.IE5 folder.

Signatures

There are SHA256 signatures of files.

4de2d00f758ece9e388f390616b66ca6581376cc674a6c2448f1bd9301246e8b

8d7f0e6b6877bdfb9f4531afafd0451f7d17f0ac24e2f2427e9b4ecc5452b9f0

C8b5119160d3301fc69657f1c23c8561e6290b953ec645298f436431d41bbd70

3a1d7604abfb9e2454f944022fc755fd5812216fd94bf78d0621feaf0e6ce1c7

2f3cd99c9dc3534442934b672b56043d3df2e1ad46ba86e352ddcc9c13c09a5e

27f0b5a061def20e7f47e3414de0b5c6b8e299b492dccd0c7eed6b449659c6d5

1ba58a1bd99998b95e495f860bed4a8059a3f05cfe3d703325d8fcc279a86caa

10b9256cdb1329b1a39cdff187968161a8bcfcbf1a05c8ce6919b03b6affb8a8

0889c7b82ff586362dc23dd5e5d5be844fe33740cc306f7adbd65550988950ad

06f31ca055070ae59fabcfedb7ca4e163b3cc8d26fd67876014fe32d15699320

013310fc143e36c02e5270864d5cec8c0b6eb54e81fe371064a30d5648dbfc70

3dabaa0faa54a84e836100d5a46835a58fcfab5a8af181ab2898d9015aba4ed9

3f62c555f1724ec2e6ac69a1e459ff69838a75868092e84c91e752fb31420a62

492dd9888117a48d26ee43375c36bd015a9ac8f5b95c0133c6daf651987ab3e0

49ddf1766d34f54d1430609495d9419d3abacba4d9c29f4a07139af2bf24ce4b

4a1aaeed4747266983004f9fa25ff0ed024415f8232f30467b08441084b002e0

598abc5239def3b3a03f9da8042117fddf21ddd549eedf881b3ec48b5f93fd82

63f7e961fd02ddeb4d3dc0baeaed475d084c73c3070ea9c084e5b0fc93b07ad2

6eae62bdea5f28eab390131992fe0fc308bb51f8cc7cfd697dcf45cf7064cd14

77c8dd36dbc5d78085739c7fa357bd68ff68bb36cf90e7b9c90ad302a3f25f18

7f6f6b0dd3f47b6a8edb4fcac3a3c118a94186b81fbc6efb8ff401a3ac8c24fe

8a633e61f4b52c6e966416c230b06161282f87c52cdba301a0d740adc5bd635e

8d99b08f6c265f6a52a766c12adc4ceae17df96155dcc8fd5b69628af7af0e54

Appendices

A. Yara Rules

Note: This rule would not apply if there were packing, injection, encoding and encryption techniques implemented in exploit.

rule vapo_persistence_build3{
meta:
last_updated = “2023/06/01”
author = “osamaellahi”
description = “Task Scheduler Persistence specifically related to vapo ransomware”
hash = “8d7f0e6b6877bdfb9f4531afafd0451f7d17f0ac24e2f2427e9b4ecc5452b9f0”
strings:
$string_for_azure = {41 00 7a 00 75 00 72 00 65 00 2d 00 55 00 70 00 64 00 61 00 74 00 65 00 2d 00 54 00 61 00 73 00 6b }
$string_for_shtaskpath = {43 00 3a 00 5c 00 57 00 69 00 6e 00 64 00 6f 00 77 00 73 00 5c 00 53 00 79 00 73 00 74 00 65 00 6d 00 33 00 32 00 5c 00 73 00 63 00 68 00 74 00 61 00 73 00 6b 00 73 00 2e 00 65 00 78 00 65}
$s2 = {2f 00 43 00 20 00 2f 00 63 00 72 00 65 00 61 00 74 00 65 00 20 00 2f 00 46 00 20 00 2f 00 73 00 63 00 20 00 6d 00 69 00 6e 00 75 00 74 00 65 00 20 00 2f 00 6d 00 6f }
$string_for_mtscexe = {6d 00 73 00 74 00 73 00 63 00 61 00 2e 00 65 00 78 00 }
condition:
$string_for_azure and $string_for_shtaskpath and $s2 and $string_for_mtscexe
}