Technical Analysis

In this section, the features and capabilities of YiBackdoor are described along with the code similarities with IcedID and Latrodectus.

ANALYST NOTE: YiBackdoor generates and uses pseudo-random values at different stages (e.g. for generating the registry persistence value name). The malware implements custom algorithms for deriving random values, which are primarily based on the bot ID (used as a seed) combined with an implementation of Microsoft’s Linear Congruential Generator (LCG). Since not all pseudo-random values are generated using a single method, ThreatLabz reversed each function and ported them to Python individually. To ensure consistency and clarity throughout this blog, the random values that are referenced can be derived using the Python script available in the ThreatLabz GitHub repository.

Anti-analysis

YiBackdoor includes a limited set of anti-analysis techniques with most of them targeting virtualized environments, and by extension, malware sandboxes. The malware employs the following anti-analysis methods:

• Dynamically loads Windows API functions by walking the loaded modules list, computing an ROR-based hash for each function name, and comparing the results with expected values to identify specific Windows API functions.
• YiBackdoor utilizes the CPUID instruction with the parameter 0x40000000 to retrieve hypervisor information. The result is then compared to values that match known hypervisors, including the following:
  • VMWare
  • Xen
  • KVM
  • Virtual Box
  • Microsoft Hyper-V
  • Parallels
• Decrypts strings at runtime by pushing an encrypted string onto the stack, which is then decrypted by performing an XOR operation with a 4-byte key (that is unique for each encrypted string).
• Measures the execution time of a code block to determine if the host is running on a hypervisor. Specifically, YiBackdoor begins by calling the Windows API function SwitchToThread followed by a call to the instruction rdtsc. Next, YiBackdoor calls the CPUID instruction, which triggers a VM exit, and then calls rdtsc again to calculate the time taken to execute the CPUID instruction. Once the time has been calculated, YiBackdoor calls the rdtsc instruction two more times and calculates the execution time again. This process is repeated 16 times and the final calculated value must be greater than 20 to bypass the detection. This behavior can be reproduced using the following code example.

