The Threat Landscape Has Changed Shape
Botnets have never been static, but the last 18 months have pushed their complexity into territory that challenges even well-resourced security teams. The recently documented 'Popa' botnet, linked to a publicly traded Israeli firm, demonstrated that botnet infrastructure is no longer exclusively the domain of criminal underground actors. Peer-to-peer botnets have evolved into resilient, distributed command structures that resist traditional sinkholing efforts. The Xdr33 variant, derived from the CIA's HIVE attack kit, showed that nation-state tooling is feeding directly into botnet ecosystems. Ransomware groups are increasingly deploying botnets as the initial access and lateral movement layer before encryption begins.
This article walks through botnet tracking from the moment of first observable beacon through to mitigation and long-term suppression, with practical telemetry guidance and control mappings that apply in enterprise and service provider environments alike.
Recognizing the First Indicators in Your Telemetry
Botnet infections rarely announce themselves loudly. The initial beacon phase is designed to blend into legitimate outbound traffic. The patterns security teams should prioritize in their log analysis stack fall into a few distinct categories.
Beaconing Cadence Detection
Most bots check in with their command-and-control infrastructure on a timed schedule. The interval varies by botnet family, but the statistical regularity is detectable. Tools like RITA (Real Intelligence Threat Analytics) analyze DNS and flow logs to surface hosts that contact external IPs or domains at suspiciously consistent intervals. A host sending 64 bytes to the same external IP every 300 seconds is not browsing the web. That pattern in your NetFlow data warrants immediate investigation.
In practice, analysts should tune their SIEM to flag connections where the inter-arrival time variance across 50 or more sessions to a single external endpoint falls below a defined threshold. Start with a variance threshold of less than 15 seconds across a 6-hour window. This catches most hardcoded beacon intervals while minimizing false positives from legitimate heartbeat services.
DNS Telemetry as an Early Warning Layer
Botnet operators commonly use domain generation algorithms (DGAs) to avoid static blocklists. A compromised host queries dozens of algorithmically generated domains, most of which resolve to nothing, until it reaches one that the operator has registered. Your DNS resolver logs will show this as a burst of NXDOMAIN responses from a single internal host in a short window. Five or more NXDOMAIN responses in under two minutes from a workstation that is not a DNS server is a flag worth chasing.
Passive DNS monitoring at the resolver level, rather than relying solely on firewall logs, gives you a fuller picture. Deploy DNS logging to a centralized collector and write detection rules that correlate NXDOMAIN bursts with entropy scoring of the queried domains. High-entropy domain names, those with consonant clusters or numerical padding that do not resemble natural language, are consistent with DGA behavior. Open source tools like DomainIQ and PDNS datasets from RiskIQ or Farsight Security give you historical resolution data to correlate against new activity.
P2P Botnet Traffic Signatures
Peer-to-peer botnets present a harder problem because there is no centralized C2 to sinkhole. Recent research on P2P botnet monitoring highlights that the node handshake protocols often expose themselves through specific port combinations and packet structures. Emotet's P2P layer used TCP on high-numbered ephemeral ports with a recognizable 8-byte header format. Tracking P2P botnet infrastructure requires continuous monitoring rather than point-in-time detection because the topology shifts as nodes come online and drop off.
For network defenders, the practical response is to instrument your perimeter and internal segments with protocol anomaly detection. A workstation initiating dozens of outbound TCP connections to external IPs on non-standard ports, especially in ranges above 40000, warrants scrutiny. In segmented environments, east-west traffic showing the same pattern is a stronger indicator because legitimate business applications rarely behave this way internally.
Building a Tracking Infrastructure
Tracking a botnet once you have identified a compromised host requires infrastructure that goes beyond your standard SIEM. The goal is to map the botnet's reach within your environment and, where possible, contribute to broader threat intelligence efforts.
Sinkholing and Passive Observation
Sinkholing redirects botnet C2 domains to infrastructure you control, allowing you to observe which hosts attempt to check in. This is most effective when coordinated with domain registrars or when DGA domains can be pre-registered before the operator activates them. For enterprise defenders without the resources to run sinkhole infrastructure directly, subscribing to threat intelligence feeds from providers who operate sinkholes gives you access to the same data. Feeds from Shadowserver Foundation, for example, include sinkhole hit data that can be cross-referenced against your external IP ranges to identify infected hosts that have contacted known C2 infrastructure.
When setting up internal passive monitoring, deploy a full packet capture sensor or a network tap on the segment hosting your quarantine VLAN. Route suspected bots to this VLAN and capture their traffic for 24 to 48 hours before remediation. The goal is behavioral documentation, not just infection confirmation. Understanding what data the bot exfiltrates, what commands it accepts, and how it contacts peers informs your threat intelligence and helps identify other compromised hosts that have not yet tripped other detection controls.
Tracking Lateral Movement
Modern botnets, particularly those deployed as ransomware precursors, do not stay on the initial compromised host. They probe internal network segments using credential spraying, SMB exploitation, and WMI execution. Your Active Directory event logs are critical here. Event ID 4625 (failed logons) appearing across multiple hosts from a single source within a short window is lateral movement. Event ID 4688 (new process creation) with command-line logging enabled will surface tools like Mimikatz, PsExec, and net.exe being spawned from unusual parent processes.
Enable command-line auditing via Group Policy under Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking. Without this, process creation logs are largely useless for botnet tracking because you see that a process started but not what it was told to do.
Correlating Across Environments
Multi-cloud and hybrid environments create visibility gaps that botnet operators exploit. The CL-STA-1062 campaign targeting Southeast Asian critical infrastructure demonstrated that sophisticated botnet operators deliberately route activity through cloud-hosted relay nodes to break correlation. Your security team needs cross-environment logging normalized to a common schema. Whether you use the Elastic Common Schema, OCSF, or a vendor-specific normalization layer, the source IP, destination IP, process hash, and parent process identifier need to map consistently across on-premise, AWS, Azure, and GCP log sources before correlation rules can work.
Practical Mitigation Controls
Tracking tells you what is happening. Mitigation is the operational response that limits damage, removes the infection, and hardens the environment against reinfection.
Network-Level Containment
The first mitigation action for a confirmed botnet infection is network isolation. This means moving the affected host or hosts to a quarantine VLAN with outbound internet access blocked. Do this before remediation begins, because the remediation process itself, including downloading tools and AV signatures, can trigger additional C2 callbacks that alert the botnet operator and cause them to activate their payload earlier than planned.
At the firewall level, implement egress filtering as a standing control rather than a reactive one. Permit outbound traffic only on ports and protocols that your organization explicitly requires. Block outbound connections on port 445 (SMB), port 135 (RPC), and ports above 40000 unless there is a documented business requirement. Outbound DNS should route exclusively through your controlled resolvers, not directly to external DNS servers on UDP/TCP 53. This forces all DNS queries through your logging and filtering stack, making DGA detection reliable.
Endpoint Response
For confirmed infections, the remediation sequence matters. Start with memory forensics before rebooting the host. Many modern bots, including variants of HIVE-derived tooling like Xdr33, run primarily in memory and leave minimal disk artifacts. Tools like Volatility or the memory acquisition modules in your EDR platform will capture the running process tree, network connections from the process perspective, and injected code in legitimate processes. This data is lost on reboot.
After memory capture, image the disk before wiping. The disk image supports your threat intelligence work and may be required for legal or regulatory purposes. Reimage from a known-good baseline rather than attempting in-place cleanup. Botnet operators commonly deploy multiple persistence mechanisms including scheduled tasks, WMI subscriptions, registry run keys, and driver-level rootkits. Attempting to manually clean all of them on a live system reliably leaves residual access.
Credential Reset and Privilege Review
Every host confirmed as botnet-infected should be treated as having had its credentials harvested. This means forcing password resets for all accounts that logged into the host during the infection window, not just the primary user account. Review the Active Directory event logs for the host's authentication history going back to the estimated infection date. Service accounts that authenticated to the host during that window need their credentials rotated immediately, and their access should be audited for privilege creep.
If your environment uses service accounts with domain admin privileges, a botnet infection on any host those accounts authenticate to represents a potential domain compromise. Tier your administrative accounts using the Microsoft Privileged Access Workstation model, and audit whether your current account structure would allow a bot on a workstation to reach domain controller credentials through cached or in-memory credentials.
C2 Blocking and Threat Intelligence Integration
Once you have identified C2 infrastructure through your tracking work, block it at multiple layers simultaneously. DNS blocklists prevent resolution of known C2 domains. IP blocklists at the perimeter firewall prevent direct IP connections when operators bypass DNS. Proxy category blocking at your web gateway prevents HTTP/S-based C2 that routes through categorized but compromised domains.
Feed your identified C2 indicators back into your threat intelligence platform with a confidence score and expiration timestamp. C2 infrastructure turns over rapidly, often within 48 to 72 hours. An indicator that is six weeks old without revalidation is likely stale and should be automatically retired from active blocking to avoid accumulating blocklist noise that degrades performance and analyst trust.
Engaging External Resources and Community Intelligence
Botnet tracking at scale requires more than internal telemetry. The botnet tracking community, including organizations like Shadowserver Foundation, Abuse.ch, and the Spamhaus Project, maintains continuous monitoring infrastructure that covers botnet families across thousands of sensors globally. Registering your organization's IP ranges with Shadowserver gives you free notification when your IPs appear in sinkhole data, botnet command scans, or honeypot interaction records.
Abuse.ch operates several tracking projects relevant to botnet defenders. URLhaus tracks malware distribution URLs used in botnet dropper stages. ThreatFox aggregates indicators across botnet families with context on associated malware families and threat actor groups. Feodo Tracker specifically follows banking trojan and botnet C2 infrastructure for families including Emotet, IcedID, and Dridex. Integrating these feeds into your SIEM via their API endpoints gives you continuous, community-validated C2 indicators that your internal tracking alone will not surface in time.
For teams dealing with ISP-level or service provider environments, the Routing Security Working Group at ARIN and the NANOG community maintain active discussions on BGP-based botnet mitigation, including techniques for null-routing botnet C2 ranges at the routing layer rather than the firewall layer. This is particularly relevant given the increasing use of compromised routing infrastructure by botnet operators to reduce the effectiveness of IP-based blocking.
Long-Term Suppression and Monitoring Continuity
Mitigation is not the end of the tracking lifecycle. Botnet operators reinfect cleaned environments through the same initial access vectors that succeeded the first time. After remediation, run a structured review of your initial access controls.
Identify how the bot got in. The most common initial access vectors remain phishing emails with malicious attachments, exploitation of public-facing applications with unpatched vulnerabilities, and compromised remote access credentials. If the initial vector was phishing, review your email security gateway configuration for the specific technique used and test whether your current controls would block a reuse of the same approach. If it was a vulnerability, audit your patch management process to understand why the patch was not applied before exploitation occurred.
Deploy honeypot hosts in your internal network segments specifically to detect reinfection attempts. A host with no legitimate purpose that suddenly starts receiving lateral movement probes from an internal IP is evidence that another host is compromised and probing for new victims. Canary tokens, the open-source tooling from Thinkst, allow you to deploy fake credential files, fake network shares, and fake API keys that alert when accessed. Botnet credential harvesters and lateral movement tools commonly grab every credential file they encounter, and a canary credential triggering an alert gives you an early detection point that many other controls miss.
Review your monitoring coverage quarterly against the current botnet threat landscape. The MITRE ATT&CK framework's Enterprise matrix covers botnet-relevant techniques under Initial Access, Execution, Persistence, Credential Access, Lateral Movement, and Command and Control tactics. Map your current detection controls against each relevant technique and document the gaps. A gap is not automatically a problem if compensating controls exist, but undocumented gaps are the ones that become incidents.
What the Current Threat Environment Demands
The combination of P2P architectures, nation-state tooling feeding criminal botnet ecosystems, and the increasing use of botnets as ransomware precursors means that the detection and mitigation posture required today is substantially more demanding than what was sufficient three years ago. Teams that rely on signature-based detection alone, without behavioral analytics on DNS, NetFlow, and authentication logs, are operating with significant blind spots.
The practical investment that moves the needle most reliably is logging coverage and detection engineering. Organizations with comprehensive logging but immature detection rules consistently outperform organizations with partial logging and mature rules, because the data is there to reconstruct what happened even if it was not caught in real time. Build toward full coverage first, then invest in detection logic tuning. The botnet tracking and mitigation work that holds up under real adversarial conditions is built on data, not assumptions about what attackers will do next.
