On the morning XLab named a new Rust botnet, its home network was already one of the busiest attackers on our decoy fleet. Here is the first party view, including the honest limits, and the moment our own endpoint protection quarantined the evidence.
RustDuck's implant lives in 176.65.139[.]0/24. That exact network is one of the busiest attackers on our live decoy fleet right now: 28 source addresses and about 130,000 events in a single day. The files we have actually captured from these networks are Panchan, RedTail, and Mirai, not RustDuck itself. We have the neighborhood and the method, not a confirmed sample.
This morning XLab published the first deep public analysis of a new botnet it calls RustDuck. A few hours later we went looking for it in our own data. We did not have to look hard. The network RustDuck operates from was already one of the busiest attackers on our decoy fleet, and it has been for months.
In XLab's telling, RustDuck is a two stage botnet written in Rust. The loader pulls and verifies a core implant, the core speaks to its operators over command and control domains hosted on dynamic DNS, and the whole thing spreads the old fashioned way, by guessing weak SSH and Telnet passwords on anything exposed to the internet. The researchers named it RustDuck because it encrypts three of its DuckDNS control domains. Its main implant is served from the address 176.65.139[.]204, and its control domains follow a deliberately juvenile and offensive naming pattern that we will not reproduce here.
If that profile sounds familiar, it should. Weak credential spreading, cross architecture payloads, and dynamic DNS command and control are the shared grammar of the internet's IoT and Linux botnets. RustDuck's twist is the move to Rust and the two stage, self verifying design. The behavior at the door, though, is something our sensors see constantly.
Deception Check runs a fleet of eighteen decoy nodes spread across several clouds and regions. Some are classic Cowrie SSH and Telnet traps. Others are language model backed decoys that imitate real equipment under hostile probing, including a Fortinet FortiGate, a Cisco SD-WAN manager, a hospital imaging server, an enterprise identity provider, a Lantronix device server, and a set of operational technology controllers for water, solar, building management, and power. When an attacker reaches one of these, we record the session.
So when a writeup names an attacker's home network, we can simply ask our own logs whether we have seen it.
RustDuck's implant lives in the 176.65.139[.]0/24 network. That exact block is, right now, one of the most active sources hitting our fleet.
In today's data we counted twenty eight distinct source addresses inside that /24, together generating roughly one hundred and thirty thousand events in a single day, landing on every one of the edge decoys. The neighboring 176.65.132[.]0/24 was active as well. To be sure this was current and not an artifact of an old export, we connected to two live nodes directly and read the running logs. At 20:28 UTC the United States control node's active session log held twenty two distinct addresses from that block. The FortiGate decoy showed just over three thousand events from it, led by two addresses hammering it in lockstep.
This is not a one day spike. The same network shows up in our April capture, where a single address in 176.65.132[.]0/24 made 11,754 login attempts against one sensor, working through the same tired guesses, root with the password 123456, admin, ubuntu. Another address, one hop away inside RustDuck's own /24, logged in and immediately fetched a cross architecture loader, downloading builds for ARM, MIPS, PowerPC, SuperH, and x86 in turn and launching each with an SSH spreading argument.
Our honeypots do not just log commands. They capture the files attackers try to plant. From the April window we pulled thirteen artifacts and verified each by its cryptographic hash. The haul is a good cross section of the current Linux botnet scene. There is a thirty megabyte Go worm that public reporting ties to the Panchan peer to peer family. There are several statically linked bots compiled for x86, ARM, and ARM64, built in the Mirai and Gafgyt mold. There are two Bash scripts, one a spreader from the RedTail cryptomining campaign, the other a cleanup tool that evicts rival miners and scrubs the crontab. And there are attacker SSH keys, dropped for persistence.
Here is the honest part. None of those captured files is RustDuck. They are its neighbors, not the duck itself. They arrive from the same networks, they use the same front door, and they belong to the same class, but the binaries in our hand today are Panchan, RedTail, and Mirai derivatives.
There is a small, telling footnote to this analysis. While we were extracting one of those captured loaders to inspect it, Windows Defender reached into the working folder and quarantined it, classifying it as a shell based trojan downloader. Our endpoint protection removed a piece of our evidence in the middle of the investigation.
We want to be precise, because precision is the whole value of first party data. We have not captured a confirmed RustDuck binary. We have not seen its exact implant address or its named control domains cross our sensors. Our strongest statement is this. The infrastructure RustDuck operates from, and the exact techniques XLab describes, are present and busy in our telemetry, today and for months past. That is corroboration of the campaign's neighborhood and method. It is not a trophy. Anyone who tells you that behavioral and network overlap equals a confirmed sample is selling something.
The lesson is unglamorous and durable. The front door is still a weak password on an exposed SSH or Telnet service. RustDuck, Panchan, RedTail, and the whole Mirai family all walk through it.