[[nodiscard]] bool isHyperVisor()
{
   uint64_t timer1 = 0;
   uint64_t timer2 = 0;
   int loop_counter = 16;
   int cpuInfo[4] = { 0 };
   while (loop_counter)
   {
       SwitchToThread();
       uint64_t first_rdtsc_timer_value = __rdtsc();
       __cpuid(cpuInfo, 1);
       timer1 += __rdtsc() - first_rdtsc_timer_value;
       SwitchToThread();
       uint64_t second_rdtsc = __rdtsc();
       uint64_t third_rdtsc = __rdtsc();
       timer2 += ((third_rdtsc 

It is worth noting that YiBackdoor stores the aforementioned information internally, but does not use the information or transmit it to the C2 server. As a result, the detection methods outlined above currently have no impact on the code’s behavior.

Initialization stage

There are several actions that YiBackdoor performs during the initialization phase including injecting code into a remote process and establishing persistence.

YiBackdoor first checks for existing instances of itself by attempting to create a mutex with a host-based name. If the mutex already exists, indicating another instance is active, YiBackdoor will terminate execution.

Code injection

Before proceeding to the core functionality, YiBackdoor ensures that it is running within an injected process. YiBackdoor determines this by checking whether its current memory address falls within the memory range of any loaded DLLs. If it does, YiBackdoor creates a new svchost.exe process and injects its code into it.

The injection begins with YiBackdoor allocating memory in the remote svchost.exe target process and copying its code into that new region. YiBackdoor patches the Windows API function RtlExitUserProcess with assembly code that pushes YiBackdoor’s entry point on the stack, which is then followed by a return instruction. Thus, when the RtlExitUserProcess function is called, the process execution flow will be redirected to the YiBackdoor’s entry point. Interestingly, the svchost.exe target process is created without any special flags (e.g., in a suspended state). However, YiBackdoor does have enough time to inject its code between the process creation and termination. Since the RtlExitUserProcess function is hooked, the malware’s code executes just as the target process is about to terminate. This injection technique may allow YiBackdoor to evade detection by some security products.

Persistence

After completing the code injection phase, YiBackdoor proceeds to establish persistence on the compromised host using the Windows Run registry key. YiBackdoor first copies itself (the malware DLL) into a newly created directory under a random name. Next, YiBackdoor adds regsvr32.exe malicious_path in the registry value name (derived using a pseudo-random algorithm) and self-deletes to hinder forensic analysis.

Backdoor configuration

YiBackdoor contains an embedded configuration stored in an encrypted state. The configuration blob is decrypted and initialized at runtime. The decryption algorithm uses a 64-byte string as the key, as shown in the decryption routine below.

def decrypt(data: bytes, key: bytes) -> bytearray:
   decrypted_config = bytearray()
   for i in range(len(data)):
       x = i % len(key)
       y = (i + 1) % len(key)
       cipher = key[x] + key[y]
       cipher = (cipher ^ data[i]) & 0xFF
       decrypted_config.append(cipher)
       rotation_x = ror(n=key[x] >> (key[y] & 7), bits=key[x] > ( rotation_x & 7), bits=key[y] 

The decrypted configuration data includes the following information:

• A list of C2 servers (separated using a space delimiter) where each C2 server has a boolean flag to indicate if the requests should be in HTTP (false) or HTTPS (true). For instance, the entry 127.0.0.1:0 instructs YiBackdoor to communicate using HTTP to the C2 address 127.0.0.1.
• Three strings that are used for deriving the TripleDES encryption/decryption keys and the  initialization vector (IV) during the network communication process.
• Two integer values that YiBackdoor converts to numerical strings, which are used to construct the C2 URI.
• An unknown string identifier, which could represent a campaign or botnet ID. In the sample analyzed by ThreatLabz, this value is set to the string test.

The configuration’s structure is provided below.

#pragma pack(push, 1)
struct configuration
{
 char C2s[300];
 char response_triple_des_key_table[192];
 char request_triple_des_key_table[192];
 char triple_des_iv[128];
 uint32_t uri1;
 uint32_t pad;
 uint32_t uri2;
 char botnet_id[64];
};
#pragma pack(pop)

ANALYST NOTE: Before decrypting the configuration data, YiBackdoor ensures that the encrypted configuration does not start with the hardcoded string “YYYYYYYYYY”. If a match is found, the embedded configuration data is considered corrupted and the execution stops. ThreatLabz has not been able to confirm the reason for this check yet. Moreover, two of the three configuration C2s are local IP addresses, which further supports the argument that YiBackdoor is still in a development or testing phase.

Network communication

Before initializing a network session with the C2, YiBackdoor derives the C2 URL by reading the following values from the decrypted configuration blob.

• C2 domain or IP address.
• Two hardcoded strings that are used as part of the C2 URI.
• Generated bot ID (calculated at runtime).

Thus, the C2 URL is structured as http(s)://C2/bot_id/uri1/uri2.

Next, YiBackdoor creates a JSON packet that contains the host’s system time (UTC format) and username. The JSON packet is then encrypted using the TripleDES encryption algorithm. The creation of encryption/decryption keys along with the IV is quite unique. The configuration blob includes three strings with each one of them used for deriving the encryption key, decryption key, and IV. However, YiBackdoor does not use their entire values. Instead, it uses the current day of the week as an offset to calculate the starting address of the target value. Using this approach, YiBackdoor manages to have dynamic (and different) encryption keys per day and as a result makes the network traffic more resilient against static-based signatures. This algorithm is shown in the figure below:

Figure 1: Network dynamic key derivation function for YiBackdoor.

The encrypted output is then Base64-encoded and appended to the HTTP header X-tag, and sent in an HTTP GET request.

The C2 response decryption process is similar. YiBackdoor verifies the presence of the HTTP header X-tag and decrypts it. The decrypted header contains the same information that was included in the HTTP request. YiBackdoor then decrypts and parses the HTTP body data, which contains incoming commands, which are in a JSON format. 

Network commands

YiBackdoor supports the commands described in the table below.

Table 1: YiBackdoor network commands.

Note that the command names above use inconsistent casing (e.g., camel case, lowercase, and uppercase).

The structures (in C format) that YiBackdoor uses to parse both tasks received and network commands are shown below.

enum Command
{
 system_info = 0x3,
 screenshot = 0x4,
 execute_new_plugin = 0x5,
 execute_loaded_plugin = 0x8,
 execute_cmd = 0x9,
 execute_powershell = 0xA,
};
struct custom_string
{
 char *string;
 size_t size;
 size_t capacity;
};
#pragma pack(push, 1)
struct task_info
{
  uint32_t task_id;
  Command cmd_id;
  uint32_t unknown_ID;
  custom_string command_parameter;
  custom_string plugin_name;
  uint32_t  timeout_time;
};
#pragma pack(pop)

Command status

YiBackdoor reports the output of each command to the C2 by sending an HTTP POST request. Each command status packet is in a JSON format and includes the following information:

• Task ID.
• A boolean value that represents the execution status of the command.
• The output of the command.

The reported output is summarized in the table below.

Table 2:  YiBackdoor command status messages.

ANALYST NOTE: The task status for the network command ‘task’ is always set to true (success) regardless of the plugin’s loading status.

Plugins

YiBackdoor stores each plugin that is received locally in the Windows temporary folder using a random filename with the file extension .bin. The malware identifies a target plugin by validating the filename against its own filename generation algorithm. The plugins are reloaded each time YiBackdoor is executed.

Each plugin is stored in an encrypted format. The following Python code snippet represents the encryption/decryption algorithm.

   def fix_key(key: bytearray, x: int, y: int) -> bytearray:
       temp_val = key[y:y + 4]
       temp_val = int.from_bytes(temp_val, byteorder="little")
       rot_val = (temp_val & 7) & 0xFF
       temp_val = key[x:x + 4]
       temp_val = int.from_bytes(temp_val, byteorder="little")
       temp_val = ror(temp_val, rot_val) & 0xFFFFFFFF
       temp_val += 1
       temp_val &= 0xFFFFFFFF
       temp_val_x = temp_val.to_bytes(4, byteorder="little")
       rot_val = (temp_val & 7) & 0xFF
       temp_val = key[y:y + 4]
       temp_val = int.from_bytes(temp_val, byteorder="little")
       temp_val = ror(temp_val, rot_val) & 0xFFFFFFFF
       temp_val += 1
       temp_val &= 0xFFFFFFFF
       temp_val_y = temp_val.to_bytes(4, byteorder="little")
       temp_key = key[:x] + temp_val_x + key[x + 4:]
       temp_key = temp_key[:y] + temp_val_y + temp_key[y + 4:]
       return temp_key
   def crypt_plugin(data: bytes, key: int) -> bytes:
       decrypted_plugin = []
       for i in range(len(data)):
           x = (i & 3)
           y = ((i + 1) & 3)
           c = key[y * 4] + key[x * 4]
           c = (c ^ data[i]) & 0xFF
           decrypted_plugin.append(c.to_bytes(1, byteorder="little"))
           key = fix_key(key, x * 4, y * 4)
       return b''.join(decrypted_plugin)

YiBackdoor manages and parses any plugins by using the structures provided below.

#pragma pack(push, 1)
struct struct_plugin_execution_info
{
 uint32_t unknown_field;
 uint32_t plugin_id;
 uint8_t do_start_plugin;
 char plugin_disk_name[16];
 IMAGE_DOS_HEADER* plugin_memory_data;
};
#pragma pack(pop)
struct plugin
{
 custom_string plugin_name;
 void *plugin_entry_address;
 void *plugin_data;
 void *sizeof_plugin_data;
 struct_plugin_execution_info *plugin_execution_info;
 void *mapped_plugin_memory_address;
};
struct plugin_manager
{
 plugin *plugins[1];
 uint64_t number_of_plugins;
 uint64_t max_allowed_plugins;
};

Code similarities

ThreatLabz observed notable code overlaps between YiBackdoor, IcedID, and Latrodectus. IcedID is a malware family that consists of several different components such as a downloader (which has gone through various updates in the past), a main module backdoor, and a main module loader. These similarities are present in both critical and non-critical parts of YiBackdoor’s code.

The code similarities between YiBackdoor, IcedID, and Latrodectus are the following:

• The use of identical alphabet charsets to derive bot-specific randomized strings. The identified charsets are aeiou and abcedfikmnopsutw.
• The format (Base64) and length (64-bytes) of YiBackdoor’s configuration decryption key matches the RC4 keys used by Latrodectus to encrypt its network traffic.
• YiBackdoor hooks the Windows API function RtlExitUserProcess as part of the remote code injection process. This code injection technique is quite uncommon and resembles IcedID’s extensive use of this Windows API.
• Although YiBackdoor uses a different approach to calculate the bot ID, part of the process involves the Fowler–Noll–Vo (FVN) hashing algorithm, which is also present in the codebase of IcedID and Latrodectus.
• YiBackdoor includes a Windows GUID list that is not used during execution. The exact same array of GUIDs is present and utilized in both IcedID and Latrodectus. Hence, the GUIDs in YiBackdoor may be code remnants from the latter two malware families.
• The most significant code similarity is the decryption routines for the configuration blob and the plugins. The plugins’ decryption routine is identical to the algorithm previously used by IcedID to decrypt the core payload and configuration data. The figure below shows the algorithm, comparing the decryption routine from a (GZIP) IcedID downloader sample and the plugins’ decryption routine found in YiBackdoor. Furthermore, the algorithm used to decrypt YiBackdoor’s embedded configuration blob is similar to the aforementioned decryption routine found in IcedID samples.

Figure 2: Comparison of YiBackdoor and IcedID GZIP decryption routines.