One domain. That’s often all you start with. A single indicator pulled from a phishing email, a SIEM alert, or a malware sandbox report. The question is: what can you build from it?

This post covers my methodology for expanding a single IOC into a full infrastructure map using passive DNS and certificate transparency logs — both freely available.

Why Infrastructure Mapping Matters

Hunting on individual IOCs is a losing game. By the time an IP or domain appears in a threat feed, the actor has likely rotated it. Infrastructure mapping lets you:

  1. Identify the pattern behind the infrastructure, not just specific artifacts
  2. Find related assets that haven’t been burned yet
  3. Build detection that survives actor rotation

Tool Stack

Passive DNS:  SecurityTrails, CIRCL PDNS, Farsight DNSDB
Cert logs:    crt.sh, Censys, Facebook CT
Scanning:     Shodan, Censys, FOFA
Pivoting:     Maltego, SpiderFoot, manual API chaining

Step 1: Passive DNS Expansion

Starting from malicious-domain[.]com, query passive DNS to find:

  • Historical IPs the domain resolved to
  • Other domains that shared those IPs (reverse resolution)
  • Temporal patterns — when did the domain first appear? Resolution gaps?
import requests

def pdns_lookup(domain, api_key):
    url = f"https://api.securitytrails.com/v1/history/{domain}/dns/a"
    headers = {"apikey": api_key}
    r = requests.get(url, headers=headers)
    return r.json()

Key pivot: if malicious-domain[.]com resolved to 1.2.3.4, find all other domains that resolved to 1.2.3.4 in the same time window. You’ve just expanded your cluster.

Step 2: Certificate Transparency

Actors reuse infrastructure patterns. If they registered login-microsoft[.]com, they probably registered login-google[.]com and login-apple[.]com too.

Query crt.sh for certificate subjects matching your pattern:

https://crt.sh/?q=%.login-microsoft.com&output=json

Look for:

  • Shared organization fields in certificate subjects
  • Let’s Encrypt issuance timing (bulk registration signatures)
  • SAN patterns (subject alternative names reveal related domains)

Step 3: Shodan Fingerprinting

Once you have a set of IPs, fingerprint the infrastructure:

  • What services are running?
  • What banners do the servers present?
  • Is there a unique HTTP header, SSL certificate, or Jarm hash?

A unique Jarm hash or HTTP server banner across multiple IPs is a strong clustering signal — it suggests shared deployment tooling or configuration templates.

Building the Graph

After three pivot rounds, you typically have enough to build a graph:

Domain → IP → Other Domains → Shared Cert Org → New IPs → ...

I use Maltego for visualization but a simple NetworkX graph in Python works fine for smaller clusters.

The goal is to find the common ancestor — the shared infrastructure characteristic that links all the assets together and allows you to write broad detection logic.

Closing

Infrastructure mapping is patient work. The payoff is detection that doesn’t expire when an actor rotates a single domain. Build the pattern, not the list.