Matanbuchus leverages two primary modules: a downloader module and a main module. In the following sections, we analyze the initial infection vector that was observed in an attack and both of the Matanbuchus modules. 

Initial infection vector

The threat actor performed the following hands-on-keyboard actions to deploy Matanbuchus:

• The threat actor used QuickAssist (likely in conjunction with social engineering) to obtain access to the victim’s system.
• The threat actor used the command-line to download and execute a malicious Microsoft Installer (MSI) package from gpa-cro[.]com.
• The downloaded payload contained an executable named HRUpdate.exe, which sideloads a malicious DLL. The malicious DLL payload was the Matanbuchus downloader module.
• The malicious DLL downloader downloaded the main module from: hxxps://mechiraz[.]com/cart/checkout/files/update_info.aspx

ThreatLabz assesses, with medium confidence, that the threat actor’s actions were intended to deploy ransomware to the victim’s organization.

Obfuscation

Both the Matanbuchus downloader and main modules use the following obfuscation methods:

• Matanbuchus stores two arrays for decrypting strings at runtime. The first array contains the encrypted strings, while the second stores information for each string, including the index of the string in the first array and the string’s size. Matanbuchus utilizes the ChaCha20 stream cipher for decryption, using a shared key and nonce for all strings. These are stored as the first 44 bytes of the first array.
• Matanbuchus resolves all necessary Windows API functions dynamically by using the MurmurHash algorithm.
• Matanbuchus embeds multiple blocks of junk instructions in its codebase to hinder analysis, as shown in the figure below.

Figure 1: Example of junk instructions in the Matanbuchus main module code.

Downloader module

Anti-analysis

The downloader and main modules share most of the same anti-analysis features; however, the downloader includes an additional feature: long-running loops. These “busy” loops delay the downloader’s functionality for several minutes after initial execution, allowing it to evade behavioral analysis by sandboxes, which often have low analysis timeout values.

The figure below illustrates one of these long-running busy loops. 

Figure 2: Example of junk code and long-running busy loops in the Matanbuchus downloader module.

Network communication

The downloader module contains an embedded, encrypted shellcode that downloads and executes the main module. The downloader leverages a known-plaintext attack technique to decrypt the shellcode via bruteforce. Matanbuchus initiates a loop that starts with the integer value 99999999. The integer is converted to an 8-byte string and prepended to a 24-byte hardcoded value to create a 32-byte ChaCha20 key. Matanbuchus then attempts to decrypt the shellcode with the ChaCha20 key and a hardcoded 12-byte nonce. Matanbuchus compares the result to the following 21 bytes, which correspond to the first 21 bytes of the shellcode, if decrypted properly.

The 21-byte known-plaintext string is shown below.

E9 A0 00 00 00 55 89 E5 6A 33 E8 00 00 00 00 83 04 24 05 CB 48

ANALYST NOTE: The ChaCha20 nonce field is set to the hardcoded array 01 02 03 04 05 06 07 08 09 10 11 12, while brute-forcing the shellcode data.

If the first 21 bytes do not match these values, the integer value is decremented by one and the loop is repeated.

The decrypted shellcode downloads the main module by sending an HTTPS GET request to a hardcoded command-and-control (C2) server and decrypts the payload received using the ChaCha20 stream cipher algorithm. The Python script below represents the decryption method for parsing and decrypting the downloaded payload.

 def decrypt_downloaded_payload(data: bytes) -> bytes:
       ”””
      Decrypts a downloaded payload from Matanbuchus. If first bytes are equal to 0xDEADBEEF then Matanbuchus writes the payload into disk.
       ”””
       decrypted_file = bytearray()
       payload_data = data[4:]
       key = payload_data[:32]
       nonce = payload_data[32: 44]
       encrypted_data = payload_data[44:]
       chunk_size = 0x2000
       state = 0
       for idx in range(0, len(encrypted_data), chunk_size):
           cipher = ChaCha20.new(key=key, nonce=nonce)
           cipher.seek(64 * state)
           cipher = cipher.decrypt(encrypted_data[idx: idx + 0x2000])
           decrypted_file.extend(cipher)
           state += 1
       return bytes(decrypted_file)

Main module

Persistence

Matanbuchus adds persistence to the compromised host by executing shellcode that is retrieved from the C2 server after the registration process (described later) is complete. Specifically, Matanbuchus generates a new file path and passes the value to the shellcode. The shellcode creates a new scheduled task with the name Update Tracker Task and a file path with the format below.

