When the DDoS Traffic Arrived, the Botnet Had Already Been Running for Weeks
In early 2025, security researchers confirmed that WSzero, a DDoS botnet family propagating through 21 distinct vulnerabilities, had reached its fourth major version. By the time most organizations noticed anomalous outbound traffic from infected hosts, the botnet's command-and-control infrastructure had already rotated through three different hosting providers and was actively recruiting new nodes through a mix of known CVEs targeting edge devices and IoT firmware. The detection window that most teams were working with was roughly two to three weeks behind the actual infection timeline.
This gap between infection and detection is not unique to WSzero. It is the defining challenge of botnet operations in 2025, and it shapes every practical decision about how to track, contain, and ultimately disrupt botnet activity before the damage compounds. This article walks through the operational methodology for tracking botnet infrastructure from first beacon through takedown, drawing on current threat intelligence across WSzero, the resurgence of HIVE-derived attack kits, and the persistent threat posed by peer-to-peer botnets that have survived repeated law enforcement actions.
Understanding the Botnet Lifecycle Before You Start Tracking It
Effective botnet tracking requires understanding what you are actually following. A botnet is not a static list of infected IPs. It is an evolving infrastructure with several distinct layers: the initial exploit delivery mechanism, the loader or dropper stage, the C2 communication channel, and the tasking layer where the botnet receives instructions for DDoS, credential theft, cryptomining, or data exfiltration.
Each layer leaves different forensic artifacts and requires different tracking techniques. Security teams that focus exclusively on traffic-level indicators, blocking IPs that show up in DDoS flows or scanning patterns, are tracking the outermost symptom while the underlying infrastructure continues operating untouched. The WSzero case illustrates this clearly. The botnet's longevity across four versions came from the operators' ability to rapidly swap out C2 endpoints while keeping the propagation and loader infrastructure largely consistent.
A complete tracking methodology needs to address all four layers simultaneously, correlating intelligence across them to build a picture of the botnet's actual operational posture.
Layer 1: Exploit Delivery and Initial Compromise
WSzero spreads through 21 documented vulnerabilities, targeting devices where patching cycles are slow or nonexistent: routers, NVRs, IP cameras, and industrial control system interfaces. The Kaspersky ICS CERT Q1 2026 threat landscape report identified similar patterns in attacks against industrial automation environments, where legacy device fleets create persistent footholds for botnet recruitment that persist long after the initial campaign ends.
Tracking at this layer means monitoring honeypot logs, vulnerability exploitation telemetry, and dark web forums where new CVE weaponization is discussed and shared before public disclosure. Tools like Shodan and Censys provide broad visibility into exposed devices, but operationally useful tracking requires correlation between what is exposed and what is actively being scanned or probed. Configure your honeypot infrastructure to emulate the specific firmware versions that WSzero and similar families target, then feed that telemetry into your SIEM with enrichment from threat intelligence platforms.
The practical output at this layer is a list of vulnerable device classes in your environment with associated CVE mappings, prioritized by active exploitation status rather than CVSS score alone.
Layer 2: Loader and Dropper Behavior
Once a device is compromised, the botnet deploys a loader that retrieves the main payload. The Xdr33 variant, derived from the CIA's HIVE attack kit, uses an encrypted communications protocol at this stage that blends with legitimate HTTPS traffic. Detecting loader activity requires deep packet inspection at the network boundary combined with endpoint telemetry showing unusual process execution chains on compromised devices.
Practically, this means deploying sensors that can identify beaconing behavior: regular, low-volume outbound connections to IP ranges that have no business justification. Xdr33's BEACON protocol, as analyzed by researchers, uses a jitter mechanism to avoid precise interval detection, but the statistical signature of jittered beaconing is still distinguishable from organic traffic when you have sufficient baseline data. Establish traffic baselines for every device class on your network, paying particular attention to OT and IoT segments where communication patterns are normally predictable and low-volume.
Command-and-Control Infrastructure Tracking in Practice
C2 tracking is where botnet hunting gets operationally complex. Modern botnet operators use a mix of bulletproof hosting, fast-flux DNS, domain generation algorithms, and increasingly, legitimate cloud infrastructure to host their C2 endpoints. The lone-attacker AWS compromise reported in mid-2025, where an attacker leveraged AI-assisted reconnaissance to breach a cloud environment within 72 hours, demonstrated how quickly cloud resources can be weaponized as C2 staging infrastructure before account abuse detection triggers.
The Gamaredon group's 2025 operational playbook provides a useful reference point. Researchers documented their use of Cloudflare Workers as C2 relays, DNS-based dead drops for IP distribution, and Telegram channels as backup communication channels. Each of these represents a different tracking problem requiring a different toolset.
DNS-Based Dead Drop Resolution
DNS dead drops use legitimate services like Pastebin, GitHub Gist, or custom records to store current C2 IP addresses. The infected host resolves these records at startup to find the active C2 endpoint. Tracking this requires passive DNS monitoring to identify domains that exhibit consistent lookup patterns from known botnet-infected IP ranges. Tools like Farsight DNSDB, PassiveTotal, and VirusTotal's passive DNS corpus allow analysts to pivot from a known infected host to the domains it resolves, then forward-track to other hosts resolving the same domains.
The operational workflow here is: infected host IP leads to DNS query logs, DNS query logs reveal drop domain, drop domain resolution history reveals all hosts that queried it, and cross-referencing those hosts against threat intelligence identifies additional compromised nodes in the botnet's fleet.
Fast-Flux and P2P C2 Architectures
The P2P botnets review published in 2025 highlighted a critical gap in traditional C2 takedown strategies. P2P botnets like Emotet's successor variants use infected nodes themselves as C2 relays, making there no single takedown point. Each node maintains a partial list of peers and routes traffic through multiple hops. Tracking these networks requires sinkholing individual nodes, monitoring the resulting peer list exchanges to map the network topology, and coordinating with hosting providers and CERTs across multiple jurisdictions to execute synchronized takedowns.
This is not a task that a single organization can accomplish alone. The practical implication for enterprise security teams is that your contribution to P2P botnet disruption is primarily about isolation: identifying and quarantining infected nodes in your environment, sharing those indicators with your ISAC or threat intelligence sharing partners, and ensuring that your infected nodes cannot relay traffic for other botnet operations.
Building Passive Detection Infrastructure
Active botnet hunting requires passive detection infrastructure that runs continuously in the background, generating indicator streams that your analysts can triage. The components of this infrastructure break down into three categories.
Network Flow Analysis
NetFlow or IPFIX data from your edge routers, combined with enrichment from threat intelligence feeds, provides the foundational dataset for botnet detection. Configure your flow collector to flag outbound connections to IP ranges associated with known bulletproof hosting providers, Tor exit nodes, and ASNs with high abuse scores. The key tuning challenge here is reducing false positives from legitimate CDN traffic and cloud services that share IP space with abusive infrastructure.
Use a tiered reputation scoring approach: flag but do not block traffic to medium-confidence indicators, and route those alerts to a threat hunting queue for manual review. Block only high-confidence indicators with multiple corroborating data sources. This prevents the operational disruption that comes from over-aggressive blocking while ensuring that your detection coverage is comprehensive.
Honeypot Networks for Early Warning
Deploy honeypots emulating the specific device types targeted by active botnet campaigns. For WSzero specifically, this means deploying honeypots mimicking Netgear, D-Link, and Hikvision firmware interfaces, using tools like Cowrie, Dionaea, or HoneyTrap configured with appropriate banners and response profiles. Log all interaction data including payloads, and extract C2 URLs, IP addresses, and file hashes from delivered payloads automatically using sandbox detonation.
The value here is early indicator generation. A WSzero variant probing your honeypot today is providing you with C2 infrastructure indicators that you can use to hunt in your production environment immediately, before any production hosts are compromised.
Malware Sample Analysis Pipeline
Establish an automated pipeline for processing botnet malware samples: YARA-based classification, static analysis for embedded C2 configurations, and dynamic analysis in isolated sandboxes for runtime C2 communication extraction. The Vidar Stealer analysis published in 2025, which identified code signing certificate abuse and Go-based loaders used to inflate file sizes and evade hash-based detection, is a reminder that modern malware analysis requires dynamic detonation because static signatures are increasingly insufficient.
Feed extracted C2 configurations directly into your network blocking infrastructure, and share them with threat intelligence sharing platforms like MISP to contribute to community defense.
Coordinating Takedown Actions
Full botnet takedowns require coordination beyond what individual organizations can execute. The practical steps for contributing to and benefiting from coordinated takedown actions are well-defined, but often poorly understood at the operational level.
When you identify botnet infrastructure with high confidence, the escalation path is: document your indicators with full evidence chains, contact the hosting provider's abuse team with a structured abuse report including timestamps, traffic logs, and malware samples, and simultaneously notify your national CERT and relevant ISAC. For botnet infrastructure hosted on major cloud providers like AWS or Azure, the providers' security response teams have dedicated escalation paths that can result in account suspension within hours when the evidence is sufficient.
The Roundcube exploitation campaign targeting academic researchers demonstrated the importance of this coordination. In that campaign, threat actors used compromised academic mail servers as staging points for further attacks. Early notification to affected institutions through coordinated CERT channels significantly shortened the dwell time of the attacker infrastructure. The same principle applies to botnet C2 hosted on compromised legitimate infrastructure: rapid notification to the infrastructure owner is often faster than pursuing hosting provider abuse channels.
Legal and Operational Boundaries
Security teams sometimes consider active countermeasures against botnet infrastructure, including sinkholing C2 domains or disrupting C2 servers directly. The legal framework for these actions varies significantly by jurisdiction and organizational authority. In most cases, sinkholing a domain requires either registrar cooperation or law enforcement involvement. Directly disrupting C2 infrastructure that you do not own or control is illegal in most jurisdictions regardless of the purpose.
The operationally sound approach is to focus your active efforts on your own infrastructure: quarantining infected hosts, blocking C2 communications at your boundary, and feeding intelligence to parties with the legal authority to act on it. Law enforcement agencies including Europol's EC3, the FBI's Cyber Division, and national CERTs have established mechanisms for receiving and acting on botnet intelligence.
Indicator Management and Intelligence Sharing
Botnet tracking generates large volumes of indicators that require careful lifecycle management. An indicator that was accurate six months ago may now point at a sinkholed domain, a recycled IP address serving legitimate traffic, or decommissioned infrastructure. Feeding stale indicators into your blocking infrastructure creates operational disruption and degrades trust in the entire detection system.
Implement indicator expiration policies based on indicator type: IP address indicators should expire within 30 days unless reconfirmed, domain indicators within 90 days, and file hash indicators within 180 days. Integrate with threat intelligence platforms that provide confidence scoring and last-seen timestamps so your blocking decisions reflect the current operational status of each indicator.
Participate in structured threat intelligence sharing through platforms like the Cyber Threat Alliance, FS-ISAC, or sector-specific sharing groups. The Insikt Group's published research on intelligence methodology emphasizes the value of corroborated, multi-source intelligence over single-source indicator lists. When sharing your own intelligence, include context: how the indicator was identified, what malware family it is associated with, the date range of observed activity, and any pivoting data that connects it to broader infrastructure.
Metrics That Tell You Whether Your Tracking Program Is Working
Botnet tracking programs are often evaluated on the wrong metrics: number of IPs blocked, number of alerts generated, or number of incidents prevented. These metrics can all improve while the underlying tracking capability degrades, because they measure output volume rather than detection quality.
The metrics that actually reflect tracking program effectiveness are: mean time from botnet campaign launch to first internal indicator generation (you want this measured in days, not weeks), percentage of confirmed infected hosts identified through proactive hunting versus reactive incident response, and the ratio of true positive to false positive indicators in your active blocking lists.
Tracking the WSzero campaign progression across four versions provides a benchmark. Teams with mature botnet tracking programs were generating indicators for version 4 infrastructure within 48 to 72 hours of its deployment. Teams relying on commercial threat feed subscriptions alone were working with indicators that lagged by one to two weeks, a gap that translates directly into additional compromised hosts and additional time for the botnet to complete its objectives in their environment.
Practical Starting Points for Teams Building This Capability
If your organization is starting from a limited botnet tracking capability, the highest-value investments in order of implementation difficulty and operational impact are as follows.
- Deploy NetFlow collection and analysis with enrichment from at least two threat intelligence feeds covering C2 infrastructure and bulletproof hosting ASNs. This provides foundational visibility into botnet beaconing from compromised hosts.
- Establish a honeypot network on your internet-facing network segment emulating the device types targeted by current active campaigns. Even a single properly configured honeypot generates significantly more operationally relevant indicators than most commercial feed subscriptions.
- Configure your SIEM with correlation rules that detect beaconing behavior statistically rather than relying solely on IP reputation lookups. Jittered beaconing, domain generation algorithm traffic, and DNS dead drop resolution all have statistical signatures that pure reputation-based detection misses.
- Join your sector's ISAC and configure bidirectional indicator sharing. The value of threat intelligence compounds with the number of organizations contributing to and consuming from the shared pool.
- Establish a malware sample analysis pipeline that automatically extracts C2 configurations from samples collected via honeypots and endpoint detection tools. Manual analysis does not scale to the volume of botnet variants active in any given quarter.
Botnet tracking is an operational discipline that rewards sustained investment in infrastructure and intelligence relationships. The teams that detected WSzero's fourth version quickly were not teams with larger budgets. They were teams with better honeypot coverage of targeted device classes, more mature passive DNS monitoring, and established sharing relationships that gave them access to early indicators from peer organizations. Those capabilities are buildable at any scale, and the operational return on that investment becomes clearest precisely when the next version of a persistent botnet family launches and the detection window determines the outcome.
