Messing with Azorult Part 1: Malware Breakdown

In this blog series, we dive into an information stealing Trojan called Azorult that we analyzed during a recent Digital Forensics and Incident Response (DFIR) investigation. During our analysis, we also take a look at the bot’s control panel and its vulnerability.

Azorult is an information stealing trojan that harvests and exfiltrates saved passwords, browser login data, cookies, history, chat sessions, cryptocurrency wallet files, and screen captures. This trojan is being sold/leaked/shared in the underground forums and is quite popular with cyber criminals. It’s commonly propagated via spam, either as an attachment or as a payload of a malicious document file. We often find this trojan downloading additional malware onto the infected system like ransomware.

Figure 1: Azorult advertised in an underground forum.

Malware Analysis

Let’s start by stepping back a bit. We received a suspect file from our DFIR Team. It was reported to us that the compromised host made a fraudulent transaction and this file was found in the memory space of the compromised system. We quickly checked the file and determined it was a PowerShell script that contained this blob of Base64 encoded data:

Figure 2: First stage Powershell script that contains a blob of Base64 encoded data

Scrolling down through the file, it became apparent that it was a Base64 encoded Windows Portable Executable (PE) file that will be dropped in the %PUBLIC% folder using a random filename with a length of three to five characters:

Figure 3: A code snippet of the Powershell script where it writes the decoded file to %Public% folder using a random filename.

Once the decoded PE file is dropped, it is then executed in the system:

Figure 4: The decoded file is a Windows PE (Portable Executable) file that is executed after it was dropped in the disk.

The executable file itself is packed with some kind of Visual Basic packer. The image below shows the malware's entry point where it calls the ThunRTMain (MSVBVM60.100 ordinal) function and a signature of a Visual Basic compiled executable. If you want to deep dive on Visual Basic PE file reverse engineering, you can check this link here: 

Figure 5: The executable's entry point. Malware's second stage is a Visual Basic compiled executable. 

Once the executable runs, it allocates some memory space where it decodes some shellcode. The decoding is actually a simple XOR with a 4-bytes key [0x10,0x28,0xde,0x00] against a blob of data in the .TEXT section of the malware body. 

Figure 6: The second stage's decoding loop is a simple XOR with the key held by the processor register ESI. 

Right after the XOR decoding, the execution is transferred to the decoded shellcode. It’s main purpose is to run another process of the main executable, unpack the payload and inject it to the process it created.

Payload: Azorult

The payload itself is Azorult. There are different versions of Azorult, but this particular  sample is version 3.3 and is compiled with Borland Delphi. Right after execution, Azorult  checks for the user privilege and takes note of it with an acronym (i.e. A = Admin, U=User, G=Guest, S=System) and this is later sent to the command and control server:

Figure 7: Azorult checks for user privilege, this information is sent later on to the command and control server

Azorult then gathers for four key pieces of data for identification of the compromised system which includes:

• A machine unique identification (taken from the registry key)
• Product name
• User name
• Computer name
• A fifth key is a combination of all the above

A non-crypto hash algorithm is used to generate an ID for each piece, and the results are then joined (separated with “-”) to identify the host machine. Here’s an example of a generated ID:

Figure 8: Example of a generated bot ID

The ID generation algorithm is a simple non-cryptographic hashing and uses a XOR-key 0x6521458A

Figure 8: A non-cryptographic hashing algorithm used to generate the identification

Figure 9: Code snippet of the bot unique identification function

Once the bot ID is generated, it is encoded with HTML URL encoding,  XOR’ed with a 3-bytes key  (0x03 0x55 0xae) then sent a control server through a HTTP POST request:

Figure 10: An example of a generated ID

Figure 11: The code snippet showing the User-agent and Command/Control server domain where it sends the initial bot registration POST request that contains the encoded bot ID

Figure 12: Wireshark packet capture during the initial bot registration.

The command and control server then responds with some encoded configuration data:

Figure 13: Command and control responds a encoded configuration

The configuration has three elements that are encoded in different ways:

1. <c></c>

   This configuration part is defined by the attacker from the control panel. It is encoded with 2 layers. First is XOR with the same 3-bytes key used when sending the initial phone home POST data, then base64. Below is the decoded configuration for this sample:

Figure 14: The decoded configuration from "<c></c>" element

From the screenshot above, highlighted in blue are bunch of flags (an array). Highlighted in red are the files to exfiltrate including the exact directory path from where to exfiltrate it. Highlighted in green are additional malware executables to download and execute. In this case, Azorult downloaded Phobos ransomware and another backdoor. Lastly, highlighted in gold is more information, namely the victim’s public IP address and geolocation.

Back to the flag array, each index element of the array is a command for the malware to carry out some pre-defined functionality. Symbols “+” represents enabling of the command otherwise “–“ symbol means disabled. Here’s an interpretation table for this configuration:

Figure 15: The malware function where it parses the flag array

2. <n></n>

   This second configuration part is an encoded stream of data XORed with a 4-bytes key [0xC8 0x65 0x30 0x01]. This data contains all necessary DLL binaries needed by the bot to perform its primary data stealing functions, as well as needed runtime libraries:

In this stream, each DLL binary is separated with ^{|||<[{99c3}]>|||} delimiter:

These files are dropped in the %AppData\Local\Temp\<Random>\ directory and are deleted after data exfiltration (depends on the bot configuration).

Here’s the list of DLL files extracted from that stream:

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
freebl3.dll
mozglue.dll
msvcp140.dll
nss3.dll
nssdbm3.dll
softokn3.dll
ucrtbase.dll
vcruntime140.dll

3. <d></d> - This final configuration part is base64 encoded data of all the suspicious strings used by the malware. This is probably to avoid malware scanner detection. Here’s the partial list of strings:

The list also includes a list of all target browsers where user data are stolen from:

And also strings target cryptocurrencies and directory paths of its wallet:

The full list of strings can be found here: https://pastebin.com/4abCyFh6

Data Exfiltration

In terms of data exfiltration, after the bot steals data from the compromised system, it organizes it into 5 categories:

Each data category is also formatted as follows:

System Information - in this category, each data is delimited with '|'

Credentials - same as above, the data is delimited with '|'

Domain list uses no special formatting, but each domain name is delimited with new line. While the stolen files are bunched together into a ZIP compressed file, the contents as shown in the image below:

• The “Browsers” folder contains the victim’s browser auto-complete data, cookies and history.
• The “Files” folder contains all other files that were stolen based on the configuration set by the criminal.
• The “Steam” folder contains the stolen steam data.
• txt is the list of domains extracted from the victim’s browser cookie database.
• txt contains a list of usernames and passwords extracted from browser login data and other mail/messenger/ftp client software.
• jpg is the desktop screenshot image.
• txt contains system information, list of running process and software installed.

All of these 5 categories of data are combined together in one stream and delimited with a unique ID hard-coded in the malware body

This combined data stream is then XOR encoded using the same 3 bytes key 0x03, 0x55, 0xae. The data is then sent as a raw data through a HTTP POST tunnel to the command and control server. This data is then parsed by the command and control server while the ZIP compressed file is stored in a directory inside the control panel. 

This Azorult bot sample was configured to “hit-and-run”. Once a victim clicks it, it right away retrieves the configuration from the control panel, steal all data that is set in the configuration, exfiltrate the data and then self-destruct. There is no persistence that is created and almost no footprint is left as all files it creates are deleted.

We will visit Azorult’s command and control in depth is Part 2 of this series.

Thanks Kunal Shandil for giving us additional information and Phil Hay for his feedback & contribution.