RustDuck Botnet: Rust Rewrite Supercharging IoT DDoS Operations
Hey folks,
Been tracking the new RustDuck botnet that QiAnXin's XLab surfaced this week, and the speed of evolution here is what's catching my attention — not necessarily the current node count.
What We Know So Far
RustDuck is a two-stage malware family actively compromising:
- Home routers (multiple vendor models with weak Telnet/SSH credentials)
- IP cameras (especially older Hikvision/Dahua firmware)
- Android TV boxes
- Poorly secured Linux servers
The researchers have been tracking it since February 2026, and the Rust rewrite appears to be a deliberate port from a prior C-based variant. The cross-compilation benefits of Rust make targeting diverse ARM/MIPS/x86 IoT architectures trivial — which explains the broad device profile.
Stage 1: Initial Access & Loader
The first stage is a lightweight loader that fetches the Stage 2 payload after architecture fingerprinting. Default credential brute-forcing on Telnet (23) and SSH (22) appears to be the primary ingress vector.
Quick detection for SOC teams — look for brute-force patterns followed by unexpected outbound fetches:
DeviceProcessEvents
| where InitiatingProcessFileName in ("telnetd", "sshd")
| where ProcessCommandLine has_any ("wget", "curl", "tftp")
| where RemoteUrl !endswith any (".deb", ".rpm", ".pkg")
| summarize count() by DeviceName, RemoteUrl, bin(TimeGenerated, 5m)
| where count() > 3
Stage 2: DDoS Engine
The second stage is the actual bot client — UDP/TCP flood modules with multi-arch support. The Rust binary is statically compiled and stripped, making reverse engineering significantly harder than its C predecessor.
If you're running Suricata, here's a basic rule to catch the payload fetch pattern:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"RustDuck Stage 2 Payload Fetch"; flow:established,to_server; content:"GET"; http_method; content:"/stage2/"; http_uri; pcre:"/\/stage2\/(arm|mips|x86|aarch64)/Ui"; classtype:trojan-activity; sid:2026006; rev:1;)
Key Concerns
- Rust makes reversing painful — stripped Rust binaries with monomorphized generics are notoriously hard to analyze in IDA/Ghidra compared to C.
- Speed of iteration — XLab noted the codebase is changing rapidly, suggesting active development and possibly multiple operators.
- IoT patching reality — most affected devices will never receive firmware updates.
Discussion
For those of you managing IoT fleets or running honeypots — are you seeing Rust-based payloads more frequently this year? And has anyone had success with automated Rust binary deobfuscation workflows? Curious what tooling people are leaning on when Ghidra's analysis falls flat on stripped Rust binaries.
Stay vigilant, — @threatforge
Good breakdown. We've been running a cluster of Telnet honeypots (Cowrie + Telnet honeypot variants) and the shift to Rust-based payloads is real — caught three distinct binaries in May alone that were Rust-compiled. For reversing, I've had decent results with rust-reverser-helper scripts for Ghidra that annotate the std library calls and clean up some of the monomorphization noise. Not perfect, but it cuts analysis time meaningfully. Also worth noting: the Android TV box angle is underreported. We're seeing a lot of cheap Chinese generic boxes with open ADB on 5555 getting scooped up. If you haven't scanned your network for port 5555, do it yesterday.
MSP owner here — this is a nightmare for us on the router side. Half our SMB clients are running consumer-grade gear we don't manage, and they're not replacing it until it dies. We've started pushing Ubiquiti across the board just to get consistent firmware lifecycle management. One thing I'd add to the detection side: if you have access to NetFlow/sFlow, watch for sustained outbound UDP on non-standard ports from IoT subnets. That's been our most reliable DDoS-participation signal. We trigger on >50KB/s sustained UDP from any device in the IoT VLAN for more than 60 seconds.
From a pentest perspective, the two-stage architecture is smart from an OPSEC standpoint — Stage 1 is tiny and looks like noise, so it flies under EDR/network monitoring that would flag a full payload pull. I've been testing similar loader patterns in engagements and most SOC teams miss the initial fetch entirely. For SOC analysts reading this: the key indicator is the sequence — brute force attempt → successful auth → immediate outbound fetch to a non-standard port. Correlate those three events and you'll catch it. Sigma rule for Splunk environments:
splunk index=firewall (action=success AND dest_port IN (22,23))
| join src_ip [search index=network sourcetype=zeek_http | stats count by src_ip, uri]
| stats count by src_ip, dest_ip, uri
One angle we've found useful for detection at the network level: RustDuck's Stage 2 beaconing has a fairly distinctive pattern — short TLS connections to a rotating set of VPS hosts, typically on non-standard ports (8080, 8443, 9999). We've had decent luck catching it with this KQL query in Sentinel:
DeviceNetworkEvents
| where RemotePort in (8080, 8443, 9999)
| where RemoteIPType == "Public"
| summarize ConnectionCount = count(), DistinctPorts = makeset(RemotePort) by DeviceName, RemoteIP, bin(TimeGenerated, 5m)
| where ConnectionCount > 10 and array_length(DistinctPorts) >= 2
Has anyone started mapping the C2 infrastructure? The IPs we're seeing cluster heavily in a few Bulgarian and Romanian hosting providers, but I'd like to cross-reference before publishing IOCs.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access