Malicious Infrastructure Clustering: How Passive DNS, TLS Certificates, and ASNs Reveal Shared Campaigns

IsMalicious TeamIsMalicious Team
Cover Image for Malicious Infrastructure Clustering: How Passive DNS, TLS Certificates, and ASNs Reveal Shared Campaigns

Short answer: Clustering is the art of joining weak signals (same subnet, co-occurring hostnames) into a defensible story, then stopping before your graph becomes a conspiracy wall.

The Three Pillar Signals

  1. Passive DNS—historical what resolved where to connect hostnames to IPs even after TTL churn
  2. Certificates—subject names, org fields, and repeated key material that can link phishing kits and admin panels
  3. ASNs and registrars—weak alone, but useful as priors, per ASN reputation basics

In combination, you get what threat intel teams call an infrastructure cluster: not proof of a single person, but often proof of a single operation or tooling pipeline.

A Grounded Method (No Graph Theater)

Step 1: Anchor on a high-certainty observable

  • Phishing domain from a well-trusted mailbox source
  • C2 from AV/EDR, not a random firewall deny

Cross-read: C2 and infrastructure overview and the narrative what is a C2 server?

Step 2: Enrich the anchor and record provenance

Use fast IOC enrichment to capture:

  • first/last seen, categories, and list diversity
  • related hashes if malware is in scope

If you are building automation, feed results into a SIEM+SOAR enrichment object so the cluster does not live in a slide deck only.

Step 3: Pivot on rare edges only

  • Certificate reuse of an uncommon leaf or an unusual org on free hosting
  • Subdomains that share a template (login- + your brand) across multiple registrars
  • IPs in small, stable ASNs (sometimes higher signal than a hyperscaler) — see the nuance in cloud IP reputation

Step 4: Falsify your hypothesis

Actively look for a benign explanation: shared CDN, parking page, or marketing vendor using the same SaaS cert bundle. Disproving a pivot is a success—it saves time.

Common Pitfalls (We Have All Been Burned)

  • Guilt by IP adjacency in a /20 full of customers
  • Guilt by shared wildcard cert (some CDNs and SaaS are noise machines)
  • Mistaking takedown sinkholes for real adversary infrastructure

If you are thinking about why a domain is suspicious, review phishing and clone sites and anatomy of phishing infrastructure for a structured lens.

Turn Clusters into Action: CTI, IR, and Takedowns

  • CTI — write a campaign note with edges, not just a STIX bag of objects
  • IR — map clusters to the MITRE matrix you already use in threat actor TTPs in 2026
  • Takedown — package certificates + HTTP similarity + phish evidence for hosts/registrars (brand teams care—see the brand impersonation runbook)

How isMalicious Supports the Loop

isMalicious is not a full passive DNS product, but it is an excellent reputation acceleration layer for each pivot. When a candidate IP or domain appears, you can quickly learn whether the internet already agrees it is bad or hot, before you open a 10k-node graph. For vendor fit, the VirusTotal alternative perspective explains scope and limits clearly.

Hands-on check: for any pivot, open the in-app IP / domain checker to attach cross-community context in minutes.

Takeaway

Clustering is not magic graph science—it is time-boxed, falsifiable pivoting with defensible records. The teams that get this right produce fewer slides and better blocks.

Further Reading

A One-Page “Graph Budget” to Stop Rabbit Holes

If your hunt team lives in a graph tool, budget the exploration the same way you budget cloud spend:

  • Time box the pivot session (45 minutes) and re-evaluate. If the only new nodes are in a huge CDN, stop.
  • Node cap: no more than N fresh IPs per parent domain unless a human escalates. This prevents “I clicked expand” incidents.
  • Edge rule: require two independent edge types to promote a node from “maybe” to “include in a report” (e.g., passive DNS to IP and cert overlap, not or).
  • Write the hypothesis first in one sentence. If you cannot, you are collecting nodes for dopamine, not for defense.

When to Bring Law Enforcement or Platform Abuse In

This is not legal advice, but in practice you want clean, reproducible artifacts: timestamps, the phishing kit hash, the victim lures, and a concise abuse narrative. A reputation snapshot from a service like isMalicious can be included as supporting context (“widely reported”), but the hosting abuse desk still expects a URL and a ToS violation story, not a philosophy essay.

Why “Same Certificate” is Sometimes Noise

A shared certificate can mean “same phisher” or “same free SaaS template.” The difference is whether the cert names are specific to your brand and whether the pages clone your login, not a generic “sign in to Microsoft” template. When in doubt, compare against how attackers build phishing infrastructure and then validate the domain string using typosquatting explainers before you invest another hour in graph land.

“Done Enough” for a Report vs “Done Enough” for a WAF

Not every graph belongs in a blog-ready intelligence report, and almost none should turn into a global firewall rule. Use this split:

  • CTI product = narrative + reproducible edge list (small, vetted) + confidence language
  • Defensive product = high-confidence IOCs, narrow scope, and a rollback plan

This mirrors the discipline we use when discussing threat intel risk scores and false positives: precision beats drama.

A Compact Example (Illustrative, Not a Real Campaign)

| Observable | What changed when you added context | | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | evil-login.example A record → a cloud IP | expected; cloud alone is not a verdict (see cloud IP guidance) | | Another hostname with same uncommon cert O field | interesting; promote to "investigate" | | 50 domains with a popular CDN wildcard | noise; do not build a “mega cluster” from CDNs | | A rare hash tied to a phishing kit also contacting the same hostname | high value; connect malware + network, similar to the workflows in file hash reputation for IR |

Cross-Link: OSINT and Legal Boundaries

If your hunt is semi-public, keep ethics and process in view—our OSINT for SOC teams explainer is a good companion so your pivots do not turn into a compliance incident.

Frequently asked questions

What is infrastructure clustering?
Infrastructure clustering is the practice of grouping related network indicators—IPs, hostnames, certificates, and ASNs—based on co-occurrence, registration similarity, and behavioral overlap to understand a single campaign, toolset, or actor infrastructure.
Is shared hosting a false positive for clustering?
Frequently, yes. Massive shared IPs and popular CDNs can connect unrelated sites. You must require additional corroboration: time correlation, cert overlap beyond generic CAs, unique JA3/HTTP behavior, or malware sample relationships.
What is the safest starting artifact to pivot from?
A high-confidence malicious domain you saw in a phishing email or a malware sample—better than a raw IP in a huge cloud range. If you have the malware, pair network pivots with [file hash triage in IR](/posts/file-hash-reputation-lookup-ioc-enrichment-incident-response).
How should I report clustered IOCs?
Use STIX relationship objects or a table with edges: parent→child, cert→host, host→ip, and time window. The goal is reproducibility, not a pretty graph screenshot.
How does isMalicious help during pivots?
isMalicious provides fast, aggregated IP and domain context so you can validate whether pivoted entities are already widely reported, reducing rabbit holes in shared hosting and bulletproof space.

Protect Your Infrastructure

Check any IP or domain against our threat intelligence database with 500M+ records.

Try the IP / Domain Checker