APT

MystRodX: The Covert Dual-Mode Backdoor Threat

Alex.Turing, WangZhiCheng, Acey9

2025年8月27日 • 13 min read

Background

On June 6, 2025, XLab's Cyber Threat Insight and Analysis System(CTIA) picked up activity from IP 139.84.156.79 distributing a suspicious ELF file—dst86.bin—with a low VirusTotal hit rate of only 4/65. While conventional scanners labeled it as Mirai, our AI module remained silent. That mismatch caught our attention.

Turns out, it wasn’t Mirai. It was a dropper—and what it delivered was a brand-new backdoor, unrelated to known Mirai strains. We’ve named it MystRodX, based on its propagation filename dst, the internal class name cmy_, and its multi-layer XOR encryption schemes.

MystRodX is a typical backdoor implemented in C++, supporting features like file management, port forwarding, reverse shell, and socket management. Compared to typical backdoors, MystRodX stands out in terms of stealth and flexibility.

Stealth is achieved through a differentiated encryption strategy for various levels of sensitive information:
1. VM & Debugger detection-related sensitive strings are encrypted using single-byte XOR.
2. AES keys, Payloads, and Trigger packets are encrypted using a custom "transform algorithm".
3. Configuration is encrypted using AES in CBC mode.
Flexibility is demonstrated by MystRodX's ability to dynamically enable different functional features based on its configuration, such as choosing between TCP or HTTP for network communication, and deciding whether to use plaintext or AES encryption for traffic.

One of the most interesting features is its support for a wake-up mode, meaning MystRodX can be configured as a passive backdoor that is activated by specific DNS or ICMP network packets without the need for open ports.

One config field sets a activation timestamp. In the samples we caught, the earliest was set to January 7, 2024, 23:10:20—meaning this thing has been hiding in networks for over 20 months, completely under the radar. Through XLab’s C2 hunting platform, we found three live C2s—and evidence of more uncaught samples in the wild. Given its stealth and low profile, we’re breaking down MystRodX now. It’s time to expose a long-lingering threat—and help defenders hunt it down.

Passive Mode

When the Backdoor Type is set to 1 in the configuration, MystRodX enters passive backdoor mode. In this state, it uses a RAW socket to monitor all incoming traffic—without binding to any open port. It can be activated by specially crafted DNS or ICMP packets.

The activation message is encrypted using the Transform algorithm (detailed in the Appendix). Once decrypted, the payload follows this structure:
Magic (4 bytes) + Protocol (4 bytes) + Port (4 bytes) + C2.
If the Magic value is verified, MystRodX establishes communication with the C2 using the specified protocol and awaits further commands.

Unlike well-known stealth backdoors like SYNful Knock, which manipulates TCP header fields to hide commands, MystRodX uses a simpler yet effective approach: it hides activation instructions directly in the payload of ICMP packets or within DNS query domains.

DNS Trigger

A valid DNS trigger packet must follow the format:www.DomainName.com.

The DomainName portion is {9-byte mask}UBw98KzOQyRpoSgk5+ViISKmpC6ubi7vao=. When this string is Base64-decoded, it produces the following ciphertext:

00000000: C5 E4 F2 A7 11 73 DD 40  70 F7 C2 B3 39 0C 91 A6  .....s.@p...9...
00000010: 84 A0 93 9F 95 88 84 8A  9A 90 BA B9 B8 BB BD AA  ................

This ciphertext is then decrypted using the Transform algorithm in the Appendix with the parameters:

magic: 0x0d
magic2: 0xaa (the last byte of the ciphertext)
key: key_for_backdoor

The decryption yields the plaintext activation payload

Parsing this plaintext reveals:

Magic: "CAT"
Protocol: TCP
Port: 0x1f4a (8010)
C2 IP: 149.28.137.254

If the Magic value matches, MystRodX initiates a connection to 149.28.137.254:8010 and awaits further instructions.

ICMP Trigger

Next, let's examine the ICMP trigger packet. This time, we'll take a proactive approach, constructing the packet and observing the sample's behavior.

First, we craft a simple ICMP ping request: 08 00 00 00 30 39 00 01. Then, we construct the PAYLOAD, specifying the C2 server as 192.168.96.1, port 443, and using the HTTP protocol:

