QiAnXin XLab says a botnet called Dysphoria has grown to roughly 200,000 infected devices while splitting into two jobs: launching distributed denial-of-service attacks and hiding command infrastructure behind compromised relay nodes. The July 25 technical report, published jointly with CNCERT, documents malware samples, network messages, command infrastructure, infection paths and indicators collected since March.
The most useful finding for defenders is the relay variant introduced in late June. It asks a local UPnP gateway to create 155 port mappings, listens on the mapped ports and forwards each inbound connection to the same port on the operator’s remote server. A compromised router, camera or other embedded Linux device can therefore become an internet-facing relay even when it originally sat behind network address translation.
XLab measured the botnet through relays and controller data
XLab observed Dysphoria between July 14 and July 20. The researchers recorded as many as 239,000 daily overseas client connections and 1,801 active clients per day in China, with 4,401 Chinese clients confirmed during the observation period. They estimate the active bot population at around 200,000 after comparing their monitoring with an image of the botnet’s control panel.
That estimate is a researcher assessment. The report does not identify every device, owner or infection time, and a daily connection is not necessarily a unique device. The operator’s public claim of 4 Tbps in DDoS capacity is also an advertisement, not an independently measured attack result.
XLab says attacks occurred almost daily across internet services and gaming targets. Its samples accept commands containing an attack duration, method, targets and configurable flags. The researchers also found a separate sample, first captured on June 25, that had removed the DDoS code and kept only its relay function.
UPnP gives the relay 155 inbound paths
The relay sample broadcasts on the local network for a UPnP-capable gateway. It then asks the gateway’s WAN connection service to create 155 port mappings to the infected device. Each corresponding local listener accepts inbound traffic and opens an outbound connection to the same numbered port on the real remote server. Linux epoll handles the two directions without blocking.
Figure details
An external connection reaches a gateway on one of 155 ports that the Dysphoria relay sample mapped through UPnP. The gateway forwards that port to a listener on the infected Linux device. The device opens an outbound connection to the same port on the remote command server and binds both directions with epoll. A separate health report goes from the infected device to login.trees4sale.net on port 9000 at intervals of at least four seconds. The public-facing address therefore belongs to a compromised relay rather than necessarily identifying the operator's command server.
The sample sends a JSON health report to login.trees4sale.net:9000 at intervals of at least four seconds. XLab’s example includes online status, active connections and bandwidth. The design gives investigators three distinct places to look: gateway port mappings, listeners and outbound connections on the infected device, and frequent health traffic to the reporting domain.
Blockchain records lead to another layer of infected relays
Dysphoria also uses Ethereum Name Service and Solana Name Service records to locate infrastructure. XLab found the malware querying records associated with burrberry.eth, ukranianhorseriding.eth and 24carnforth2merseyside.sol. Data hidden inside IPv6-looking strings is transformed into IPv4 addresses.
The late-June DDoS sample first resolves the node record for burrberry.eth, decodes a list of distribution nodes, and sends an HTTP request to port 9000 for another address list. XLab says the returned command addresses were themselves compromised relay nodes. Blocking one visible endpoint may interrupt a connection while leaving the lookup path and the underlying command service intact.
The report publishes infrastructure domains, four IP addresses, sample hashes and a distinctive FTP banner. Those indicators are useful for scoping, but they are time-bound. The family changed domains, record keys and sample behavior several times between March and June.
Weak credentials and known flaws feed both botnet roles
XLab attributes propagation primarily to weak Telnet and SSH credentials plus known remote-code-execution flaws in routers, gateways, cameras and other embedded Linux devices. Its observed exploit list spans old and recent issues, including CVE-2017-17215, CVE-2020-8515, CVE-2025-28137, CVE-2025-34152, CVE-2025-9528 and CVE-2025-55182.
That mix changes the remediation problem. A network can block the published domains and still leave the original access path available. CISA’s exposure-reduction guidance calls for changing default passwords, applying current patches, replacing unsupported devices, monitoring access and reviewing ingress and egress traffic on internet-facing systems.
Defenders should verify the gateway, device and egress path
Start at the gateway. Export the active UPnP and static NAT tables, then investigate devices with a large block of unexpected mappings, especially a set approaching 155 ports. Disable UPnP where it has no documented owner or operational need. Remove unauthorized mappings and confirm from an external test point that the ports no longer accept connections.
On the mapped device, collect volatile evidence before resetting it when possible. Check for a process named libdalvikengine.so, an unusual set of listening sockets, same-port outbound sessions, and connections to the domains, IP addresses and port 9000 infrastructure in XLab’s report. Review DHCP, DNS, firewall, flow, Telnet and SSH records to identify the device, initial access and other systems reached from the same source.
Patch the model-specific vulnerabilities that apply, replace weak or default credentials, disable unneeded Telnet, SSH and remote administration, and install a vendor-trusted image. Factory reset or replace a device when its firmware cannot be verified or is no longer supported. Rotate any credentials that crossed the device or were used to administer it.
Close the incident only after the gateway has no unauthorized mappings, an outside scan confirms that the 155-port exposure is gone, the device runs a trusted supported image with unique credentials, and DNS and flow monitoring show no further Dysphoria infrastructure or relay traffic. Missing gateway history, device logs or a trusted firmware baseline leaves the device’s prior activity unresolved.