RustDuck: An In-Depth Analysis of a Two-Stage Botnet

Overview

Since February 2026, the XLAB large-scale network threat perception system has detected a new malware family active in cyberspace that adopts a Loader + Core (two-stage loading) architecture. Currently, the family has spawned multiple variants, with the main core functionality being the execution of large-scale Distributed Denial-of-Service (DDoS) attacks. It also possesses strong cross-platform adaptability and continuous evolution capabilities.

Although the family's current activity level and influence in DDoS attacks are not yet comparable to some mainstream botnets, its speed of technological evolution deserves significant attention. Research has found that the family is undergoing a comprehensive technological transition from C to Rust , and its anti-defense and traffic encryption techniques are also iterating rapidly. Based on the shift of its technology stack from C to Rust and the characteristic of early core payloads encrypting three duckdns C2 domains, we have named it RustDuck.

Attack Incident Trend

In terms of sample propagation, the spread chain of this family mainly covers IoT devices, web applications, and enterprise infrastructure. The attack methods primarily involve weak password brute-forcing (Telnet/SSH) and the exploitation of various RCE vulnerabilities, including device vulnerabilities in Android ADB, TVT API, Ruijie, TP-Link, ZTE, and others, as well as web/component vulnerabilities such as ThinkPHP, Jenkins, YARN. It also combines several historical CVEs (CVE-2025-29635, CVE-2017-17215, CVE-2018-8007, CVE-2024-1781) to expand the attack surface. Overall, it presents a combined propagation characteristic of "weak passwords + IoT vulnerabilities + Web RCE", capable of covering routers, cameras, Android terminals, and server environments, enabling large-scale automated intrusion and payload delivery. Currently, over 20 IPs have been observed participating in spreading the RustDuck botnet, with the most active implant source IP being: 176.65.139[.]204

Sample Analysis

1. Evolution and Clustering Analysis of the Loader

Loader-stage samples typically adopt a streamlined three-part design: Loading Code , Compressed Data (Compressed Core) , and Configuration Information (Config) .

Its classic file layout is as follows: the loading code resides in the code segment at the beginning of a standard ELF file, while the core compressed data and configuration information are appended as overlay data at the end of the file.

By performing structured reverse engineering on the configuration information (Config) at the file tail, we can clearly cluster the family's Loader into the following four evolutionary stages:

Stage<br>SHA1 (first 8 chars)<br>Config Size<br>Decryption Algorithm<br>Decompression Algorithm<br>Magic Verification Feature

Loader Variant 1<br>8315f650<br>16 bytes<br>LCG + XOR<br>LZ4<br>Dynamic verification (ROL4 + XOR)

Loader Variant 2<br>6aa791c7<br>33 bytes<br>Xoshiro128 + XOR<br>BLZ<br>Introduces dynamic constants

Loader Variant 3<br>4d11bd49<br>48 bytes<br>Standard XOR<br>LZ4<br>Fixed plaintext "ASHPCK\x01\x00"

Loader Variant 4<br>d39a3ee9<br>32 bytes<br>ChaCha20<br>LZ4<br>Fixed plaintext "iEMPK\x02\x00\x00"

1. Loader Variant 1

SHA1: 8315f650e9e4f67c00277b076ab304eed23db47d

Config Size: 16 bytes (equally divided into 4 fields, each 4 bytes)

Memory Layout:

+--------------+-------------------+---------------------+--------------+<br>| Key (4B) | Compress_Size(4B) | Decompress_Size(4B) | Magic (4B) |<br>+--------------+-------------------+---------------------+--------------+

Magic Verification Algorithm: Introduces cyclic left shift (ROL) and XOR combined verification:

comperss_size ^ decompress_size ^ ROL4(key, 13) ^ 0x5A3C9E7F == magic

Encryption/Decryption and Decompression: Uses a Linear Congruential Generator (LCG) to generate a pseudo-random number sequence for XOR decryption, followed by LZ4 decompression.

2. Loader Variant 2

SHA1: 6aa791c76b3107fca9d57b7ecea8f46d97d83738

Config Size: 33 bytes

Memory Layout: +---------------+-------------------+---------------------+---------------+---------------+<br>| Key (16B) | Compress_Size(4B) | Decompress_Size(4B) | Magic (8B) | Noise_Size(4B)|<br>+---------------+-------------------+---------------------+---------------+---------------+

Encryption/Decryption and Decompression: Upgraded to Xoshiro128 + XOR decryption, with the decompression algorithm changed to BLZ .

Countermeasure Characteristics: This variant introduces multiple hard-coded constants to obfuscate the decryption and Magic verification process. Since the constants vary dynamically across different samples, it is extremely difficult for security researchers to perform static batch decryption.

3. Loader Variant 3

SHA1: 4d11bd496da82d15b3ed13050f414e44f5a892d4

Config Size: 48 bytes

Memory Layout: +-------------------+---------------------+-------------------------------+---------------+<br>| Compress_Size(4B) | Decompress_Size(4B) | Key (32B) | Magic (8B)...