Summary
- Palo Alto Networks’ Unit 42 identified a new Kimwolf botnet version active since February 2026, a month before authorities seized its previous infrastructure.
- The botnet now mimics Chrome browser behaviour over HTTP/2, making its flood traffic difficult to distinguish from legitimate user requests.
- Command-and-control addresses are hosted on the Ethereum blockchain via the Ethereum Name Service, placing them outside the reach of registrar-level law enforcement orders.
- A hardcoded Tor hidden service acts as a fallback if all five ENS addresses fail, concealing the server’s physical location.
- Infrastructure analysis points to servers located in a single network registered in Saint Petersburg, Russia.
A botnet engineered around law enforcement playbooks
The Kimwolf botnet — which splintered from the record-setting Aisuru DDoS operation — is back, and its developers appear to have studied exactly how previous versions were dismantled. Researchers at Palo Alto Networks’ Unit 42 published findings Tuesday describing a new iteration that was already operating in February, one full month before international authorities seized Kimwolf’s infrastructure in March. The rebuilt version carries two significant architectural changes designed to make both detection and disruption considerably harder.
HTTP/2 floods that look like Chrome
The most operationally significant change is a new flood method built on HTTP/2, the protocol that carries the majority of today’s web traffic. Earlier botnets typically fired raw packets that security tools could identify and filter. This version operates differently: each infected device — drawn primarily from hijacked Android TV boxes and other internet-connected consumer hardware — sends requests with full browser fingerprints, replicating the header order and behaviour of the Chrome browser.
The consequence for defenders is straightforward and uncomfortable. Standard DDoS mitigation relies on distinguishing bot traffic from legitimate users. When the bot traffic is indistinguishable from Chrome, a targeted server faces a binary choice: serve every request and collapse under the load, or begin blocking traffic that may belong to genuine customers. Neither outcome is acceptable, and that is precisely the point.
Blockchain-based command infrastructure
The second change addresses resilience against takedown operations. Conventional botnets embed a domain name in their malware to locate the command-and-control server. Investigators can approach the domain registrar, seize the record, and effectively cut communications across the entire network. This Kimwolf version removes that option entirely.
Instead, the malware resolves its command address through the Ethereum Name Service (ENS), a directory that operates on the Ethereum blockchain. Unlike a conventional domain, an ENS record sits in a ledger distributed across thousands of computers worldwide. There is no registrar to serve with a legal order and no single record to seize. The malware carries five public Ethereum gateway addresses and randomises the order before each lookup attempt, adding a further layer of friction for blocking tools.
Tor as the last line of defence for the operators
Should all five ENS addresses become unreachable, the malware falls back to a hardcoded Tor hidden service address. Tor resolves the address through its own network rather than the conventional domain system, and it conceals the physical location of the server from investigators. There is, by design, no hosting provider to contact.
Infrastructure and attribution
Unit 42’s infrastructure analysis found that four of the command servers share an SSH host key, and further examination placed them within a single network registered in Saint Petersburg, Russia. Whether this version was built by the same people behind previous Kimwolf iterations or by a new group capitalising on the botnet’s established reputation among malicious actors is, according to the researchers, not yet clear. A Canadian man alleged to have operated previous versions was arrested in May and extradited to the United States, though that arrest has evidently not halted development.
Context and reach
Kimwolf drew broad attention from the security research community when it briefly claimed the top position in Cloudflare’s global domain rankings in late October 2025, a reflection of the sheer volume of traffic its infected devices can generate. The botnet’s primary infection pool — consumer Android TV boxes and other internet-connected devices — represents a population that is rarely patched, often forgotten by its owners, and typically outside any enterprise security perimeter.
Why it matters
This rebuild represents a deliberate response to law enforcement methodology, not simply a technical upgrade. By anchoring command infrastructure in a decentralised blockchain service and layering Tor as a fallback, the operators have eliminated the two most reliable levers authorities have used to disrupt botnets: registrar seizure and hosting provider cooperation. Simultaneously, HTTP/2 mimicry degrades the effectiveness of conventional DDoS mitigation tools. For CISOs, the practical implication is that the cost of defending against a Kimwolf-style attack is rising, because traffic scrubbing tools calibrated for earlier attack signatures may not distinguish this traffic cleanly, and because the infrastructure powering the attacks is now materially harder to take offline through law enforcement channels.
What to do now
- Review your DDoS mitigation provider’s capability to detect and rate-limit HTTP/2 floods that carry full browser fingerprints, and ask specifically whether Chrome-mimicking traffic is handled differently from other bot patterns.
- Assess whether your organisation’s perimeter or CDN tooling currently blocks or monitors ENS resolution attempts, which may indicate botnet-infected devices on or connected to your network.
- Evaluate exposure from consumer or unmanaged IoT devices — including Android TV hardware — that may connect to your network or be used by staff in hybrid environments, as these represent the primary infection pool for this botnet.
- Engage your DDoS mitigation vendor to confirm their detection logic has been updated to account for HTTP/2-based floods with legitimate-looking browser headers.
- If your organisation has faced DDoS incidents previously, revisit incident response runbooks to account for scenarios where traffic cannot be cleanly separated from legitimate user requests — the binary blocking decision this botnet forces on defenders warrants a prepared response.