%WINDIR%\\SysWOW64\\msiexec.exe -z %Matanbuchus_path%

Matanbuchus generates the random file path with the following steps:

• First, Matanbuchus creates a new directory under the Windows APPDATA folder. The name of the directory is derived from the volume serial number of the disk, as shown in Python below.

volume_serial_number = -1
directory_name = f"{volume_serial_number:x}{volume_serial_number >> 2:x}"

• Then, Matanbuchus generates a new random filename with a 12-character lowercase alphabetical string.
• Finally, Matanbuchus copies itself into the newly created directory using the randomly generated filename.

ANALYST NOTE: Matanbuchus creates a unique, per-host mutex to ensure single execution. The mutex name matches the name of the persistence directory, with the string sync prepended to it.

Configuration

The main module of Matanbuchus includes an embedded configuration blob, which is stored in an encrypted format. Upon execution, Matanbuchus decrypts the configuration blob using ChaCha20. The first 44 bytes of the configuration blob consist of the decryption key, followed by the nonce.

The decrypted configuration blob stores the following information:

• A C2 URL along with a boolean value indicating if the network protocol is HTTP (false) or HTTPS (true).
• A campaign ID stored in a UUID format.
• An expiration date.

It is worth noting that Matanbuchus checks the expiration date only on execution and not at any other stage. Consequently, the compromised host might still communicate with the C2 server if the system was not restarted after the expiration date has passed. 

Network communication

Matanbuchus follows a network communication pattern similar to many other malware families. Matanbuchus starts by registering the compromised host with the C2 server and then requests a set of tasks from the server. If any tasks are available, Matanbuchus executes them and reports back any results.

The network communication pattern is illustrated in the figure below.

Figure 3: Matanbuchus network communication pattern.

Matanbuchus supports three main request types. Each request type is assigned a unique ID, which appears at the beginning of each packet after serialization in a Protobuf data structure. These request ID values are listed in the table below.

Table 1: Matanbuchus request IDs.

Matanbuchus uses HTTP(S) for network communications with payloads that contain encrypted Protobufs. Matanbuchus encrypts each Protobuf using ChaCha20 by generating a random key and nonce that is prepended to the packet data. The structure below represents the layout of a network packet created by Matanbuchus.

#pragma pack(1)
struct network_packet
{
 uint8_t  key[32];
 uint8_t  nonce[12];
 uint32_t data_size;
 uint8_t  data[data_size];
};

The network packet data consists of a Protobuf with various message types.

Before requesting any tasks from the C2 server, Matanbuchus registers the compromised host by collecting and sending the following information.

• Hostname and username.
• Windows version.
• Windows domain name.
• A list of installed security products that includes:
  • Windows Defender
  • CrowdStrike Falcon
  • SentinelOne
  • Sophos EDR
  • Trellix
  • Cortex XDR
  • Bitdefender GravityZone EDR
• Boolean value indicating if the compromised host is a Windows server.
• Boolean value indicating if the compromised user has administrator privileges.
• Boolean value indicating the Windows architecture (32/64-bit).
• Campaign and bot IDs.

As soon as the registration process is complete, the following actions are taken.

• Matanbuchus marks the compromised host as registered by creating a registry key under HKEY_CURRENT_USER\SOFTWARE\%volume_serial_number_based_ID% with the bot ID. Matanbuchus checks this registry path on each execution to verify if the host needs to be registered.
• Matanbuchus adds persistence (as described in the Persistence section above).

After completing registration, Matanbuchus starts requesting tasks from the C2 server. The network commands supported by Matanbuchus are described in the table below.

ANALYST NOTE: Matanbuchus maps the network command IDs found in a packet to internal IDs embedded in the binary’s code. For clarity, both ID types are listed in the table below. 

Table 2: Matanbuchus network commands.

ANALYST NOTE: The reverse engineered Matanbuchus Protobuf structures are available here.

Notably, the payloads downloaded from external URLs may be encrypted. Matanbuchus determines if decryption is required by reading a boolean flag from the incoming Protobuf message. The payload decryption routine also uses ChaCha20, similar to the downloader module.

As a final step, Matanbuchus reports the result of each network command, including any output generated from the command. Each task report packet includes the bot ID, task IDs, and any command output (e.g., the result of executing a system shell command). If a task fails, Matanbuchus does not report the task to the C2 server.