Threat Intelligence Feeds: Following the Infrastructure

A threat feed surfaces a suspicious IP address in a SIEM. The alert fires. An analyst checks it against a few sources, confirms it looks malicious, blocks it at the firewall, and closes the ticket. The indicator is handled. The investigation never really starts.

In this article, we examine what happens between receiving an indicator and actually understanding what it represents. That means looking at why IOCs alone leave most of the picture invisible, how OSINT investigation extends structured feed intelligence into real context, and what the practical difference looks like between treating an indicator as a conclusion versus treating it as a starting point.

What an Indicator Actually Tells You

An indicator of compromise is a data point, not an explanation. A malicious IP, a suspicious domain, a file hash tied to known malware: each confirms that something has been observed and flagged somewhere. That is genuinely useful. It is also, by itself, limited.

The problem is that indicators are inherently reactive. By the time a hash appears in a threat feed, a domain gets flagged as malicious, or an IP lands on a blocklist, the activity behind it has already happened somewhere. The infrastructure behind many indicators has already rotated by the time the feed publishes it, leaving analysts investigating signals that no longer reflect current attacker behavior.

This is not a criticism of threat feeds. It is a structural reality of how indicators work. An IP address tells you an endpoint communicated with infrastructure that has been associated with malicious activity. It does not tell you who operates that infrastructure, what campaign it belongs to, what other infrastructure shares the same operators, or whether the environment has already been more deeply compromised through related vectors.

David Bianco's Pyramid of Pain captures this well. At the base of the pyramid sit the easiest indicators to generate and the easiest for attackers to change: IP addresses, domains, and file hashes. Blocking one IP costs an attacker almost nothing. Understanding the infrastructure, behavior, and campaign behind it costs them considerably more.

Where Structured Intelligence Runs Out

Threat intelligence feeds excel at what they are designed to do: providing structured, consumable data about known malicious activity at scale. Where they run out is in context, relationship, and history.

A feed can tell you that an IP has been associated with botnet activity. It usually cannot tell you which campaigns that IP has appeared in, which domains have resolved to the same hosting infrastructure, which SSL certificates are shared across related servers, or whether the registrant details behind the associated domains connect to other infrastructure worth investigating.

That context gap is where investigations stall. An analyst who receives a feed-confirmed malicious IP has one data point. What they often need to make a useful decision is a cluster of related data points that explains what the IP is part of, how significant it is, and whether the exposure is larger than one indicator suggests.

This is where OSINT investigation picks up where structured feeds leave off.

The Investigative Layer: What OSINT Adds

Open-source intelligence in a threat investigation context is not about searching for an IP address in a browser. It is about using public infrastructure data, passive DNS records, certificate transparency logs, registration histories, network topology data, and behavioral signals to build a picture of what an indicator is connected to.

Used properly alongside structured feeds, OSINT investigation helps analysts answer questions that feeds cannot:

• What other infrastructure shares the same hosting, registration patterns, or certificates as this indicator?
• Has this infrastructure appeared in prior campaigns, and which threat clusters does it overlap with?
• Are there related domains or IPs already communicating with internal systems that the feed has not yet flagged?
• What does the registration and operational history of this infrastructure suggest about how it was set up and by whom?

The investigative technique at the center of this is pivoting: starting from one known data point and systematically expanding outward through related infrastructure. A suspicious domain becomes a hosting IP. The hosting IP connects to other domains registered around the same time with similar patterns. Those domains connect to SSL certificates shared across multiple servers. The certificates connect to infrastructure that has appeared in prior incident reports.

What started as one indicator becomes a map of related infrastructure, and that map is far more actionable than the original data point alone.

A Practical Example: IP to Campaign

To make this concrete, consider a practical scenario. An analyst receives an alert: an internal system made a connection to an external IP flagged by a threat feed as malicious. The feed confirms it has been associated with command-and-control activity. Standard procedure might be to block the IP, log the event, and move on.

An investigative approach looks different. The analyst takes that IP and begins pivoting through available OSINT sources. Passive DNS data shows that the IP has resolved several domains over the past few months, some no longer active. Historical certificate data reveals that one of those domains shared a certificate with three other domains registered in the same week with similar naming patterns. Two of those domains are not yet flagged in any feed.

Checking the hosting provider and autonomous system data reveals that several of these domains sit on the same infrastructure cluster. Cross-referencing against public incident reporting and threat actor tracking platforms shows that this cluster has appeared in a campaign targeting organizations in the same sector. The TTPs described in that reporting match behavioral indicators already present in internal telemetry that had not been escalated.

The original alert was one connection to one IP. The investigation reveals a wider infrastructure cluster, two additional uncategorized domains already communicating with internal systems, and a connection to a known campaign that provides context for how to scope the incident.

That is the investigative layer in practice.

The Pivot Points: What Investigators Actually Use

Infrastructure investigation relies on several key data sources that sit outside structured threat feeds but are publicly accessible or commercially available.

Passive DNS records the historical resolution history of domains and IP addresses. Because malicious infrastructure frequently rotates, passive DNS allows investigators to see what an IP hosted in the past and what other addresses a domain has previously resolved to. This is often how analysts connect current indicators to prior campaigns.

SSL certificate data from certificate transparency logs is one of the most productive pivoting sources available. Operators of malicious infrastructure frequently reuse certificates across multiple servers or generate certificates from the same automated workflows, leaving patterns that connect otherwise unrelated infrastructure.

WHOIS and registration history remains useful even in an era of privacy registrations. Registration timing, registrar patterns, nameserver configurations, and historical registration data before privacy protection was applied can connect infrastructure across campaigns and operators.