00000000: 43 41 54 00 01 00 00 00  BB 01 00 00 31 39 32 2E  CAT.........192.
00000010: 31 36 38 2E 39 36 2E 31  00 00 00 00 00 00 00 00  168.96.1........
00000020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

Next, we apply the Transform algorithm with the magic2 parameter set to 0x9f to encrypt the payload. Finally, we combine the ICMP header with the encrypted payload to form the complete ICMP packet.

Upon receiving the ICMP packet, MystRodX establishes a communication connection with 192.168.96.1:443 and sends an HTTP-formatted check-in message. This behavior aligns perfectly with our expectations, confirming the accuracy of our analysis.

Digging Deeper

In the two captured MystRodX samples, the configured C2 servers have no active ports open. After completing reverse analysis, we have a question: Is MystRodX still an active threat or has it been abandoned? To answer this, we conducted several investigations from both BOT and C2 perspectives using XLab’s C2 hunting platform.

0x1: Activating Bots

We sent DNS/ICMP activation packets across the internet to trigger MystRodX backdoors in passive mode, aiming to identify potential victims. Unfortunately, aside from our test IPs, no valid check-in responses were received. Possible reasons include: wild MystRodX samples may not have passive mode enabled, or they use new keys, magic values, or configurations, causing our activation packets to fail.

0x2: Probing C2s

With the support of active C2 probing services, we successfully identified three C2 servers that are still active in the wild. These servers responded to the online packets and sent a command 7 to the bots, requesting them to enable traffic encryption. They have been active since 2024, demonstrating the continued presence of the MystRodX threat.

MystRodX configurations include RSA public keys for decrypting command 7. Attackers typically use distinct keys for different campaigns, with two known keys linked to the “neybquno” and “zoufkcfr” campaigns. In command 7 packets, a 256-byte segment at offset 0x110 contains the MagicString ciphertext. MystRodX enables traffic encryption only if the decrypted MagicString matches the hardcoded “0x68abut.” This allows us to link C2s to known campaigns.

Among the three newly discovered active C2 servers, only the command 7 issued by 149.28.137.254 could be successfully decrypted using known public keys. This indicates that the other two C2s (156.244.6.68 and 185.22.153.228) belong to an as-yet unknown attack campaign, meaning there are definitely uncaptured MystRodX samples in the wild.

Detection Analysis

Over the past two months, the detection rate for MystRodX samples has slightly increased, now reaching 6/65. The main label remains Mirai.

We speculate that some antivirus software use the Mirai label because the sample uses Mirai's classic single-byte XOR encryption for strings related to virtual machines and debuggers.

vmware	vbox	phoenix
innotek	lldb	strace

We tried two patch methods: one removes the encrypted strings related to virtual machines and debuggers in the sample, while the other replaces the encrypted text with plaintext. The antivirus detection results after patching were surprising, as both patch methods effectively lowered the detection rate. However, these strings are actually unrelated to the core functionality of the sample, indicating that the community has not truly identified the MystRodX threat.

Dropper Analysis

0x1: String Decryption

MystRodX uses single-byte XOR encryption to protect sensitive strings. The decryption method is simple: the last byte of the ciphertext is the XOR key, and it is XORed byte-by-byte with the ciphertext. For example, if the ciphertext is \x13\x08\x12\x04\x17\x00\x65, the key is 0x65, and after decryption, it becomes vmware\x00. To make analysis easier, we can use an Idapython script to batch decrypt.

The results are as follows:

The decrypted strings can be divided into three major categories, which are used for virtual machine detection, debugger detection, and launcher-related functions:

VM-related: Checks the contents of /sys/class/dmi/id/bios_vendor to see if it contains vmware, vbox, Phoneix, or innotek to determine if it is running in a virtualized environment.
Debugger-related: Checks the parent process name for common debugging tools such as gdb, lldb, ltrace, strace to determine if the current process is being debugged.
Launcher-related: The next stage involves the Launcher filename, PID file, and working directory.

0x2: Payload Decryption

Before decrypting the Payload, a keyinfo structure needs to be set up in advance, where the value of key1 is 0x13, and the xorkey is hardcoded in the sample with a length of 32 bytes.

struct keyinfo {
    uint8_t key1;
    uint8_t unknow[3];
    void *xorkey;
    uint16_t xorkey_len;
    uint8_t key2;
    uint8_t notused;
};

