Threat Infrastructure Analysis: How Far Should You Pivot?
Investigate domains, IP addresses, certificates, hosting, and relationships while setting evidence thresholds that prevent false cluster expansion.
Infrastructure analysis can reveal undisclosed domains, campaign preparation, victim delivery paths, and opportunities for detection. It can also produce enormous clusters of innocent shared services. The analyst’s job is to decide which pivots are strong enough for investigation, monitoring, or control.
Write the purpose first: scope an incident, find related delivery sites, assess whether a cluster is still active, or produce a warning. The acceptable evidence threshold for exploration is lower than the threshold for blocking or public attribution.
Start With a Provenanced Seed
Record why the seed artifact is relevant, where it came from, when it was observed, and whether malicious control is confirmed or only suspected. Preserve the exact domain, IP, URL, certificate fingerprint, account, or service identifier.
A mistyped or stale seed contaminates every downstream link. Revalidate it against the original evidence and separate attacker-controlled infrastructure from compromised victim systems and legitimate platforms being abused.
Grade Every Relationship
Stronger links may include a rare certificate reused across hosts, distinctive registration patterns, matching content and deployment timing, or an observed redirect chain. Weaker links include a common name server, large cloud IP, privacy service, or popular analytics ID.
For each edge record relationship type, temporal overlap, prevalence, source, and confidence. Two independent features are preferable to one. Never let a graph layout imply a relationship stronger than the underlying data.
Set Stop Rules Before the Graph Expands
Limit hop depth, time window, shared-service prevalence, and minimum independent features. Pause at CDNs, public resolvers, commodity hosting, link shorteners, and shared certificates unless other evidence restores specificity. Keep discarded paths so analysts do not repeat them.
Validate promising artifacts using a separate source and, where authorized, internal telemetry. Translate only current, high-confidence items into detections or blocks. The CTI source evaluation guide helps assess provenance.
Deliver a Cluster With Operational Labels
Provide a compact relationship table or graph, the analytic claim it supports, first and last seen dates, confidence per artifact, benign-use risk, and recommended handling: investigate, monitor, detect, block, or retain only as context.
Keep discovery separate from action. A wide exploratory cluster can be valuable internally, while the operational list remains small and well supported. The best stopping point is where further pivots no longer improve the reader’s decision.
Frequently asked questions
What is an infrastructure pivot?
It is a move from a known artifact to related data, such as a domain to registration, certificate, passive DNS, hosting, or another artifact.
Does shared hosting prove two domains are related?
No. Shared hosting is common and usually weak evidence unless supported by distinctive registration, certificates, timing, content, or control patterns.
When should analysts stop pivoting?
Stop when the decision is answered, expected value falls below cost, the path enters high-noise shared services, or new links lack independent support.
Should every discovered domain be blocked?
No. Discovery confidence and enforcement confidence differ. Validate ownership, current use, collateral risk, and observable malicious behavior before blocking.
How long is infrastructure intelligence useful?
It depends on the artifact and actor. Track first seen, last seen, collection date, and expiry; reassess before operational use.
