building-adversary-infrastructure-tracking-system

name	building-adversary-infrastructure-tracking-system
description	Build an automated system to track adversary infrastructure using passive DNS, certificate transparency, WHOIS data, and IP enrichment to map and monitor threat actor command-and-control networks.
domain	cybersecurity
subdomain	threat-intelligence
tags	["infrastructure-tracking","passive-dns","c2","whois","threat-actor","pivoting","threat-intelligence","domain-analysis"]
version	1.0
author	mahipal
license	Apache-2.0
nist_csf	["ID.RA-01","ID.RA-05","DE.CM-01","DE.AE-02"]

Building Adversary Infrastructure Tracking System

Overview

Adversary infrastructure tracking uses passive DNS records, certificate transparency logs, WHOIS registration data, and IP enrichment to discover, map, and monitor threat actor command-and-control (C2) networks. Attackers frequently reuse hosting providers, registrars, SSL certificates, and naming patterns across campaigns, enabling analysts to pivot from known indicators to discover new infrastructure. This skill covers building an automated tracking system that identifies infrastructure relationships, detects newly registered domains matching adversary patterns, and maintains a continuously updated map of threat actor networks.

When to Use

• When deploying or configuring building adversary infrastructure tracking system capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Common Misconfigurations & Verification

• Over-pivoting on shared hosting: reverse-IP and pivot_from_seed expansion explodes when a seed resolves to a CDN, parking IP, or shared host -- you ingest thousands of unrelated co-tenants. Cap reverse_ip_lookup results (the [:20] slice) and exclude known CDN/cloud ASNs before adding edges, or the graph clusters around hosting hubs, not the actor.
• Passive-DNS time blindness: treating first_seen/last_seen as current state links domains that never co-existed. Pivot only on temporally overlapping resolutions.
• WHOIS privacy noise: registrant-email pivots match privacy-proxy addresses (WhoisGuard, REDACTED) shared by millions -- filter these before clustering.
• API/dedup errors: SecurityTrails 429s and quota exhaustion silently truncate results; normalize hostnames (lowercase, strip trailing dot) before adding nodes or the same domain appears twice.

To verify: confirm the pipeline handles non-200/429 responses (do not treat an empty records as "no infrastructure"); validate find_hub_nodes() against a known seed and check that high-centrality nodes are real shared infra, not artifacts of the [:20] cap. Run a seed with known related infrastructure and confirm the expected domains land in one cluster while CDN/sinkhole IPs are excluded. Re-resolve discovered subdomains via DNS before acting -- CT/passive-DNS hits can be stale.

Prerequisites

• Python 3.9+ with , , , , libraries