The Investigation That Changed How a SOC Team Thinks About IP Data
In early 2025, a mid-sized financial services firm flagged a series of authentication attempts originating from an IP block that looked, on the surface, like a legitimate cloud hosting range. The IP reputation feeds said clean. The geolocation said Western Europe. The volume was low enough to avoid rate-limit alerts. It was only when the SOC analyst cross-correlated that single IP against five separate open-source intelligence sources simultaneously that the picture shifted: the address belonged to a bulletproof hosting reseller operating under a legitimate-looking AS, had appeared in passive DNS records tied to a phishing campaign targeting APAC financial institutions three months earlier, and was part of an infrastructure cluster that shared SSL certificate fingerprints with a known espionage actor.
That kind of finding does not come from running an IP through one lookup tool. It comes from a structured OSINT workflow that treats each data source as a layer in a composite picture rather than a standalone verdict. With ransomware attacks continuing to rise and groups like Armored Likho actively expanding their toolkit, the pressure on security teams to move faster on raw IP data has never been higher. The question is whether speed is leading teams to shortcut the cross-correlation work that actually produces actionable intelligence.
Why Single-Source IP Lookups Produce Incomplete Pictures
Most IP investigation workflows in active SOC environments start and end with a reputation feed or a WHOIS lookup. That approach was adequate when threat actors operated on predictable infrastructure with stable registration patterns. Modern attack infrastructure operates differently. Hosting is rented through resellers. Certificates rotate every 30 to 90 days. AS ownership can be obscured through multiple layers of transit agreements. The Armored Likho group, for example, has demonstrated a pattern of repurposing legitimate cloud infrastructure in ways that make single-source reputation checks unreliable during the early hours of a campaign.
The practical consequence is that a clean reputation score tells you about historical behavior on a given IP, not about the current operator or current use. Passive DNS tells you what that IP was resolving to in the past. BGP routing data tells you which AS is announcing it and whether that AS has a history associated with abuse. SSL/TLS certificate transparency logs tell you what other domains share the same certificate issuer chain or organization field. Putting those four things together tells you something that none of them tells you individually.
The Five Open Sources Worth Running in Parallel
Passive DNS Repositories
Passive DNS data captures the relationship between IP addresses and domain names over time by collecting resolver queries at scale. Tools like SecurityTrails, DNSDB, and the RiskIQ (now Microsoft Defender Threat Intelligence) passive DNS index allow analysts to query which domains have resolved to a given IP, when those resolutions occurred, and how long the association lasted.
For IP investigations, this matters because threat actors reuse infrastructure. A command-and-control domain that was active six months ago may have been replaced, but if the replacement is hosted on the same IP, passive DNS will show you the historical pattern before the current campaign fully matures. During the investigation workflow, query the target IP and examine any domains that resolved to it within the past 12 months. Look for registration clustering, shared name servers, and patterns in domain naming conventions that suggest automation or bulk registration.
BGP and Autonomous System Data
Every IP address on the public internet is announced by an autonomous system. That AS has an operator, a registration history, and a routing behavior pattern that open sources can surface. Tools like BGPView, Hurricane Electric's BGP Toolkit, RIPE NCC's routing registry, and Team Cymru's IP-to-ASN mapping provide structured access to this data.
The key investigative questions at this layer are: Who is announcing the block containing the target IP? Has that AS changed hands recently? Does the AS peer with networks that have documented abuse histories? Bulletproof hosting operations frequently appear in AS data as small, recently registered networks with limited peering relationships and hosting located in jurisdictions with weak abuse reporting enforcement. Cross-referencing the AS number against abuse databases like AbuseIPDB's AS-level reports and Spamhaus's ASN DROP list can surface risk signals that IP-level reputation data misses entirely.
Certificate Transparency Logs
Every publicly trusted TLS certificate issued since 2018 is logged in one or more certificate transparency logs, and those logs are queryable through tools like crt.sh, Censys, and Google's Transparency Report. For IP investigations, certificate transparency data allows analysts to identify what domains have been associated with a given IP by querying certificates that include that IP in the Subject Alternative Name field, or by querying certificates issued to domains that passive DNS associates with the IP.
The investigative value here lies in infrastructure clustering. Threat actors who manage multiple domains across related operations often use the same certificate authority, the same organization name in certificate metadata, or the same wildcard certificate structure. Identifying one malicious domain and then searching certificate transparency logs for other certificates sharing those attributes can expand the scope of a campaign map significantly. This technique proved useful in tracking infrastructure related to several phishing campaigns that emerged following the broader Hugging Face platform security incidents discussed at Black Hat USA 2026, where researchers noted that attackers pivoted across multiple domains sharing common certificate issuance patterns.
Shodan and Censys Infrastructure Fingerprinting
Both Shodan and Censys conduct continuous internet-wide scans and index the services, banners, and configurations exposed by IP addresses. For a target IP, these tools return what ports are open, what software versions are advertising themselves, what HTTP headers look like, and what default credentials or configurations might be present.
In an active investigation, infrastructure fingerprinting answers whether the services running on a suspect IP are consistent with its claimed purpose. A hosting provider IP that claims to be a residential broadband address but is running an exposed Cobalt Strike team server or a suspicious JARM fingerprint is telling you something important regardless of what the reputation feed says. JARM fingerprinting in particular has become a standard technique for identifying command-and-control infrastructure because certain frameworks produce consistent TLS handshake patterns that are detectable even when domain names rotate. Censys provides JARM data in its host records, and cross-referencing that against public JARM blocklists maintained by security researchers can surface infrastructure that is days old and not yet in any reputation feed.
Threat Intelligence Sharing Platforms and Community Reports
AlienVault OTX, ThreatFox, Malware Bazaar, and VirusTotal's graph view all aggregate community-submitted threat indicators that include IP addresses, and more importantly, they provide context around those indicators in the form of associated malware samples, campaign tags, and analyst comments. The community data layer is where you find the freshest intelligence, because researchers and incident responders submit indicators in real time during active campaign responses.
The investigative workflow here involves querying the target IP across these platforms and examining not just whether it appears as a known indicator, but what it is tagged with, what malware families reference it in their configuration data, and what other IPs appear in the same pulse or campaign cluster. ThreatFox in particular has become a critical resource for correlating IPs against malware command-and-control configurations submitted from sandboxed samples, which means that an IP appearing there likely has a crypter-protected payload submission in Malware Bazaar referencing it. With malware crypting services now documented as a commercial threat actor service category, the probability of a flagged IP having associated sandbox submissions is higher than it was two years ago.
Building the Cross-Correlation Workflow
Running these five sources individually is straightforward. Running them in a way that produces structured, usable correlation requires a documented process. The following workflow represents a practical implementation for a SOC analyst working an active alert.
- Start with BGP context. Before querying reputation databases, establish who owns the IP at the network level. Pull the ASN, check registration date, identify the operator, and check the AS against Spamhaus ASN DROP and known bulletproof hosting lists. This takes two minutes and establishes the foundational risk context.
- Pull passive DNS history. Query SecurityTrails or DNSDB for domains that have resolved to the IP in the past 12 months. Document domain names, registration dates, name servers, and registrars. Flag any domains that match known malicious naming patterns or that cluster around registration events.
- Query certificate transparency. Run crt.sh against any domains identified in the passive DNS step. Look for shared certificate attributes. Document organization names, certificate authorities, and SAN field entries that suggest additional related infrastructure.
- Fingerprint the exposed surface. Run a Shodan or Censys query against the target IP. Document open ports, service banners, HTTP headers, and JARM fingerprints. Cross-reference JARM values against public datasets maintained by researchers tracking Cobalt Strike, Metasploit, and other frameworks.
- Correlate against community threat intelligence. Query OTX, ThreatFox, and VirusTotal Graph using the target IP and any associated domains or certificate attributes identified in prior steps. Build a relationship map that shows which indicators co-occur across sources.
The output of this process is a structured indicator cluster, not a single verdict. That cluster allows you to make decisions about blocking, escalation, and threat hunting that a single reputation score cannot support.
Telemetry Interpretation Under Adversarial Conditions
One of the most important skills in IP OSINT is distinguishing between infrastructure that is actively malicious and infrastructure that was recently compromised and is being used as a proxy hop. The telemetry signals differ in detectable ways. A compromised legitimate server typically shows a long history of legitimate domain associations in passive DNS, has an AS with a clean historical profile, and shows services consistent with its stated purpose alongside anomalous new services like unexpected open ports or unusual banner changes.
Purpose-built attack infrastructure, by contrast, tends to show recent registration dates in both the IP allocation and any associated domains, AS relationships with limited peering history, certificate issuance patterns consistent with automated bulk issuance, and infrastructure fingerprints that match known offensive tooling. Groups like the China-linked threat actors recently observed conducting AI-augmented attacks across APAC targets have demonstrated sophisticated infrastructure construction that mimics legitimate cloud hosting patterns at the AS level while revealing tooling fingerprints at the service layer. That kind of nuance only surfaces when the cross-correlation workflow is running at full depth.
Automation and Tooling Considerations
Manual cross-correlation across five sources is feasible for a single high-priority IP but does not scale to the volume of IPs that a modern SOC processes daily. Building automation around this workflow requires API access to each source and a structured data pipeline that normalizes output formats and surfaces correlation hits. Several open-source frameworks support this, including OpenCTI, MISP with appropriate enrichment modules, and TheHive with Cortex analyzers configured for each data source.
For teams operating without dedicated threat intelligence platforms, a Python-based enrichment script using the APIs of SecurityTrails, Shodan, and ThreatFox can be integrated into SIEM workflows as an automated enrichment step triggered on any outbound connection alert or authentication alert. The script queries each source, normalizes the output into a structured JSON object, and appends it to the alert record. Analysts then work from pre-enriched alerts rather than running manual lookups under time pressure.
Microsoft's recent patch releases covering nearly 400 security vulnerabilities serve as a reminder that the volume of exploitable surface area continues to grow, and that IP investigation workflows need to be fast enough to keep pace with exploitation timelines. Automation is not optional at the scale that modern infrastructure generates alerts.
Practical Defensive Controls That Follow From IP OSINT Findings
The purpose of an IP investigation is not the investigation itself. It is the downstream action that the investigation supports. Cross-correlation findings map to specific defensive controls in direct ways.
An IP that clusters with known bulletproof hosting infrastructure via AS relationships justifies AS-level blocking rather than single-IP blocking, which closes the gap that forms when the operator rotates to a new IP within the same range. An IP that shows certificate attributes shared with active malware command-and-control infrastructure justifies threat hunting queries across endpoint telemetry looking for connections to any domain in the identified certificate cluster. An IP that appears in ThreatFox tagged to a specific malware family justifies pulling all associated malware configuration data and running those configurations against network captures to identify any lateral movement that occurred before detection.
Inside a modern SOC, identity systems are increasingly the first point of contact for adversary activity, and IP investigation findings should feed directly into identity-layer controls. If an IP correlates with a known credential stuffing campaign cluster, that finding should trigger immediate review of any authentication events associated with that IP across Active Directory, Entra ID, or equivalent systems, regardless of whether those authentications succeeded.
Where Most Teams Stop Short
The common failure pattern in IP OSINT is stopping at the first positive result. An analyst queries a reputation feed, gets a hit, blocks the IP, and closes the ticket. That approach handles the immediate indicator but leaves the associated infrastructure, the campaign cluster, and the potential lateral movement entirely unaddressed.
The five-source cross-correlation workflow described here exists precisely to prevent that failure. The IP is the entry point to a broader infrastructure map. That map contains the information needed to get ahead of the next wave, to build blocking rules that hold when the actor rotates, and to identify whether the activity you detected is part of a campaign that has already placed other indicators inside your environment. With ransomware groups increasing attack frequency and AI-augmented threat actors demonstrating faster operational tempos, the depth of initial IP investigation directly affects how much ground you have to recover after the first detection.
