Dysphoria Botnet Infects 296,000 IoT Devices, Hides C2 in ENS and SNS Records
A home router can appear entirely functional – broadcasting Wi-Fi and sitting quietly on a shelf for years – while silently routing someone else’s attack traffic. Researchers have identified approximately 296,000 devices infected with the Dysphoria botnet. The affected population spans routers, gateways, IP cameras, and other Linux-based hardware, all of which threat actors are leveraging for DDoS attacks and as covert proxy servers.
Shadowserver Rates the Threat as CRITICAL
The Shadowserver Foundation published the new findings, assigning every documented infection the maximum CRITICAL severity rating. The true scale of the botnet significantly exceeds earlier estimates. In late July, researchers at XLab and CNCERT reported more than 200,000 devices under Dysphoria’s control, with the number of simultaneously active infections outside China peaking at 239,000 on certain days.
How Dysphoria Spreads: Familiar IoT Attack Vectors
Dysphoria propagates through methods well established among IoT botnets. The malware brute-forces weak Telnet and SSH passwords and exploits known remote code execution vulnerabilities. Its targets include home and office routers, network gateways, cameras, and other devices that frequently run outdated firmware with internet-exposed management interfaces for years at a stretch. Researchers found both long-documented vulnerabilities that botnets have exploited for years and more recently disclosed flaws within Dysphoria’s exploit arsenal.
Blockchain-Based Command Infrastructure: ENS and SNS
Dysphoria’s defining characteristic has less to do with its infection count than with how its command infrastructure is architected. Rather than relying on conventional domains, the botnet’s creators adopted the Ethereum Name Service (ENS) and Solana Name Service (SNS). The malware resolves the addresses of its required communication infrastructure through ENS and SNS records. This approach substantially complicates takedown efforts, since defenders cannot simply request that a registrar suspend a conventional domain name.
Layered Obfuscation: Infected Devices as Relay Nodes
Dysphoria’s operators have added a further layer of concealment. Infected devices can themselves function as intermediary nodes positioned between bots and the genuine command-and-control servers. When analyzing network traffic, a researcher observes the address of another compromised device rather than the operators’ actual server – a scheme that substantially complicates efforts to locate and block the underlying infrastructure.
An Evolution Toward Pure Proxy Infrastructure
In late June, the developers pushed this concept further still. Researchers discovered a distinct Dysphoria variant entirely lacking DDoS attack functionality. The infected device’s sole purpose in this version was to operate as a proxy and traffic relay. Days later, automatic port-forwarding configuration via UPnP appeared, allowing the malware to bypass NAT restrictions and accept inbound connections from external sources.
As a result, an ordinary home IP address can now serve as an intermediary point for someone else’s traffic entirely. This grants attackers the ability to conceal the true origin of a connection, circumvent IP-based restrictions, or hide command-and-control servers behind the networks of unsuspecting device owners. Dysphoria is thus gradually transforming from a conventional DDoS botnet into a distributed infrastructure built from residential proxy servers.
A Commercial DDoS-for-Hire Operation
The project carries a commercial dimension as well. On a page researchers have linked to Dysphoria, the operators advertised DDoS attack capacity of up to 4 Tbps and offered paid tiers priced according to attack duration and bandwidth. XLab observed near-daily attacks, with targets spanning internet services and gaming platforms across multiple countries.
Recommended Mitigation Steps
Shadowserver recommends that owners and administrators of potentially affected devices update device firmware, change administrative passwords along with Telnet and SSH credentials, disable unnecessary remote access and UPnP, and audit existing port-forwarding rules. Older devices no longer receiving security updates from their manufacturer should be replaced entirely.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
