The Problem That Sits in Every SOC Queue
Botnets are not an abstract threat category. They are infrastructure — persistent, distributed, and increasingly sophisticated. For most security operations teams, the challenge is not recognizing that a botnet exists. It is figuring out which systems in their environment are already enrolled in one, how far the compromise has spread, and what the command-and-control (C2) channels look like well enough to disrupt them before the next payload stage executes.
The recent arrest of the alleged Kimwolf botmaster known as 'Dort,' charged in both the U.S. and Canada, is a reminder that even long-running botnet operations eventually attract serious law enforcement attention. But between initial deployment and eventual takedown, these networks cause real damage — credential theft, DDoS capacity rental, ransomware staging, and persistent espionage footholds. Cybersecurity professionals and IT administrators need operational processes for tracking and mitigating botnet activity, not just high-level frameworks.
This article walks through how to build and maintain those processes in practical terms: what to look for in your telemetry today, how to structure your investigation this week, and how to harden your detection and response posture over the coming quarter.
Understanding What Modern Botnets Actually Look Like
Before you can track a botnet effectively, you need an accurate mental model of its architecture. Modern botnets have moved well beyond the centralized hub-and-spoke IRC-based designs of the early 2000s. Two categories dominate current threat activity:
Centralized C2 with Resilience Layers
Many botnets still use centralized C2 infrastructure, but with multiple redundancy mechanisms. Domain generation algorithms (DGAs) allow infected hosts to autonomously compute a list of potential C2 domains, so even if defenders sink one domain, the botnet operator can register a new one that infected hosts will find on their own. Fast-flux DNS adds another layer: a single domain resolves to dozens of IP addresses that rotate on short TTLs, often using compromised residential systems as proxies to obscure the actual C2 server.
The Ghost CMS SQL injection flaw recently exploited in a large-scale ClickFix campaign illustrates how botnets use web vulnerabilities not just for initial compromise but for staging C2 redirectors. When legitimate web properties get compromised and turned into botnet relays, standard IP reputation blocklists lose much of their effectiveness. A Ghost CMS installation at a small nonprofit has a clean reputation history. Your threat intelligence feed has no signal on it until the campaign is already underway.
Peer-to-Peer Botnets
P2P botnets are architecturally more resilient and operationally harder to disrupt. There is no single C2 server to sink. Instead, each bot acts as both a client and a relay, propagating commands through the mesh. Recent research into P2P botnet behavior and continuous monitoring programs has shown that these networks can maintain operational coherence even when defenders successfully identify and null-route significant percentages of the node population.
P2P botnets typically use encrypted communications over standard ports (443, 80, 53) and increasingly leverage legitimate platform APIs — Telegram, Discord, Slack webhooks — for command relay. Behavioral detection, not signature matching, is the only reliable detection path here.
Today: What to Check Before You Leave Your Desk
The first phase of botnet tracking is telemetry triage. Pull these data sources and apply the checks below before moving into deeper investigation.
DNS Query Logs
DNS is still the most reliable early-warning signal for botnet C2 contact. Look for:
- Hosts generating high volumes of NXDOMAIN responses, which can indicate DGA activity where the host is cycling through a list of algorithmically generated domains, most of which are not yet registered.
- Queries to domains with high entropy names — strings that look random rather than human-readable. Tools like
dnstwist,freq.py, or commercial threat intelligence platforms can score domain entropy at scale. - Consistent query intervals from a single host at fixed time offsets, which often reflects a beacon check-in schedule rather than organic browsing behavior.
- Queries to recently registered domains, particularly those registered within the last 30 days with privacy-protected WHOIS and hosting on bulletproof autonomous systems.
Outbound Traffic Patterns
In your NetFlow or equivalent session data, filter for hosts making recurring small outbound connections to the same external IP or set of IPs on non-standard ports. Botnet beacons are characteristically regular. A workstation contacting the same IP on port 4444 or port 8080 every 60 seconds for six hours is not browsing behavior. Even when botnet traffic is encrypted, the periodicity is often visible in session metadata.
Gremlin Stealer, a recently documented infostealer with evolved evasion tactics, exemplifies how modern malware hides C2 traffic inside resource files and uses mimicry of legitimate application traffic to avoid detection. That means defenders need to look beyond known-bad IPs and focus on behavioral signatures: connection frequency, session duration, data volume patterns, and user-agent strings that don't match the claimed application.
Endpoint Process Trees
On managed endpoints, correlate suspicious network connections to the process initiating them. A connection from svchost.exe to an external IP is less concerning than a connection from a process with a randomized name spawned from a temp directory. Process injection techniques — where botnet malware injects into a legitimate process — are common, so also look for unusual parent-child process relationships. A Word document spawning PowerShell, which then spawns a network connection, is a classic botnet loader chain.
Building a Reliable Botnet Detection Architecture
Tactical checks are useful, but sustainable botnet tracking requires architectural investment. These are the components that create detection depth.
DNS Sinkholing
Deploy a recursive DNS resolver that you control, and configure it to resolve known botnet domains to a sinkhole IP address that you own. When an infected host tries to reach a C2 domain and gets your sinkhole address instead, it will make a connection to your sinkhole server. That connection gives you the infected host's IP address, the domain it was trying to reach, and the request structure — all of which feed your incident response workflow.
Maintain a current feed of botnet-related domains from threat intelligence sources — abuse.ch's ThreatFox, the Shadowserver Foundation, CIRCL.lu, and commercial feeds all publish domain indicators. Automate the ingestion of these feeds into your sinkhole configuration, with daily or more frequent updates.
One practical note: sinkholing works best in enterprise environments where you control the full DNS resolution path. In environments with mixed BYOD or where endpoints use hardcoded public resolvers (8.8.8.8, 1.1.1.1), you need firewall rules that force DNS traffic through your controlled resolver, or the sinkhole provides incomplete coverage.
JA3/JA3S Fingerprinting for TLS Sessions
Botnet C2 communications are increasingly TLS-encrypted, but the TLS handshake itself is fingerprint-able. JA3 generates a hash from specific fields in the TLS ClientHello (cipher suites, extensions, elliptic curves), and JA3S does the same for the ServerHello. Many botnet families use distinctive TLS configurations that produce consistent JA3 hashes across all infected hosts.
Integrate JA3 fingerprinting into your network sensor stack — Zeek (formerly Bro) has native JA3 support, and Suricata can extract these hashes for rule matching. Build a database of known-bad JA3 hashes from published threat intelligence and correlate against your traffic. This catches malware communicating over HTTPS without requiring certificate inspection or traffic decryption.
Passive DNS for Infrastructure Tracking
Botnet operators recycle infrastructure. A C2 IP that hosted one campaign will often resurface under a new domain in the next campaign. Passive DNS databases — pDNS — record the history of which domains have resolved to which IPs over time. Tools like RiskIQ PassiveTotal, Farsight DNSDB, and the open-source equivalent PDNS from Circl give you historical resolution data.
When you identify a suspicious IP in your environment, query passive DNS to find all domains that have historically resolved to that IP. Those domains may match known malware families, be listed in threat feeds, or cluster around registration patterns associated with botnet infrastructure. This lateral expansion from a single IP indicator often reveals the broader campaign infrastructure.
This Week: Structured Investigation Workflow
Once you have initial indicators, structured investigation turns a suspicious signal into actionable intelligence. Follow this workflow when a potential botnet infection surfaces in your telemetry.
Step 1: Scope the Infected Population
Starting from your initial indicator — a suspicious domain, an unusual C2 IP, a known-bad JA3 hash — query your network telemetry for all hosts that have contacted this indicator in the past 30 days. Do not assume the initial host you identified is the only one. Botnet operators typically achieve initial access across dozens to hundreds of systems before defenders identify the first case. Your first job is understanding the actual scope of the infection.
Use your SIEM to pivot on the indicator across multiple data sources: DNS logs, proxy logs, firewall session logs, and endpoint detection data. Aggregate the results into a definitive list of potentially affected systems before you start remediation. Cleaning one system while leaving 40 others actively communicating with C2 infrastructure accomplishes very little.
Step 2: Establish the Infection Timeline
For each affected system, reconstruct the timeline of compromise. When did the first C2 contact occur? What process made that contact? What ran on the system in the hours before the first C2 contact? This sequence identifies the initial access vector — phishing email, drive-by exploit, malicious update, supply chain compromise — which determines both your remediation scope and your defensive improvement priorities.
The TeamPCP supply chain campaign documented through late May 2026 is a current example of why timeline reconstruction matters. Supply chain compromises can create botnet infections through legitimate software update channels, meaning standard user-behavior-based detection (suspicious email attachment, unusual download) produces no signal. Only timeline analysis — correlating the infection onset with software update events — reveals the actual vector.
Step 3: Identify the Botnet Family
Botnet family identification determines the full threat picture. Different families have different capabilities, persistence mechanisms, and secondary payload delivery tendencies. A system infected with a DDoS botnet represents a different risk profile than one infected with a banking trojan that also has botnet functionality.
Submit malware samples to sandboxes: Any.run, Hybrid Analysis, or your internal sandbox environment. Correlate behavioral indicators against malware family databases: MalwareBazaar, VirusTotal, and vendor threat intelligence publications. If the family is known, published research will describe its persistence mechanisms, which tells you exactly where to look on infected systems and what to remove.
Step 4: Map the C2 Infrastructure
Use the indicators extracted from malware analysis — domains, IPs, URL patterns, certificate hashes — to map the C2 infrastructure. Apply passive DNS, WHOIS history, ASN analysis, and SSL certificate transparency logs (crt.sh is freely accessible) to expand the known infrastructure footprint. This map serves two purposes: it gives you a comprehensive blocklist to deploy immediately, and it gives you threat intelligence that may be shareable with your industry ISAC, law enforcement, or infrastructure providers who can action takedown requests.
Mitigation Controls: Phased by Implementation Complexity
Not every mitigation is appropriate for every environment, and not every control can be deployed immediately. Structure your mitigations by implementation time and operational impact.
Immediate Controls (Same Day)
Block confirmed C2 indicators at your perimeter firewall and DNS resolver. Isolate confirmed infected hosts from the network — move them to a quarantine VLAN with no outbound internet access but with access to your sinkhole and logging infrastructure so you can continue to observe behavior during investigation. Push emergency endpoint detection signatures for the identified malware family to your EDR platform.
If you are running a SIEM with correlation rules, create a time-bounded rule that generates high-priority alerts for any host contacting the newly identified C2 infrastructure. This catches systems that weren't in your initial scope sweep and surfaces new infections as they occur.
Short-Term Controls (This Week)
Audit your DNS resolver configuration and enforce DNS over HTTPS or DNS over TLS for all endpoints, routing through your controlled resolver. This closes the bypass path that exists when endpoints use hardcoded public resolvers. Review firewall egress rules and apply explicit allow-list policies for outbound traffic where operationally feasible — denying all outbound traffic to ports and protocols not required by documented business need reduces the attack surface for future botnet C2 channels significantly.
Deploy or tune your network detection and response (NDR) platform to flag recurring small outbound sessions with regular intervals. Most commercial NDR platforms have beacon detection built in; verify it is enabled and that the sensitivity is calibrated for your environment's baseline traffic patterns.
Structural Hardening (This Quarter)
Invest in recursive DNS visibility. If you are not capturing full DNS query logs for all endpoints and servers in your environment, that is the single highest-value logging gap to close for botnet detection. Full DNS visibility, combined with threat feed integration, gives you reliable early warning for C2 contact that is independent of endpoint agent coverage.
Evaluate your passive DNS access. Whether through a commercial threat intelligence platform or through relationships with organizations like the Shadowserver Foundation, having historical DNS resolution data available for investigation purposes dramatically accelerates the infrastructure mapping phase of any botnet investigation.
Stand up or formalize a threat intelligence program that includes regular ingestion of botnet-specific feeds. The Shadowserver Foundation publishes daily botnet reports covering infected IPs by country and ASN. Abuse.ch ThreatFox publishes IOCs with malware family tags. CISA maintains advisories on active campaigns. Automate the ingestion of these sources into your detection stack rather than treating them as manual review items.
For environments with high-value data, consider deploying network traffic analysis at the east-west boundary inside your environment. Botnets operating in P2P mode often communicate between compromised systems inside the same organization before communicating externally. Internal traffic that matches botnet communication patterns is often invisible to perimeter-focused sensors.
Working With Law Enforcement and Industry Partners
The Kimwolf botmaster arrest, resulting in charges in both the United States and Canada, reflects an increasingly coordinated international response to major botnet operations. Law enforcement agencies — FBI, CISA, Europol's EC3, and national CERTs — actively seek threat intelligence contributions from defenders who have investigated botnet infrastructure. When your investigation produces C2 infrastructure maps, malware samples, and attack timelines, that material can directly support disruption operations.
Practically speaking, this means maintaining clean chains of custody for malware samples and logs during your investigation. Document your analysis methodology. When you share with law enforcement or ISAC partners, the credibility and utility of your contribution depends on the rigor of your documentation. FBI field offices and CISA regional contacts are accessible to organizations of most sizes — the barrier to engagement is lower than most IT administrators assume.
Industry sharing works in the other direction too. When you receive intelligence from an ISAC or government partner about a botnet campaign targeting your sector, build an automated process to ingest those indicators into your detection stack immediately rather than processing them through a manual review queue. The window between indicator publication and active exploitation of organizations that have not yet applied indicators is often measured in hours.
What Continuous Monitoring Requires
Botnet campaigns are not one-time events. The Kimwolf operation, the P2P botnets covered in ongoing research, and the Iranian APT Screening Serpens espionage campaigns all share one characteristic: they are persistent over months or years. Defenders who build detection for a specific campaign and then move on will miss the follow-on infrastructure when operators rotate domains and IPs after takedowns or blocklist additions.
Continuous monitoring means scheduled, automated queries against your historical telemetry for new botnet IOCs as they are published. It means regular review of sinkhole connection logs to identify newly infected systems. It means monthly review of DNS query entropy distributions to catch DGA activity that has not yet been mapped to a known malware family. And it means quarterly exercises where you simulate a botnet investigation using historical data to verify that your detection stack and your team's workflow are still functioning as expected.
The investment in these processes pays off not just for botnet detection. The telemetry, tooling, and investigation workflows that make botnet tracking effective are broadly applicable to any C2-dependent threat: ransomware operators, nation-state implants, and commodity RATs all use infrastructure that the same detection architecture will surface.
Closing Perspective
Botnet tracking is infrastructure intelligence work. It requires the same methodical approach as any other infrastructure investigation: collect the right telemetry, pivot through the data with the right tools, map the infrastructure comprehensively, and apply controls that match the threat model of the specific botnet family you are dealing with. The operators who do this well treat botnet indicators not as terminal blocklist entries but as starting points for broader infrastructure discovery.
Recent events — from the Kimwolf arrest to the ClickFix campaign exploiting Ghost CMS vulnerabilities — confirm that botnet operations span the full range from opportunistic commodity attacks to sophisticated, long-term infrastructure projects. Your detection and response posture needs to be calibrated for both ends of that range. The technical foundations described in this article — DNS visibility, behavioral detection, passive DNS access, C2 infrastructure mapping, and structured investigation workflows — provide that range of coverage when implemented and maintained consistently.
