The Threat Landscape Botnets Are Operating In Right Now
Botnets have evolved well past the image of a few thousand compromised home routers pushing spam. Today's botnet operators run layered command-and-control infrastructure, rotate hosting across bulletproof providers, and exploit legitimate cloud services to blend in with normal traffic. Recent intelligence confirms this trajectory. The emergence of Xdr33, a variant derived from the CIA's leaked HIVE attack kit, demonstrates that even highly sophisticated offensive tooling ends up repurposed in commercial botnet operations. The Cavern Manticore campaign, linked to Iranian threat actors, revealed a modular C2 framework that compartmentalizes operator communication, payload delivery, and exfiltration into separate stages, making traffic correlation significantly harder for defenders.
Australia's warning about a global campaign targeting vulnerable CMS platforms is a direct example of how botnet operators build initial access inventory at scale. Attackers scan millions of IP addresses, identify unpatched WordPress, Joomla, and Drupal installs, and add them to herder-controlled pools. Those compromised hosts later deliver malware, participate in DDoS swarms, or serve as proxies for subsequent attacks. The 'Popa' botnet, linked to a publicly traded Israeli firm, underscored something defenders rarely want to confront: botnet infrastructure sometimes originates inside entities that appear commercially legitimate, which makes blocklist-based defenses less reliable than teams assume.
Ransomware attack frequency continues to climb, and a significant percentage of ransomware delivery chains now rely on botnet infrastructure for initial access brokerage and lateral movement staging. Understanding how botnets are built, tracked, and dismantled is no longer a niche specialization. It is a core operational requirement for any security team managing production infrastructure.
How Modern Botnet Infrastructure Is Actually Structured
Most security teams think about botnets at the traffic layer: high-volume requests, repeated connection attempts, known bad IPs. That framing misses the architectural reality. Modern botnets are designed with operational security in mind, borrowing principles from nation-state C2 frameworks and applying them at commercial scale.
A typical mid-tier botnet uses a tiered C2 model. The lowest tier consists of compromised hosts, the actual bots. Above them sit tier-one relay nodes, often rented VPS instances or compromised servers, that receive operator commands and relay them downward while aggregating data upward. The operator never communicates directly with individual bots. Commands travel through at least one intermediate layer, sometimes two, before reaching compromised endpoints. This architecture means that blocking a bot's IP address does nothing to disrupt the operator's control, and blocking a relay node only temporarily interrupts a channel the botnet automatically replaces.
Domain generation algorithms (DGAs) are still widely used for C2 resilience. Bots compute a rotating list of potential C2 domains using a shared seed, attempt connections across that list, and re-establish control whenever the operator registers one of those domains. Some botnets have moved to fast-flux DNS, where multiple IPs rotate behind a single domain with very short TTLs, making IP-based blocking almost entirely reactive. Others use legitimate platforms, including cloud storage services, social media APIs, and even code repositories, as dead-drop resolvers for initial C2 contact.
The Watering Hole attacks pushing the ScanBox keylogger represent another delivery vector that feeds botnet growth. Legitimate websites are compromised, JavaScript is injected, and visiting users receive payloads that enroll their machines into botnet infrastructure without any direct user interaction. This technique specifically targets industry-relevant sites to build pools of high-value compromised endpoints rather than indiscriminate infection.
Where Tracking Actually Begins
Effective botnet tracking starts at the earliest observable indicator, which is usually at the exploit or delivery layer rather than at the C2 communication layer. By the time a bot is actively beaconing, the initial compromise is complete and the attacker has already established persistence. The detection window that matters most is between initial exploitation and the first successful C2 contact.
Passive DNS monitoring is one of the highest-value tracking techniques available without requiring deep access to endpoint telemetry. When a botnet begins registering DGA domains or activating fast-flux infrastructure, those DNS queries appear in passive DNS databases before most blocklists carry the entries. Correlating newly observed domains against DGA pattern libraries, registration patterns, and hosting ASN clusters gives analysts a meaningful head start.
Network flow analysis at the perimeter and between segments provides the behavioral baseline that botnet detection depends on. Bots follow predictable rhythms. Beaconing intervals, even jittered ones, produce statistical signatures in flow data that differ from human-generated application traffic. A bot checking in every 3,600 seconds with a 10% random jitter still produces a connection pattern that stands out in flow analysis when examined over 48 to 72 hours of data. Tools like Zeek (formerly Bro) can extract these timing relationships from packet captures or NetFlow exports and feed them into detection pipelines.
Honeypots that mirror production services, specifically configured to capture exploitation attempts and initial payloads, give security teams visibility into which vulnerabilities botnet operators are actively weaponizing. A compromised-looking CMS instance running a current but deliberately unpatched version of a common plugin will attract automated scanners within hours. The payloads those scanners deliver contain C2 contact details and configuration data that analysts can extract and use for infrastructure mapping.
Botnet Tracking Checklist for Security Operations Teams
- Deploy passive DNS collection on all recursive resolvers, both internal and any forwarders, to capture the full resolution chain for all outbound queries, including NXDOMAIN responses that reveal DGA activity.
- Establish NetFlow or IPFIX export from all network boundaries, including internal segment boundaries, and retain at least 72 hours of flow data for retrospective analysis.
- Configure beacon detection logic in your SIEM or network analysis tool that flags connections to the same external IP or domain occurring at statistically regular intervals across multiple internal hosts.
- Integrate threat intelligence feeds that include botnet-specific C2 indicators, including DGA seed lists, fast-flux domain patterns, and known botnet ASN clusters from providers that specialize in this data category.
- Monitor certificate transparency logs for newly issued certificates matching naming conventions associated with known botnet infrastructure families. CT log monitoring often reveals infrastructure before it goes operational.
- Instrument DNS sinkholes for known DGA families relevant to your industry. Route DGA domain queries to a sinkhole that logs the querying host, timestamps, and query volume, giving you direct visibility into which endpoints are infected.
- Review outbound traffic to hosting ASNs associated with bulletproof hosting providers on a scheduled basis. Even if individual IPs are not flagged, traffic volume to known bad-neighborhood ASNs is an early indicator.
- Cross-reference newly observed external IPs in your flow data against passive DNS records. An IP that hosts dozens of domains registered in rapid succession is a strong indicator of fast-flux or disposable relay infrastructure.
- Implement process-to-network correlation on critical endpoints so that any network connection can be traced to the specific process and parent process that initiated it. This collapses the gap between network detection and endpoint forensics.
- Schedule quarterly reviews of your DGA detection coverage against newly documented botnet families to ensure your detection logic has kept pace with operator innovation.
Infrastructure Mapping as a Core Mitigation Discipline
Blocking individual IPs or even individual domains has limited effect against mature botnet operators. The infrastructure mapping approach treats botnet C2 as a network of connected assets and pursues disruption at the infrastructure level rather than the traffic level.
Start by pivoting on every confirmed C2 indicator. A single confirmed C2 IP yields its hosting ASN, the SSL certificate it presents, WHOIS registration data, and passive DNS records showing which other domains have resolved to it. Each of those attributes connects to additional infrastructure. The SSL certificate serial number or subject alternative name fields may match certificates on other IPs in the same cluster. The registrar and registration email may appear on dozens of other domains. The hosting ASN may concentrate dozens of other relay nodes. Following these pivots manually is feasible for small investigations, but automating the pivot graph using tools like Maltego, CIRCL's MISP, or custom scripts against VirusTotal's graph API scales the process to the volume of indicators that production environments generate.
When the infrastructure map reaches a sufficient level of completeness, the mitigation options expand substantially. Rather than individual IP blocks, security teams can implement ASN-level filtering for bulletproof hosting providers that appear repeatedly in the map. DNS sinkholing can be applied to entire DGA domain families rather than individual entries. Firewall rules can target certificate fingerprints rather than IPs, catching connections that rotate through multiple relay addresses but maintain consistent TLS identity for operational reasons.
Coordination with upstream providers amplifies individual team effort significantly. Internet service providers and cloud hosting companies have the technical means to null-route or suspend botnet relay nodes when provided with credible evidence. Law enforcement agencies in many jurisdictions can compel hosting providers to preserve logs or seize infrastructure when botnet operators cross legal thresholds. Organizations like the Shadowserver Foundation and Team Cymru provide botnet tracking data and infrastructure mapping support that most individual security teams could not replicate independently.
Mitigating Botnet-Driven Attacks on Organizational Infrastructure
Tracking a botnet externally addresses only one dimension of the problem. When a botnet is actively targeting your infrastructure, whether through credential stuffing, DDoS, vulnerability scanning, or payload delivery, the mitigation response needs to operate at multiple layers simultaneously.
Rate limiting on authentication endpoints, APIs, and public-facing web applications is the first line of defense against botnet-driven abuse. Distributed botnets, by design, spread their request volume across hundreds or thousands of source IPs to defeat simple per-IP rate limits. Effective rate limits for botnet scenarios need to operate on behavioral signals: request patterns, header consistency, TLS fingerprinting, and session behavior, rather than source address alone. The JA3/JA3S TLS fingerprinting approach identifies bot clients by the characteristics of their TLS handshake, which remains consistent even when the source IP rotates.
CAPTCHAs and proof-of-work challenges have limited utility against sophisticated botnets that route traffic through human-operated browser farms or use headless browsers that pass basic JavaScript challenges. For high-value endpoints, consider step-up authentication requirements that activate when behavioral signals suggest automated traffic, rather than challenging all users at all times.
Network segmentation directly limits the damage from botnet-driven lateral movement following initial compromise. If a compromised endpoint can only communicate with the resources it legitimately needs, the botnet operator's ability to expand their foothold is constrained. The Cavern Manticore campaign's modular architecture was specifically designed to operate across segmented networks by using different communication channels for different stages of the attack, which means segmentation needs to be paired with behavioral monitoring of permitted communication paths, not just access control.
For organizations managing large numbers of public-facing servers, vulnerability management cadence directly determines botnet attack surface. The Australian government warning about CMS platform targeting is a reminder that publicly documented vulnerabilities in common platforms attract automated exploitation within hours of publication. Treating patch deployment for CMS plugins and themes with the same urgency as core system patching closes the inventory that botnet operators depend on building.
Coordinating Takedown Efforts Without Wasting the Intelligence Window
Takedown operations against botnet infrastructure follow a sequence that teams frequently compress incorrectly, burning intelligence before maximum leverage is achieved. The instinct to immediately block or report every identified C2 node is understandable, but premature action destroys the visibility that makes comprehensive disruption possible.
Before any external notification or blocking action, complete as much infrastructure mapping as the available data supports. Every C2 node you identify and block immediately disappears from your monitoring view, potentially before you have enumerated the relay nodes behind it. Operators detect sudden connectivity loss and rotate infrastructure within hours. The mapping phase should run until you have documented the full observable tier structure, the DGA family if present, the ASN distribution of relay nodes, and the upstream providers controlling the infrastructure.
Coordinate notification to hosting providers and relevant CERTs simultaneously rather than sequentially. Sequential notification allows the botnet operator time to observe partial infrastructure disruptions and evacuate remaining nodes before action reaches them. Simultaneous notification to all identified hosting providers, coordinated through a central reporting contact such as a national CERT or the Shadowserver Foundation, maximizes the disruption effect.
After takedown actions complete, maintain sinkhole monitoring for 30 to 90 days. Infected endpoints that were connecting to now-defunct C2 infrastructure will continue attempting connections to sinkholed addresses, providing a count of the infected population and identifying organizational assets that still require remediation even after the external threat is disrupted.
Implementation Pitfalls That Undermine Botnet Tracking Programs
The most common failure in operational botnet tracking programs is data retention gaps that prevent retrospective analysis. Botnets operate on timescales that exceed the default retention periods for most SIEM configurations. If NetFlow data expires after 24 hours or DNS query logs are pruned at 48 hours, the statistical analysis required to identify beacon patterns and DGA activity becomes impossible. Before deploying detection logic, confirm that the underlying data stores retain enough history to support the correlation windows the detection requires.
Treating threat intelligence feeds as authoritative blocklists rather than starting points for investigation creates a second category of failure. Commercial and open-source botnet C2 feeds are valuable, but they reflect historical observations. Fast-flux infrastructure and freshly registered relay nodes often have no prior reputation. Teams that depend exclusively on feed matching will miss newly stood-up infrastructure that has not yet accumulated reputation data. Behavioral detection logic that functions without feed data is not optional; it is the component that catches the activity the feeds have not seen yet.
Siloing botnet tracking within the network security team without integration into endpoint detection and incident response processes limits the program's effectiveness. A network-level detection that flags a probable infected endpoint has limited value if the endpoint team's response workflow does not include botnet-specific investigation steps. Process integration ensures that network detections trigger endpoint forensics, and endpoint findings feed back into network indicator expansion.
Finally, botnet infrastructure mapping efforts frequently stall when analysts reach hosting providers or registrars outside their jurisdiction or familiar contact channels. Building relationships with ISP abuse teams, national CERTs, and international coordination organizations like the Anti-Phishing Working Group before an active incident is necessary because the middle of a botnet investigation is the worst time to establish those relationships for the first time. Proactive engagement turns what would be a cold contact under pressure into a familiar channel with established trust.