The xorkey is as follows:

00000000  02 06 03 09 04 02 0e 0a 01 0f 08 0a 04 0d 0b 09  |................|
00000010  0a 09 01 03 06 05 6d 0c 01 02 0f 03 03 0a 05 00  |......m.........|

The value of key2 is computed using a checksum-like algorithm on the xorkey, which in this case is 0x90.

After obtaining key1, xorkey, and key2, the following code snippet is used to decrypt the Payload. It can be observed that the last byte of the Payload is also a key. This algorithm, known as MystRodX_Transform, is repeated across multiple scenarios in MystRodX, such as AES key decryption, trigger packet decryption, etc.

After analysis, we implemented the algorithm in Python, as detailed in the "Transform Algorithm" section of the Appendix. In actual use, you only need to provide magic, magic2, and key. For example, to decrypt the Payload, magic is key1 (0x13), magic2 is the last byte of the Payload (0xab), and key is key_for_dropper.

The decrypted Payload contains three critical files: chargen, busybox, and daytime. Among them, daytime is the Launcher component responsible for launching chargen, which is the core MystRodX backdoor component. The Payload's verification mechanism relies on a 7-byte checksum value: C2 0A D7 A4 22 21 5A. The Dropper compares this value and only releases the Launcher and MystRodX backdoor if the checksum matches.

Launcher Analysis

The Launcher uses the same string encryption algorithm. The decrypted clog and dlog are used to store the process IDs (PIDs) of the MystRodX and Launcher. Its core function is to continuously monitor the status of the MystRodX backdoor process, chargen. If chargen is not running, the Launcher will restart the backdoor process.

MystRodX Backdoor Analysis

MystRodX is a typical backdoor implemented in C++. The class names in the sample clearly reveal the functions it supports, such as file management, reverse shell, SOCKS proxy, port forwarding, etc.

Due to space limitations, this article will not delve into the common functions but will focus on analyzing the distinctive features of MystRodX from two aspects: host behavior and network protocols, including:

Dual-process Guardian Mechanism
Configuration Decryption
Communication Protocol
Passive Backdoor Mode

0x1: Dual-process Guardian Mechanism

MystRodX continuously monitors the daytime process. If daytime is not running, MystRodX will immediately launch the Launcher process again. This way, the Launcher and MystRodX form a dual-process guardian mechanism: if either process terminates, the other will restart it, ensuring long-term stable operation.

0x2: Configuration Decryption

MystRodX’s configuration is encrypted using AES. The AES key, like the Payload, is protected by the Transform algorithm, except that the values of key1, xorkey, and key2 differ.

key1:0xd

xorkey
00000000  00 02 07 11 13 19 04 06 16 0e 18 0b 02 2d 0b 19  |.............-..|
00000010  a0 91 02 23 96 45 6c 1c b1 d2 7f e3 22 00 00 00  | ..#.El.±Ò.ã"...|

key2:0xf1

Below are the AES-related ciphertext and the decrypted plaintext. The AES key starts at offset 0x08 in the plaintext and has a length of 32 bytes.

Using the above AES key and a hardcoded IV 0D 0F 02 04 08 07 2D 1C 01 04 0D 01 02 07 06 02, you can decrypt the configuration using CBC mode. Readers can refer to the CyberChef section in the Appendix for more details.

The configuration of the sample 72d377fa8ccf23998dd7c22c9647fc2a are shown below:

The decryption process for the configuration of a46f2c771fb580e2135ab898731be9a7 is the same; only the key differs.

The configuration includes information such as the activity name, time, C2 server, port, public keys, and more. The table below lists each attribute and its offset in the configuration (note: the configuration may vary depending on the sample):

Offset	Field
0x00	Campaign
0x08	Backdoor Type
0x0c	MainC2 Port
0x10	BackupC2 Port
0x1c	Interval
0x24	Effective date
0x78	Main C2
0x178	Backup C2
0x278	Public Key

When the Backdoor Type is set to 1, MystRodX enters passive backdoor mode and waits for an activation message. When the value of Backdoor Type is not 1, MystRodX enters active backdoor mode and establishes communication with the C2 specified in the configuration, waiting to execute the received commands. In the two samples captured so far, the value of Backdoor Type is 0.

