On August 13, Shadowserver distributed a one-time report identifying about 296,000 IoT devices compromised by the Dysphoria botnet. The list covers routers, gateways, cameras, and other embedded Linux systems that can support distributed denial-of-service attacks or serve as residential proxies and relays.
The dataset is more than seven days old, yet it remains actionable. Shadowserver says newly subscribed network owners can request regeneration of recent special reports at no cost. The foundation created the retrospective dataset so constituents could act on incidents outside its usual 24-hour reporting window, describing the goal as “maximum public benefit.”
A retrospective list changes scope
Shadowserver marks every event in the Dysphoria report as critical. Each row can contain the affected IP address, port, protocol, autonomous system, location, sector, device vendor, model and version, plus first- and last-seen fields. That combination helps an owner move from a public IP to the equipment and service that need attention.
The report’s timestamp field does not record the observation time for each device. Shadowserver set it to 2026-08-12 00:00:00, the distribution date for the one-off dataset. Owners should use last_seen_time for the final event observed in that row.
This limits what the number proves. The report identifies about 296,000 devices seen as compromised in a retrospective collection. It does not establish that all remained online or infected on August 28.
CNCERT and XLab measured the botnet from a different vantage point and time window. Their research says Dysphoria exceeded 200,000 bots, with a daily peak of 239,000 online bots outside mainland China and 4,401 confirmed active bots inside mainland China during July 14–20. Those figures describe separate observations and should not be added to Shadowserver’s total.
Two roles share one fleet
XLab divided captured Dysphoria samples into two roles. One carries DDoS functions. The other drops the attack module and turns the infected host into a relay or proxy.
Both sample types alter their process name to resemble libdalvikengine.so. The DDoS variant uses a modified RC4 routine to recover protected strings. Its registration and heartbeat messages are fixed at 78 bytes, with distinct 12-byte magic values that defenders can search for in retained packet data.
The relay role changes the value of a compromised camera or router. On June 25, XLab captured a relay-only variant. By June 27 and 28, the family had added automated UPnP port mapping and a hybrid command path that placed infected systems between DDoS bots and the actual control infrastructure.
Figure details
A weak credential or known IoT flaw leads to one compromised router, gateway, camera, or embedded Linux device. Dysphoria then follows one of two source-observed roles. A DDoS sample receives attack commands and sends traffic toward a target. A relay-only sample uses UPnP to map 155 ports, listens for inbound traffic, and forwards each connection to a same-port remote endpoint.
XLab says weak Telnet and SSH credentials remain Dysphoria’s main infection path. Known IoT remote-code-execution flaws add another route. Across the XLab page and joint CNCERT and XLab report, the published partial lists span CNVD-2017-38447, CNVD-2018-01041, CNVD-2020-08128, CNVD-2020-35174, CNVD-2020-70958, CNVD-2021-79445, CNVD-2025-12011, CNVD-2025-29924, CVE-2013-3307, CVE-2016-20016, CVE-2017-17215, CVE-2017-5259, CVE-2018-14558, CVE-2020-25499, CVE-2020-8515, CVE-2022-35733, CVE-2025-9528, CVE-2025-28137, CVE-2025-34152, and CVE-2025-55182.
The cited sources do not map every identifier to an affected model, vulnerable build, and first fixed firmware. There is no universal Dysphoria fixed version. Each matched device needs its vendor’s model-specific supported release, and a later release supersedes an earlier fixed build. Unsupported hardware needs replacement.
The cited records do not report a coordinated response from the device vendors represented in the dataset.
Relays hide the control plane
Dysphoria uses Ethereum Name Service and Solana Name Service records to find infrastructure. A DDoS sample can query the node record for burrberry[.]eth, decode relay-distribution addresses, and request /nodes?key=meowmeowmeow over TCP port 9000. The response supplies another list of addresses for command traffic.
XLab found that the returned addresses were compromised hosts acting as relays. A relay sample searches the local network for a UPnP-capable gateway, creates 155 port mappings, and listens on those ports. When traffic arrives on a mapped port, the sample opens an outbound connection to the same port on the actual remote endpoint and binds the streams with Linux epoll.
The result is a moving layer of victim-owned infrastructure between the bot and its operator. Blocking one relay can interrupt one route while leaving the name record, distribution node, and other relays available.
XLab also observed relay status messages sent at intervals of at least four seconds to login[.]trees4sale[.]net:9000. A health message reports fields such as status, connections, and bandwidth_mbps. That cadence and destination can separate a quiet embedded appliance from one reporting its usefulness to a relay service.
Hunt the published signals
The values below are detection strings from the joint CNCERT and XLab report. The network destinations are defanged because the report treats them as Dysphoria infrastructure or compromised relays. They are search material, not acquisition links.
Process and protocol markers:
libdalvikengine.so
220 cool ftp server hosted on brian krebs' giant ass 4head
Login magic: 00 80 00 5a 00 57 00 c8 00 f0 00 1e
Heartbeat magic: 22 ba 15 24 1a 6f 04 d4 1f 9c 0d 06
GET /nodes?key=meowmeowmeow over TCP/9000IPv4 addresses:
217[.]60[.]195[.]160
76[.]164[.]203[.]171
92[.]42[.]100[.]131
78[.]153[.]155[.]152
144[.]31[.]38[.]215 (decoded relay-distribution example)Infrastructure and blockchain names:
i[.]peer4you[.]net
o[.]peer4you[.]net
login[.]trees4sale[.]net
www[.]trees4sale[.]net
c2[.]saintpetersburgresident[.]ru
peer[.]saintpetersburgresident[.]ru
kieron[.]androiddebugbridge[.]su
dysphoria[.]androiddebugbridge[.]su
telaviv[.]androiddebugbridge[.]su
jerusalem[.]androiddebugbridge[.]su
node[.]androiddebugbridge[.]su
wow[.]androiddebugbridge[.]su
m3rnbvs5d[.]eth
burrberry[.]eth
ukranianhorseriding[.]eth
24carnforth2merseyside[.]solAdditional control domains in the joint CNCERT and XLab report:
boblazar[.]inhumanencounters[.]org
roswell[.]inhumanencounters[.]org
www[.]c1s[.]su
www[.]oppenheimer[.]suSHA-1 sample hashes:
c1bedea261f325441fb9a75c50b11d0c8fb01ac6
a3b9575897c16cbf6afe3af1aa8b55171ea6edf9
8db6c78533c176f13b61405cdc3f8fad703325f1
9c1716d770ea69e8e1418d96d52222396ecb4362
73651c02b29f1c07e3177e86c967fc45e9f30f0f
955ff909972958098f0d4a06bcc4d6b9eea90449
25081bdec05f64eb4f313420c82d8de957e30026
dcea71b9ab9de8efca301de9e2f7bf11c7132364
df510f6f69a5c149c216c7b3accc4f460d8cf363
b0782a9d6eef2ce02f734a6e5e1d8e0f9a2b65be
e7e1694162639ed587625432a79cfaa49f560d11
b7faa44ab0772047a8581bbfdd9c561e28fc66de
e999d3d31c623ab5618b251c9b0e11f8ebcdde12
9311fb79fbfe1b180ed634315457212eb0fc885c
9ba9b4c24f1913a8644969a271f62b828e79f4c7
1b1ed06fdbe73446b1503c016be6c3bf5d8299e4
2f7f577d76df6db398a90e34b4d14907a25b1ff9An indicator hit establishes a scoping lead. Shared or reassigned IP addresses, stale observations, and compromised relays require asset ownership and time correlation before containment decisions.
Rebuild trust device by device
Start with the Shadowserver row. Resolve the public IP, port, last_seen_time, device fields, and network owner to a specific asset. Preserve firewall, NAT, DNS, DHCP, authentication, and packet records before rebooting or replacing it. The evidence should distinguish an exposed service from confirmed malware execution and show whether the device was an attack node, a relay, or only an address-match candidate.
Reset the device from trusted media or a vendor-supported recovery method. Install the vendor’s current supported firmware, rotate local and remote-administration credentials, remove unnecessary Telnet and SSH exposure, disable unnecessary UPnP mappings, and restrict outbound traffic for appliances that do not need arbitrary internet access. The cited sources publish no cross-vendor build matrix, so the remediation record should name the specific device model, prior build, installed build, and vendor advisory used.
A concrete verification test uses three evidence planes. The device inventory should show the intended supported firmware and fresh credentials; the gateway should show no unexpected mapped ports; retained network telemetry should show no matching 78-byte protocol messages, /nodes?key=meowmeowmeow requests, or status traffic to the published infrastructure. The expected result is a known device state with no recurring Dysphoria process or network behavior during the organization’s observation window.
A retrospective hit means the device entered an attacker-controlled fleet. Rebuilding trust requires evidence from the device, the network edge, and the vendor-supported firmware state. A quiet day after cleanup cannot supply that proof by itself.