The Call That Changes the Morning
At 7:42 AM, a mid-sized financial services firm's SOC analyst notices an unusual spike in outbound DNS queries from a cluster of workstations in the accounting department. The queries follow a regular cadence — every 90 seconds, multiple hosts are resolving domains that share a distinctive pattern: randomized subdomains under a handful of recently registered .xyz and .top TLDs. The traffic volume is low enough to avoid triggering any threshold-based alert. Nobody receives a page. Nobody opens a ticket. By noon, those same hosts have exfiltrated roughly 4 GB of data through encrypted channels to IP addresses spread across three different hosting providers.
This is how botnet infections operate in 2026. They are not loud. They do not announce themselves. And by the time most teams notice the problem, the command-and-control (C2) relationship has been established long enough for the operator to have already accomplished their primary objective.
The recent discovery of IronWorm, a supply chain attack hitting the NPM ecosystem written in Rust, reinforces a pattern that botnet researchers have tracked for years: modern botnets embed themselves early in trusted software pipelines, use legitimate-looking communication channels, and leverage distributed infrastructure that makes single-point blocking ineffective. Understanding how to track and mitigate these threats requires moving beyond alert-and-react and into continuous behavioral monitoring.
What Botnet Traffic Actually Looks Like on the Wire
Most defenders have a mental model of botnet traffic that is shaped by early-2010s threat intelligence: high-volume SYN floods, obvious IRC channels, predictable callback intervals. Contemporary botnet architecture looks fundamentally different.
Modern C2 frameworks increasingly use HTTPS for all communications, making payload inspection difficult without TLS inspection infrastructure. Operators rotate through fast-flux DNS configurations, sometimes changing IP resolution every few minutes. Domain generation algorithms (DGAs) allow infected hosts to autonomously derive callback domains from shared seeds, which means blocking known C2 domains after-the-fact rarely prevents ongoing communication.
The behavioral signatures that actually matter for detection include:
- Beaconing patterns: Regular outbound connections to external hosts at consistent intervals, even when the payload is small. Look for connections every 30, 60, or 90 seconds to the same destination over hours or days.
- Low-and-slow data transfer: Small, consistent data uploads that individually fall below data loss prevention thresholds but represent meaningful exfiltration in aggregate over time.
- DGA-generated domain queries: High volumes of NXDOMAIN responses from a single host querying algorithmically generated domains. Tools like PDNS passive DNS and Zeek's DNS logging make this visible.
- Lateral movement from infected hosts: Botnets with worm propagation components, like the IronWorm supply chain variant, will attempt SMB, RDP, or SSH brute-force against internal network ranges shortly after establishing a foothold.
- Anomalous process-to-network relationships: A spreadsheet application making outbound HTTPS connections is worth examining. EDR telemetry that correlates process behavior with network connections is essential for catching this.
Building a Tracking Framework That Scales
Effective botnet tracking is not a product purchase — it is an operational process that combines internal telemetry with external threat intelligence feeds and requires continuous tuning to remain useful.
Internal Telemetry Collection
Start with DNS. Full DNS query logging, including responses and TTLs, gives you more actionable data per storage byte than almost any other log source. Deploy logging at your recursive resolvers so you capture every query from every internal host, not just the queries that result in successful resolution. Configure alerts for hosts generating NXDOMAIN rates above a baseline — a threshold of 20 NXDOMAIN responses per minute from a single host over a sustained period warrants immediate investigation.
Network flow data (NetFlow, IPFIX, or sFlow depending on your environment) provides the behavioral context that packet captures cannot sustain at scale. Flow records show you which internal hosts are communicating with external IPs, connection frequency, byte counts, and protocol distribution. When you correlate flow data with threat intelligence feeds, you can identify hosts communicating with known malicious ASNs or IP ranges without inspecting payload.
Endpoint telemetry from EDR tools rounds out the picture. Specifically, you want process creation events, network connection events associated with specific process IDs, and scheduled task or service installation events. Botnets persist through scheduled tasks, registry run keys, and service installations — EDR logs catch the persistence mechanism being written, which is often the clearest indicator of compromise you will ever get.
External Intelligence Integration
Threat intelligence feeds vary enormously in quality and freshness. For botnet tracking specifically, prioritize feeds that provide C2 IP and domain indicators with associated malware family context. Abuse.ch's Feodo Tracker, the Spamhaus Don't Route Or Peer (DROP) list, and community-maintained blocklists from sources like the Emerging Threats ruleset provide actionable data that maps to real botnet infrastructure.
Integrate these feeds directly into your SIEM so that every DNS query and every outbound connection is checked against current indicators in near-real time. Feeds that update daily are marginally useful; feeds that update every few hours are substantially better given how quickly botnet operators rotate infrastructure. Automate feed ingestion through STIX/TAXII where possible to reduce the manual overhead of keeping indicators current.
Passive DNS services like Farsight DNSDB, Circl.lu's passive DNS, and similar providers let you investigate historical resolution data for suspicious domains. When a host in your environment queries a domain you have not seen before, passive DNS tells you how long that domain has been registered, what IPs it has historically resolved to, and whether those IPs have been associated with known malicious infrastructure. This context is indispensable for triage decisions.
Identifying the Scope of an Infection
When you confirm one infected host, the immediate operational question is how many others are in the same state. Botnet operators rarely stop at a single infection — the entire business model depends on scale, and lateral movement is built into most modern loaders.
Run a targeted query across your SIEM for all hosts that have communicated with the confirmed C2 infrastructure over the past 30 to 90 days. Use both IP indicators and domain indicators, because operators frequently switch IPs while keeping domain resolution stable. This query will give you your initial scope estimate, which is almost always larger than the first responder assumes.
Cross-reference infected hosts against your asset inventory to identify high-value targets. A botnet infection on a developer workstation with access to source code repositories, a financial analyst's machine with access to wire transfer systems, or a server with domain admin credentials represents a materially different risk than an infection on a guest Wi-Fi kiosk. Silent Ransom Group's current campaign targeting law firms through vishing and fake IT support calls demonstrates that attackers correlate the value of their infected hosts with their escalation tactics — your response prioritization should mirror that logic.
Look for shared attributes among infected hosts: the same software package installed at roughly the same time, the same user who clicked the same phishing link, the same VPN entry point. Finding the infection vector early dramatically reduces the time required to achieve full remediation because you can identify uninfected hosts that were exposed to the same vector and proactively harden or monitor them.
Disrupting C2 Communications
Once you have identified the scope of infection and confirmed the C2 infrastructure, the next step is disrupting the botnet operator's ability to task infected hosts or receive exfiltrated data. Do this before beginning host remediation, not after — cutting C2 communication prevents the operator from issuing a destructive payload in response to detecting your cleanup activity.
DNS Blocking and Sinkholing
DNS-based blocking is the fastest lever you have. Configure your recursive resolvers to return NXDOMAIN or a sinkhole IP for all confirmed C2 domains. A sinkhole is preferable to NXDOMAIN because it allows you to continue observing which internal hosts are still attempting to reach C2 after you have begun remediation — any host that continues querying the sinkholed domain after its supposed remediation needs a second look.
Deploy Response Policy Zones (RPZ) on BIND or equivalent functionality on your DNS platform to implement this blocking. RPZ allows you to define custom resolution behavior for specific domains or entire zones without modifying your primary zone data, and you can update it in near-real time as new indicators arrive.
Network-Layer Blocking
For IP-based C2 infrastructure, push blocks at your perimeter firewall and at any internal network segmentation points. If your environment uses next-generation firewall or SASE platforms with centralized policy management, this can be deployed organization-wide within minutes. When the botnet is using IP addresses on shared hosting infrastructure, consider blocking at the ASN level if the hosting provider's legitimate customer base poses an acceptable false-positive risk — many botnet operators concentrate infrastructure in specific bulletproof hosting ASNs where collateral blocking is a reasonable tradeoff.
For organizations with BGP capabilities, Remotely Triggered Black Hole (RTBH) routing provides a mechanism to drop traffic to specific prefixes at the router level, upstream of your firewall. This is particularly effective when botnet-generated traffic is consuming bandwidth or when you need to block communication while firewall policy is being updated.
Isolating Infected Hosts
Network isolation of confirmed infected hosts is a prerequisite for effective forensic analysis and remediation. Use your NAC platform, firewall policy, or VLAN assignment to move infected hosts into a quarantine segment that allows only traffic necessary for investigation and re-imaging. Avoid fully cutting network access before imaging the host — you want to preserve volatile memory and network connection state for forensic purposes.
Coordinate the timing of isolation carefully. If you isolate hosts sequentially over several hours, botnet operators monitoring their fleet will notice the dropout pattern and may issue a wiper or accelerate data exfiltration from remaining hosts. Batch isolation of all confirmed infected hosts within a narrow time window reduces this risk.
Forensic Analysis and Attribution
Forensic analysis of infected hosts serves two purposes: confirming the malware family and understanding the full scope of attacker activity. Both are operationally necessary even when you are under pressure to remediate quickly.
Memory acquisition before shutdown preserves artifacts that will not survive a reboot: active network connections, injected code in legitimate process memory, encryption keys for exfiltration channels, and runtime configuration data. Tools like Magnet RAM Capture, WinPMEM, or LiME for Linux systems allow memory acquisition without requiring specialized hardware. Capture the memory image to a network share in your investigation environment rather than to local disk to avoid contaminating the forensic artifact.
Disk imaging should follow memory acquisition. Use FTK Imager, dc3dd, or equivalent tools depending on your platform. Prioritize the system volume and any additional volumes with evidence of attacker activity identified during initial triage.
Malware sample extraction from the captured artifacts allows you to submit to your AV vendor, to sandbox platforms like Any.run or Hatching Triage, and to sharing platforms like VirusTotal. Sharing malware samples through established community channels accelerates collective detection across the industry — this is a practice that pays dividends in both directions, as your analysts benefit from others' prior submissions of the same samples.
Remediation and Hardening
Re-imaging infected hosts from known-good baselines is the only reliable remediation for persistent botnet infections. Antivirus-based cleanup is insufficient for loaders and rootkits that modify system components below the OS kernel. Establish a baseline image for each host class in your environment and maintain the tooling to deploy it quickly — when you are remediating 40 hosts simultaneously, manual re-imaging is not viable.
After re-imaging, before returning hosts to production, apply all outstanding patches and verify that the infection vector has been closed. If the infection arrived through a compromised NPM package, as with the IronWorm campaign, audit your software supply chain dependencies and pin versions. If the vector was a phishing email that delivered a malicious loader, verify that your email security stack has been updated to detect similar payloads and that user training has been reinforced through targeted communication about the specific technique used.
Credential rotation is mandatory for any account that was authenticated on an infected host during the infection period. Treat all credentials present in the environment of an infected host as compromised, including cached credentials, browser-saved passwords, API keys stored in configuration files, and service account passwords. The Silent Ransom Group and similar actors routinely harvest credentials from botnet-compromised hosts as a precursor to escalating their access, making complete credential rotation a non-negotiable remediation step.
Operationalizing the Response Through Tabletop Exercises
Botnet response capabilities atrophy without practice. A tabletop exercise specifically designed around botnet infection scenarios — including supply chain compromise vectors, DGA-based C2 communication, and multi-stage lateral movement — validates your detection and response procedures before an actual incident tests them under adverse conditions.
Design the exercise around realistic indicators: actual DGA domain patterns from known malware families, realistic NetFlow data showing beaconing behavior, and EDR telemetry from previous public incident reports. Walk through the complete response cycle: initial detection, scope determination, C2 disruption, host isolation, forensic acquisition, and remediation. Identify gaps in tooling, authority, or communication that would slow the response in a real incident.
The exercise output should produce specific, assigned remediation actions for the gaps identified, with deadlines. A tabletop that produces a list of recommendations without ownership or timelines does not improve readiness — it documents existing weaknesses and creates liability.
Long-Term Visibility Improvements
Effective botnet tracking requires sustained investment in detection infrastructure. Several capabilities consistently provide high-value detection that justifies their deployment cost.
Full packet capture (PCAP) at network choke points gives analysts the ability to reconstruct attacker activity retrospectively when new indicators emerge. You do not need to store full PCAP indefinitely — 72 hours of rolling storage at key network segments is typically sufficient to support incident investigation. Tools like Arkime (formerly Moloch) make full PCAP storage and searching operationally viable at reasonable scale.
Network traffic analysis (NTA) platforms that apply machine learning to identify anomalous behavior patterns, rather than matching against static signatures, provide detection capability for novel botnet families that have not yet generated published indicators. Platforms in this category analyze protocol behavior, connection timing, byte volume distributions, and certificate characteristics to surface anomalies that warrant investigation. They work alongside signature-based tools rather than replacing them.
Threat hunting cadences dedicated specifically to botnet indicators improve your team's familiarity with botnet behavioral patterns and frequently surface infections that automated detection missed. A structured hunt for DGA-like domain queries, irregular outbound beaconing, or connections to known bulletproof hosting ASNs conducted monthly provides meaningful detection coverage beyond what passive alert monitoring delivers.
The operational reality in 2026 is that botnet operators are sophisticated, patient, and well-resourced. The Handala group's expansion into hybrid threat operations and the continued targeting of critical infrastructure sectors, including the recent attacks on exposed fuel tank gauges in the US, reflects a threat landscape where botnet infrastructure increasingly serves as the operational backbone for campaigns that extend well beyond credential theft and DDoS. Treating botnet detection as a checkbox exercise is a risk posture that the current threat environment does not support.
