# Threat Actor Infrastructure Tracking
Threat actor infrastructure tracking is the disciplined practice of identifying, cataloguing, and continuously monitoring the servers, domains, IP addresses, certificates, and related technical assets that adversaries build and operate to conduct attacks. Defenders who track this infrastructure gain a structural advantage: they can detect attacker preparation activity before any malicious payload reaches a target network. Where traditional detection waits for an attack to begin, infrastructure tracking shifts that detection window backward in time, creating opportunities to block, investigate, and share intelligence before an intrusion attempt lands. This practice addresses a persistent asymmetry in cybersecurity, where defenders must be right every time and attackers only need to succeed once. By mapping the technical terrain adversaries operate from, defenders convert that asymmetry into actionable foresight.
---
Threat actor infrastructure tracking is the systematic collection, analysis, and correlation of internet-facing technical assets associated with malicious actors, including command-and-control (C2) servers, phishing domains, staging servers, bulletproof hosting accounts, redirectors, and operational relay networks. It operates at the intersection of open-source intelligence (OSINT), passive DNS analysis, active internet scanning, and behavioral pattern recognition.
This discipline is distinct from indicator of compromise (IOC) management, which is primarily reactive. IOC management ingests known-bad artifacts after an event; infrastructure tracking works to discover unknown-bad assets before they are weaponized against a specific target. It is also distinct from vulnerability management, network traffic analysis, and endpoint detection, none of which examine adversary-controlled internet infrastructure as a first-class intelligence target.
Infrastructure tracking is not the same as threat hunting within a defended network. Threat hunting queries internal telemetry for signs of intrusion. Infrastructure tracking queries the public internet and commercial data sources for signs of adversary preparation.
Subtypes of this practice include:
Passive infrastructure tracking: Collecting data from third-party sources such as passive DNS databases, certificate transparency logs, and internet scan datasets without directly probing infrastructure.
Active infrastructure tracking: Sending crafted network requests to suspected adversary servers to fingerprint services, capture banners, and generate behavioral hashes such as JARM scores.
Attribution-linked tracking: Connecting infrastructure to specific threat groups using historical behavioral patterns, naming conventions, and hosting preferences documented in prior campaigns.
Predictive infrastructure tracking: Using known actor patterns to anticipate future infrastructure provisioning, enabling preemptive identification of new assets before they are used.
Infrastructure tracking does not guarantee attribution. Infrastructure can be shared, rented, or deliberately seeded to mislead analysts. Findings require corroboration before driving high-confidence attribution claims.
---
Infrastructure tracking combines multiple technical methods applied sequentially or in parallel. Each method produces signals that, in isolation, may be weak, but when correlated, produce high-confidence infrastructure clusters.
Step 1: Seed Identification
The process begins with a known indicator. This might be a C2 domain discovered during incident response, a suspicious IP identified in network logs, or a malicious certificate observed in a threat intelligence feed. This seed is the starting point for pivoting.
Step 2: Passive DNS and Historical Resolution Analysis
The seed indicator is submitted to passive DNS databases such as Farsight DNSDB or RiskIQ (now part of Microsoft Defender Threat Intelligence). These databases record historical DNS resolution data, showing which IP addresses a domain resolved to over time and which other domains have resolved to the same IP. A domain that resolved to an IP shared by three other domains registered on the same day with similar naming patterns is a strong signal of coordinated provisioning.
Step 3: TLS Certificate Analysis
Certificates issued for infrastructure frequently contain reusable fingerprinting characteristics. Analysts examine subject fields (common name, organization, locality), issuer chains (especially self-signed or free CA patterns), serial number formatting, and validity windows. Certificate transparency logs maintained by Google and Cloudflare record every publicly trusted certificate issued, providing a searchable historical record. An actor who registered certificates with identical subject fields across twenty domains has left a durable fingerprint that persists even after those domains change IP addresses.
Step 4: Active Fingerprinting with JARM
JARM is an active TLS fingerprinting tool developed by Salesforce that sends ten TLS client hello messages with varied parameters and records the server's responses. The resulting 62-character hash reflects how the server's TLS stack is configured, including which ciphers it accepts, extension ordering, and version negotiation behavior. Specific C2 frameworks such as Cobalt Strike, Sliver, and Brute Ratel produce distinctive JARM hashes by default, even when operators change other configuration details. Security teams can scan internet ranges for known JARM signatures to find active C2 infrastructure before it is used against their organization.
Step 5: HTTP and Service Banner Fingerprinting
Beyond TLS, adversary infrastructure often exposes identifiable HTTP response patterns. Default Cobalt Strike team servers, for example, have historically returned a specific 404 response body and HTTP header ordering that distinguish them from legitimate web servers. Analysts use tools such as Shodan, Censys, and ZoomEye to query for these patterns across the indexed internet. A search for servers returning a specific HTTP header combination alongside a known JARM hash substantially narrows the result set to probable C2 nodes.
Step 6: Hosting and ASN Pattern Analysis
Threat actors frequently return to the same hosting providers, autonomous system numbers (ASNs), or even specific IP blocks across campaigns. This preference may be driven by anonymization services offered by bulletproof hosters, payment method compatibility, or simply operational habit. Tracking which ASNs appear repeatedly in confirmed actor infrastructure allows analysts to assign elevated scrutiny to new registrations or certificate issuances within those ASNs.
Step 7: Temporal Correlation
Coordinated infrastructure provisioning often occurs in compressed timeframes. An actor preparing a campaign may register ten domains, obtain TLS certificates, spin up VPS instances, and configure C2 software within a 24-to-72-hour window. Temporal clustering of these events, visible through certificate transparency logs and passive DNS data, identifies infrastructure build-outs that precede attacks.
Concrete Scenario: Tracking a Financially Motivated Actor
A financial services firm's threat intelligence team identifies a phishing domain targeting their brand during an incident. The domain resolves to an IP on a known bulletproof hosting ASN. Passive DNS shows that IP previously hosted four other domains, all registered through the same registrar with privacy protection enabled, all using Let's Encrypt certificates issued within the same 48-hour window. JARM scanning of those IPs returns a hash consistent with Cobalt Strike with a default malleable C2 profile. The team submits the entire cluster to their ISAC, blocks all associated infrastructure at the network perimeter, and alerts three peer institutions whose brands appeared in adjacent domain names. Two of those institutions had not yet received any phishing traffic, meaning the tracking effort created warning before the attack began.
---
Organizations that do not track adversary infrastructure operate in a fundamentally reactive posture. They detect threats when malicious traffic reaches their users, when credentials are stolen, or when a ransom note appears on a server. At that point, the attacker has already achieved some degree of access, and the cost of response is substantially higher than the cost of earlier detection would have been.
Infrastructure tracking compresses the adversary's window of safe operation. When defenders can identify C2 servers before they are tasked against a specific target, they can block them at the network layer without ever experiencing a successful intrusion. This is not a theoretical benefit. The financial sector has used infrastructure tracking through FS-ISAC and sector-specific intelligence programs to share adversary infrastructure clusters across member institutions, creating collective early warning that no individual firm could generate alone.
Real-World Consequence: SolarWinds Supply Chain Campaign
Post-incident analysis of the SolarWinds intrusion documented that the SUNBURST backdoor communicated with C2 infrastructure that had specific, detectable DNS characteristics, including a domain generation algorithm (DGA) that encoded victim organization details into subdomains. Retrospective examination of passive DNS data showed that this infrastructure had been active and resolvable for weeks before the campaign was publicly identified. Organizations with mature infrastructure tracking programs that had ingested and searched passive DNS data for the relevant DGA patterns could have detected the C2 communication earlier. This is not a criticism of victims; it is a demonstration that the signal existed in publicly available data and that infrastructure tracking is the mechanism for finding it.
Common Misconception: Many security teams treat infrastructure tracking as an activity only available to nation-state defenders or large enterprises with substantial intelligence budgets. This is incorrect. Free and low-cost data sources, including certificate transparency logs, Shodan community accounts, and VirusTotal's free tier, provide sufficient data for small teams to conduct meaningful infrastructure tracking on priority threat groups. The constraint is analytical capacity, not data access.
A second misconception is that blocking adversary infrastructure creates a lasting defense. Infrastructure is cheap and fast to replace. Blocking is a delay tactic, not a permanent countermeasure. The durable value of infrastructure tracking is the intelligence produced: understanding actor patterns, hosting preferences, tooling fingerprints, and campaign timelines.
---
The CDA Planetary Defense Model (PDM) positions threat actor infrastructure tracking within the Threat Intelligence Domain (TID), specifically aligned with TID-R01 (Threat Actor Profiling) and TID-R05 (Predictive Infrastructure Intelligence). CDA's methodology for this capability is Predictive Defense Intelligence (PDI), expressed operationally as: "See the threat before it sees you."
Where many organizations treat threat intelligence as a feed subscription and firewall rule import, CDA approaches it as a structured analytical discipline with defined collection requirements, regular production cycles, and measurable outcomes. Infrastructure tracking within the PDM is not a passive activity. It is assigned to specific analysts with defined threat actor portfolios, who conduct weekly pivoting sessions against their assigned actor clusters using a standardized methodology that combines passive DNS analysis, certificate transparency log queries, JARM-based active scanning, and ASN heat mapping.
CDA distinguishes between two operational modes for this capability. The first is campaign-responsive tracking, triggered when an incident or intelligence report surfaces new infrastructure. The second is continuous predictive tracking, which runs independently of any specific event and seeks to identify actor infrastructure provisioning before any targeting activity against CDA clients begins.
A specific operational differentiator in the CDA approach is the maintenance of actor infrastructure dossiers: structured documents that record confirmed and suspected infrastructure for each tracked threat group, including hosting preferences, certificate patterns, tooling fingerprints, and provisioning timelines. These dossiers are updated on a defined cycle and used as the baseline for each new pivoting session, ensuring that analytical findings accumulate rather than being discarded after each report.
CDA also integrates infrastructure tracking outputs directly into client network monitoring by translating identified infrastructure clusters into detection rules, DNS sinkhole configurations, and firewall block lists with defined confidence scores. Clients receive not just indicators but the analytical context explaining why each indicator was included, enabling their teams to make informed decisions about blocking versus monitoring.
This capability is recommended for organizations at TID maturity level 3 or above, though foundational passive tracking using certificate transparency logs and passive DNS can begin at maturity level 2.
---
---
---