ASN and hosting data helps identify infrastructure clusters. When multiple malicious domains sit on the same autonomous system or hosting provider with similar configuration patterns, that overlap is investigatively significant even when other indicators differ.

Network scanning data from platforms that continuously index internet-facing infrastructure reveals what services are running on a given IP, what certificates it presents, and how its configuration compares to related infrastructure. This helps analysts identify related servers even when direct domain or IP overlap is absent.

From Infrastructure to Behavior

Infrastructure pivoting reveals what is connected. Understanding what is actually happening requires a second investigative layer: connecting infrastructure to observed behavior, TTPs, and campaign context.

This is where OSINT investigation intersects with structured threat intelligence most productively. Once an analyst has mapped related infrastructure through pivoting, that infrastructure can be cross-referenced against malware reporting, incident post-mortems, threat actor tracking, and TTP databases to understand what campaigns or actor clusters have used it.

MITRE ATT&CK provides a useful framework here. If the infrastructure identified through pivoting has appeared in reporting that describes specific techniques, those techniques can be used to improve detection logic, inform hunting queries, and scope the investigation to look for behavioral evidence of those TTPs in internal telemetry.

The combination matters because infrastructure alone is circumstantial. Infrastructure connected to documented behavior and prior campaigns is operationally significant. It tells analysts what to look for internally, not just what to block externally.

Where This Fits in Real Workflows

The investigative approach described here is not a replacement for structured feed consumption. It is an additional layer that activates when an indicator warrants deeper understanding.

In SOC triage, the most immediate use is determining whether a feed-confirmed indicator is part of something larger before closing the alert. If pivoting from one IP reveals two uncategorized domains already in internal DNS logs, the incident scope changes significantly.

In threat hunting, investigators use OSINT pivoting proactively. Starting from known campaign infrastructure or actor-associated indicators, they expand outward to find related infrastructure and then search retrospectively across internal telemetry for evidence of contact with that infrastructure, even before it appears in any feed.

In incident response, OSINT investigation helps determine scope and containment boundaries. When an organization knows it has been exposed to a specific campaign, pivoting through the known infrastructure associated with that campaign helps identify what else may have been used in the intrusion that has not yet been flagged internally.

In fraud and financial crime investigations, the same pivoting techniques apply to domain infrastructure used in phishing campaigns, credential harvesting sites, and payment fraud operations.

What Gets Missed Without the Investigative Layer

Most security programs consume feeds competently. Fewer connect that consumption to active investigation, and the gap shows up in predictable ways.

Incidents get scoped too narrowly because analysts stop at the flagged indicator without checking whether related infrastructure has already made contact. Hunting remains reactive because teams wait for indicators to appear in feeds rather than pivoting from known campaign infrastructure to find what the feeds have not yet caught. Detections remain brittle because they are built on specific indicators rather than on the behavioral patterns and infrastructure relationships that persist even when individual indicators rotate.

Consider what that looks like in practice. A SOC team blocks a malicious IP, closes the alert, and moves on. Two weeks later, a separate alert fires on a domain that was quietly communicating with internal systems the entire time. That domain resolves to the same hosting cluster as the original IP. Had the first alert triggered an investigation rather than just a block, the related domain would have surfaced immediately. The second alert was not an escalation. It was the same incident, missed the first time because the indicator was treated as the end of the story rather than the beginning of one.

This is exactly what the comparison above illustrates. Stopping at the indicator leaves the broader infrastructure invisible. Investigating it surfaces what feeds have not yet caught.

The Takeaway

A threat feed gives you a signal. An investigation gives you understanding.

The gap between them is not a failure of feeds. Structured threat intelligence does exactly what it is designed to do. The gap is what happens when organizations treat indicator consumption as the end of the process rather than the beginning of one.

OSINT investigation extends structured intelligence by connecting indicators to the infrastructure, campaigns, and behavior behind them. The combination of passive DNS, certificate data, registration history, network scanning data, and behavioral reporting allows analysts to move from a single data point to a meaningful picture of what they are actually dealing with.

The strongest security programs treat every significant indicator as a question: what is this part of? The investigative layer is how they answer it.

FAQ

What is the difference between threat intelligence feeds and OSINT investigation? 

Threat intelligence feeds provide structured, automated data about known malicious indicators. OSINT investigation uses public infrastructure data, passive DNS, certificate logs, and registration records to understand the infrastructure, campaigns, and behavior connected to those indicators.

What is indicator pivoting in threat intelligence? 

Pivoting is the investigative technique of starting from one known data point, such as a malicious IP or domain, and expanding systematically through related infrastructure using passive DNS, certificate data, hosting patterns, and registration history to map connected infrastructure and campaigns.

Why do indicators expire so quickly? 

Malicious infrastructure rotates frequently. Attackers change IP addresses, register new domains, and move between hosting providers to avoid blocklists. This is why OSINT pivoting, which traces historical relationships rather than current states, often finds connections that current-state feeds miss.

How does OSINT investigation support incident response? 

During incident response, OSINT pivoting helps analysts map the full infrastructure associated with a campaign, identify related domains or IPs already in contact with internal systems, and connect the incident to prior reporting that describes attacker TTPs and behavior.

Where does MITRE ATT&CK fit into threat investigation? 

ATT&CK provides a behavioral framework for connecting infrastructure to observed techniques. Once OSINT pivoting maps related infrastructure to documented campaigns, ATT&CK helps analysts understand what techniques to look for internally and how to improve detection logic based on known attacker behavior.

Want to see how investigative OSINT platforms help analysts pivot from indicators to infrastructure? Book a personalized demo with one of our specialists and discover how SL Crimewall supports threat investigation, indicator enrichment, and campaign analysis through integrated OSINT workflows.