0x3: Network Communication

The MystRodX backdoor supports two communication modes: TCP and HTTP, and it can be configured to enable or disable AES encryption. The currently captured samples all use the TCP mode and have encryption disabled. The network packet format is as follows:Packet Length (4 bytes) + Main Code (4 bytes) + Sub Code (4 bytes) + Packet Direction (4 bytes) + Data

For example, the packet 10 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 indicates that the packet is sent from the BOT to the C2, with a length of 16 bytes. The Main Code and Sub Code are both 1, which corresponds to the online message of MystRodX.

Little Endian 
10 00 00 00  ---> Packet length, 0x10 bytes
01 00 00 00  ---> Main Code, 0x01
01 00 00 00  ---> Sub Code, 0x01 
01 00 00 00  ---> Direction, 0x01, bot_to_c2

The Main Code in the protocol can have the following values: 1, 2, 5, 7, and 8. Among them, 2, 5, 7, and 8 correspond to reverse shell, file management, port forwarding, and SOCKS management functionalities, respectively.

1 represents general management functions, primarily used by the C2 for controlling the bot, such as updating configuration files, uploading device information, etc. These operations are assigned different Sub Codes. The table below lists the Sub Codes and their corresponding functions.

SubCode	Function
1	Beacon
2	Uplaod DeviceInfo
4	Heartbeat
7	Enable Traffic encryption
14	Set a new interval
15	Update Configuration
16	Teardown
19	Upload TimeInfo

For example, when the bot receives a command with MainCode 1 and SubCode 2, it will report the device information back to the C2.

Additionally, it is worth mentioning that when traffic encryption is enabled, the network packet format changes and is upgraded to the following structure:CipherText Length(4bytes)+ PlainText Length(4bytes) + padding(8bytes) + CipherText.

Summary

With this, our analysis of MystRodX comes to a temporary close. The above information represents all the relevant intelligence currently available. Network administrators can refer to the technical details in this analysis to assess whether their systems have been compromised by this backdoor.

Due to limited visibility, we currently do not know the specific infiltration vectors, attack targets, or the true intentions of MystRodX. We sincerely welcome industry partners who possess further information to share intelligence with us, so that we can work together to enhance cybersecurity defenses.

If you are interested in our research or have any information related to this backdoor, feel free to contact us via the X platform.

IOC

Downloader

http://139.84.156[.]79/dst-x86.bin

C2 & Campaign

airtel.vpndns.net:443   neybquno
149.28.130.195:443    zoufkcfr

149.28.137.254:8010   neybquno
149.28.137.254:8443   zoufkcfr


156.244.6.68:443    unknown
185.22.153.228:443  unknown

Sample MD5

Dropper
5e3a2a0461c7888d0361dd75617051c6 *dst
72d377fa8ccf23998dd7c22c9647fc2a *chargen
5bf67ce1b245934965557de6d37f286f *daytime


fa3b4d5fd1f6c995395244f36c18ffec *dst
a46f2c771fb580e2135ab898731be9a7 *chargen
e8fcb7f3f0edfc7d1a99918dc14527d1 *daytime
1f003437e3d10e07f5ee5f51c61c548f *networkd

Patched By Xlab
4dc20d1177da7932be3d63efe939b320
2775d9eac1c4a5eb2c45453d63ea6379
4db35e708c2d0cabe4709fa0540bafb7

Public Key

neybquno

zoufkcfr

Appendix

Transform Algorithm

