Loading...
Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Messing with Azorult Part 1: Malware Breakdown

In this blog series, we dive into an information stealing Trojan called Azorult that we analysed 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.

Under_ground_forum_Azorult_blog_1
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:

First_stage_powershell_base64_blob
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:

First_stage_powershell_dropper_code2_blob
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:

First_stage_powershell_dropper_code_blob
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

First_stage_EXE_VBMarker
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. 

First_stage_decoder_shell_code_p
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:

Ida_TokenMembership_check
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:

Bot_Unique_id_with_labels_c
Figure 8: Example of a generated bot ID

 

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

Ida_non_crypto_hash_algo
Figure 8: A non-cryptographic hashing algorithm used to generate the identification
 
Ida_guid_algo
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:

X64_example_of_generated_id
Figure 10: An example of a generated ID

 

Ida_useragent_and_cnc
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

 

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

 

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

CnC_respond
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:
C_configpng
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:

Index

Symbol

Malware function

0

-

Repeated reports

1

+

Steal saved passwords

2

+

Steal browser cookies

3

+

Steal cryptocurrency client files

4

-

Steal Skype session db

5

+

Steal Telegram tdata

6

+

Steal Steam data

7

+

Take screenshot of desktop

8

+

Self-destruct

9

+

Steal

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

 

  1. <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:

Azorult_DLL_dependencies_binary_config1

 

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

Azorult_DLL_dependencies_binary_config2

 

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

 

  1. <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:

Azorult_config_string_list

 

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

Config_browser_strings

 

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

Config_cyptu_strings

 

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:

Category Description
System Information The data includes the bot ID, operating system version, OS name,
OS architecture, computer name, username, number of
passwords/cryptocurrencies/files stolen, bot binary type and system rights 
Credentials List of stolen credentials categorized by software type and name
Domain List List of domain name extracted from stolen browser's cookie
Stolen files Stolen files compressed in ZIP format
Victim's IP and Country IP address and country code of the victim

 

Each data category is also formatted as follows:

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

Category_System_information

 

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

Category_creds_information

 

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:

ZIP_content

 

  • 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

Azorult_delimiter_guid

 

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.    

Recent SpiderLabs Blog Posts