Cyber reconnaissance and infrastructure tracing
Map the technical footprint of a domain, host or malicious campaign using passive sources first, active checks only inside an authorized scope.
1. Define the scope before you touch anything
Write down exactly which domains, IP ranges and accounts are in scope and where your authority comes from — written permission, ownership, or purely passive public data. Anything outside that list is off limits, even when a tool makes it trivial. Keep the scope note in the case file so every later finding can be traced to an approved starting point.
2. Work outward from passive sources
Start with certificate transparency (crt.sh), passive DNS and historical WHOIS (SecurityTrails), and internet-wide scan data that already exists (Shodan, Censys). None of these touch the target. They reveal subdomains, hosting providers, shared certificates and forgotten staging servers that often carry the real story.
3. Pivot on shared artefacts
Infrastructure is linked by reused artefacts: TLS certificate fingerprints, favicon hashes, analytics IDs, name servers, registrant emails, HTTP response headers and default page titles. One pivot rarely proves a link; three independent pivots pointing the same way is a strong lead.
4. Confirm with sandboxed interaction
Use urlscan.io or a disposable VM to fetch a page rather than your own browser, so your IP, cookies and identity never reach the target. Capture the DOM, requests and redirect chain as evidence. Only run active tooling — Nmap, ZAP, Nikto, Gobuster — against systems you own or have written authorization to test.
5. Record indicators in a reusable form
Store domains, IPs, hashes and timestamps in a flat, machine-readable list with a source and a first-seen date for each. Indicators without provenance cannot be defended later, and infrastructure rotates fast — a screenshot plus an archive link keeps the finding alive after the host disappears.
Best practices
- ›Separate research identity from personal identity: dedicated browser profile, VPN, and no logged-in accounts.
- ›Prefer passive data until active testing is explicitly authorized in writing.
- ›Timestamp everything in UTC; infrastructure findings age within hours.
- ›Capture evidence twice — a local screenshot plus a public archive snapshot.
- ›Rate-limit any tool that touches a live host; noisy scans damage both the target and your credibility.
- ›Never upload a client's private sample to a public multi-scanner; search by hash first.
Case studies
The staging server that leaked the roadmap
- Situation
- A researcher investigating a product launch found only a hardened marketing site with no useful data.
- Method
- A certificate transparency search surfaced a subdomain issued three weeks earlier that was never linked from anywhere. It resolved to an unauthenticated staging build.
- Lesson
- Certificates are published the moment they are issued, so the certificate log is often ahead of the live site. Always enumerate certificates before concluding a target is clean.
One favicon, forty phishing domains
- Situation
- A single reported phishing page appeared isolated, with a freshly registered domain and privacy-protected WHOIS.
- Method
- The favicon hash was searched across internet-wide scan data, returning dozens of live hosts serving the identical kit, all on two hosting ranges.
- Lesson
- Attackers rotate domains but rarely rebuild assets. Hash the static files and pivot on them to turn one report into a campaign map.
Common pitfalls
- Treating a shared hosting IP as proof of a relationship — thousands of unrelated sites share one address.
- Scanning a target because a tool made it easy, without checking authorization.
- Trusting a single WHOIS record; most registrant data is proxied or stale.