key_for_dropper=bytes.fromhex('02 06 03 09 04 02 0e 0a 01 0f 08 0a 04 0d 0b 09
0a 09 01 03 06 05 6d 0c 01 02 0f 03 03 0a 05 00')


key_for_backdoor=bytes.fromhex('00 02 07 11 13 19 04 06 16 0E 18 0B 02 2D 0B 19
A0 91 02 23 96 45 6C 1C B1 D2 7F E3 22 00 00 00')


def calc_sum(buf):
    checksum = 0
    for i, v in enumerate(key):
        checksum ^= (v << (i&7)) & 0xFF  
    return checksum  
    

def transform(magic,magic2,buf,key):
    
    buf_len=len(buf)-1
    key_len=len(key)
    key1=magic ^ calc_sum(key)
    
    key2=(key[(key1^buf_len)%key_len]) ^ magic2 ^ buf_len
    out=bytearray()
    for i, value in enumerate(buf):
        out.append((key[(i^key1)%key_len] ^ key2 ^ value ^ i)&0xff)

    return out

CyberChef

https://gchq.github.io/CyberChef/#recipe=AES_Decrypt(%7B'option':'UTF8','string':'z7bcjTSKrFiHYUB63NZendVvtJ2RGfo8'%7D,%7B'option':'Hex','string':'0d%200f%2002%2004%2008%2007%202d%201c%2001%2004%200d%2001%2002%2007%2006%2002'%7D,'CBC','Raw','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)To_Hexdump(16,false,false,false)&input=PBpcVtR8VHCFl/oaqAGk0w7pCVMMe1xQ1Ma0FBs2X2P9vpD6GrVC/b6XqKDWb/eFS/g9najMHOO3r38h3V9lZvvSKl31GM2FJbIKw91n/r6Z9TgKmrlLdLroahpV91HmQPi2ttGAyXrF9SmsLMCBqA6X5fIPZ/v3cEI69nKREj1Fq%2BHffi6q4s3sfzgDmFDZL9XFff9g2AtSVm7MLBAhNjMXqifFPxIbo5L0McZ%2B%2B78Wrdv3VnsvZIZTBLLM%2BEY/EqiKf73OIvmRGrI3Q4ksiGyG8CTcau6hrlJUN91IWdSjRU0vNPxvwIU4qy9aTSKhTI2Be2Cc53B3aRu%2BGKMcFG0d/IioT0fb1MxeIMPKtPViBzHRRj0OGbK5OFpX0nfdTyAEW85fnXos14I6yO7%2B/JfsaF4YQv7OVCKgQnYXFrjMMajtE%2BoiGInB6d4ybrNNXA3u3p%2BQ3leErM8yuIpvzSre6wPsyJ4VZxyPQA4iRn1AnZO7QA5UG2IzqPCXZfAvLHhvMqMNI9D8bwInx1pnVdx2kwHQhxvyzLGFxkVrhvTcZSGSG708jkAYfzjItoPANBc0WMg0NWuSs53gVmuc/UJk%2BvEiZTjHayg4o1yLANpPtRTfmIMcLfSRIw2BCdthqmPLwx8L46rvUycpHvL3Nb7vl9Uwr12%2BqRjMQj5aaLg4veTaOnRCSJTjVq9aRrzjZutk1hb9CiS/JigJYJoxhCnZ82ZpTIzrjMR8RjES5UX9%2B9/3xkARRcAunSTQP8SZiPVuMOXTHyKB8nr7NsfoUeQ1ixisswp7E3FOqmel92N2CdmrifZzdD3KmnPubHhM5OIX7x0X9004py1zlMSZCAPPLvrCxLpBwqkmuxNjlW7Qz6FKMgXoiwucVrYUzj3rWPBpENrqBAkWvKR3c9Y6dKzTmOPT/CRsEvdbe/l5MWmg5n7vog0TOR3TQpaDRBVC6HMsCSIS/NG0lteKVEevZQDQvSqtWbjMneAUvQ8RLEl8e7CDAQN7xfmQpdRVbaqUtD7hzvz9pfsHgWCG5g0lMkYA6NQFtfyH98/DwB/Jo5fmUANQZGu8XJ6pDF7KSqbqKDxk2EzVNK7po3llMavonwq9JxHk8xoywqGhNoKLWbFlatzFx6fTqn%2BtLZBZcYzb/csSzWeq9t3ireaZw3EJGaxOX09YvlTZbCMIyIEed17qkdNbufSJ4hPWsLHzmnihehvy1xOPlmVX%2BjLnBHRX5mNgVdWednIL0duHduvvCOejxcn5QFTwaspWfeSXYXlNoMFrVfCvrv%2BscinLs2OvtUlBV3mijU2pnE0tmTn%2BZqpYCeht5cWA5VAPbz63mOEIAl9%2BNcYsrUAaZf51jiyzhBI%2BW0pH5kATshWsI0Ltl6rThYzCOYdgzaSRDEjOw/dNqJdK2k8Ut4t5uUvcgw4oryOrhQOJVaVcGX%2BvRVnwYzfeF5ryWFbfvlVp661XNlA7