A sophisticated new botnet family dubbed RustDuck emerged in early 2026, leveraging a two-stage Loader and Core architecture to compromise IoT devices, routers, and enterprise servers through brute-force credential attacks and remote code execution vulnerabilities.
RustDuck employs a multi-pronged infection strategy combining weak password attacks against Telnet and SSH services with exploitation of known RCE vulnerabilities across diverse device ecosystems.
The botnet targets Android ADB interfaces, TVT API endpoints, and devices from manufacturers including Ruijie, TP-Link, and ZTE, alongside web application vulnerabilities in ThinkPHP, Jenkins, and YARN components.
Historical CVEs such as CVE-2025-29635, CVE-2017-17215, CVE-2018-8007, and CVE-2024-1781 are actively weaponized to expand the attack surface.
This hybrid approach enables large-scale automated intrusion across routers, IP cameras, Android terminals, and server environments, with over 20 IPs observed participating in propagation efforts, most notably 176.65.139.204.
The Loader stage follows a streamlined three-component design comprising loading code, compressed core data, and configuration information appended as overlay data in ELF files.
Discovered by Qianxin’s XLAB in February 2026, RustDuck represents a significant evolution in botnet engineering, transitioning from C to Rust while implementing advanced anti-analysis techniques and robust traffic encryption.
Reverse engineering reveals four distinct evolutionary stages with progressively sophisticated encryption and obfuscation techniques.
RustDuck Botnet Targets IoT Devices
Variant 1 employs LCG pseudo-random generation with XOR decryption and LZ4 decompression, implementing dynamic magic verification through ROL4 combined with XOR operations.
Variant 2 introduces Xoshiro128 encryption with BLZ decompression and hard-coded constants that vary dynamically across samples, significantly complicating static batch decryption efforts. Variant 3 reverts to standard XOR with LZ4 but adopts fixed plaintext magic strings for verification.
The most advanced Variant 4 integrates ChaCha20 stream cipher encryption while maintaining LZ4 decompression, indicating a clear trajectory toward stronger cryptographic primitives. Detailed technical specifications for each loader variant are documented.
The Rust-based Core module demonstrates exceptional engineering complexity in key derivation, anti-debugging mechanisms, and communication protocols.
Key generation uniformly implements HKDF-SHA256 with two coexisting sources: UTC time-based dynamic keys that refresh every 10 minutes to counter replay attacks, and Curve25519 asymmetric key exchange using Noise_IK_25519 architecture for forward secrecy.
Symmetric encryption branches into two implementations, with one using permuted Ascon128 lightweight encryption and another employing ChaCha20-Poly1305 during handshake transitioning to AES-GCM for compliant sessions.
RustDuck incorporates a dynamic weight scoring mechanism for environment validation,_accumulating risk points across multiple detection vectors.
Analysis tools scanning for Wireshark, GDB, IDA, and Frida processes assign a 100 risk weight, as do debug checks reading /proc/self/status for non-zero TracerPid values and library checks parsing /proc/self/maps for injection frameworks.
SHA256 checksum verification detects file modifications from reverse engineering, while honeypot checks search for Cowrie and Dionaea configurations.
Additional countermeasures include network blackhole detection connecting to reserved IP 192.0.2.1, dual clock source time travel checks preventing sandbox acceleration, and virtualization hardware fingerprinting through DMI information and VM-specific MAC address OUI prefixes.
When accumulated risk exceeds preset thresholds, the malware automatically erases traces and terminates execution.
The network protocol deeply references the Noise framework’s IK pattern, deriving session keys through ECDH using hardcoded server static public keys and runtime-generated ephemeral keys.
A global MsgID participates in message sequencing and rolling key generation, preventing network-side decryption using plaintext keys.
The handshake phase employs ChaCha20 transport encryption with four-step compliance verification including login, verify, confirm, and acknowledgement messages.
Post-handshake command loops switch to AES-GCM with independent uplink and downlink key separation, splitting the derived 88-byte aesGCMKey into distinct clientKey, clientNonceKey, serverKey, and serverNonceKey components to maximize MITM resistance.
While RustDuck’s current DDoS activity levels remain below mainstream botnets, its rapid technological evolution and comprehensive C-to-Rust migration warrant significant security attention.
The cross-platform adaptability combined with continuous iteration of anti-defense and traffic encryption techniques positions RustDuck as an emerging threat requiring proactive monitoring and defensive posture adjustments across IoT and enterprise infrastructure.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
