A Scenario Worth Recognizing
A mid-sized financial services firm notices repeated authentication attempts against their VPN gateway at 2:47 AM on a Tuesday. The source IP is unfamiliar. The security analyst on call runs it through a single threat intelligence feed, sees a clean reputation score, and marks it as low priority. Twelve hours later, three privileged accounts have been compromised and lateral movement is underway across two subnets.
The clean reputation score was accurate the day before the attack began. The IP had been freshly provisioned from a bulletproof hosting provider operating through a legitimate-looking ASN. A more thorough investigation would have surfaced that context within minutes. This is the gap that structured OSINT methodology closes.
Why Single-Source Lookups Fail Under Real Conditions
Most IP investigations start and end with a paste into VirusTotal or AbuseIPDB. Those tools have genuine value, but treating them as the final word creates a false sense of resolution. Reputation databases reflect historical behavior. A threat actor using freshly registered infrastructure or a newly hijacked clean IP will pass those checks without triggering a single flag.
The 0ktapus threat group, which compromised over 130 firms through phishing and credential theft campaigns, demonstrated exactly this pattern. Their infrastructure rotated frequently, leveraging hosting providers with responsive abuse handling that kept their IPs clean on major blocklists. Analysts who stopped at reputation checks missed the campaign entirely until internal telemetry surfaced it.
Effective IP investigation treats the IP address as a starting coordinate, not a destination. The goal is to build enough context around it to make an informed operational decision, and to do that quickly when the threat is active.
Passive DNS: The First Thread Worth Pulling
Passive DNS records capture historical resolution data, showing which domain names have pointed to a given IP address over time and when those associations existed. This is one of the highest-yield starting points in IP investigation because it reveals infrastructure reuse patterns that attackers rarely bother to clean up.
When you query a suspicious IP through a passive DNS provider like Farsight DNSDB, SecurityTrails, or RiskIQ (now part of Microsoft Defender Threat Intelligence), you are looking for several things. First, check how many domains have resolved to that IP. A residential or legitimate corporate IP typically shows one or a small number of domains. An IP serving as C2 or phishing infrastructure frequently shows dozens or hundreds of short-lived domain associations.
Second, look at the timing patterns. If multiple domains began resolving to the IP within the same 24-hour window, that is a strong signal of bulk provisioning, which is characteristic of automated threat actor infrastructure setup. Third, examine the domain names themselves for patterns. Typosquatting, brand impersonation, and randomized character strings all carry different implications for the type of threat you are dealing with.
In practice, an analyst investigating a suspected phishing IP might find through passive DNS that the same address hosted a credential-harvesting subdomain mimicking a major cloud provider three weeks ago, then transitioned to its current domain. That single data point elevates the threat classification significantly and informs the response decision.
WHOIS and RDAP: Reading the Registration Signal
WHOIS data has become less informative since GDPR-driven redaction became widespread, but it still carries meaningful signals when you know what to look for. Registration dates matter enormously. An IP block registered within the past 30 to 90 days warrants elevated scrutiny, particularly when the associated ASN has a history of abuse or operates in jurisdictions with limited abuse response infrastructure.
RDAP (Registration Data Access Protocol) is the modern successor to WHOIS and offers more structured, machine-readable output. Tools like the ARIN RDAP endpoint, RIPE's REST API, and regional Internet registry lookups provide ASN registration details, network block ownership, and abuse contact information. When investigating a suspicious IP, pull the full network block, not just the specific address. Look at how large the allocation is and whether the block appears to be a dedicated slice sold to a reseller or bulletproof hosting operator.
Pay attention to the abuse contact email. Legitimate hosting providers and ISPs maintain active abuse response mailboxes. Providers that list generic or non-functional abuse contacts, particularly those registered through privacy proxy services or using disposable email domains, are frequently associated with infrastructure that tolerates malicious use. This is not proof of malicious activity, but it is a meaningful risk signal.
Cross-reference the organization name in the WHOIS record against known threat intelligence. Some bulletproof hosting operations cycle through shell company names but reuse the same address blocks, contact details, or registration patterns. Tools like DomainTools Iris can surface these correlations automatically.
BGP and ASN Context: Understanding the Routing Environment
The Autonomous System Number associated with an IP address tells you something about the network environment where that IP exists. Not all ASNs carry equal risk profiles, and understanding the routing context helps you assess whether a given IP is operating from infrastructure commonly associated with threat activity.
BGP lookup tools including BGPView, Hurricane Electric's BGP Toolkit, and Team Cymru's IP to ASN mapping service let you quickly identify the ASN, the organization operating it, the countries it announces routes from, and the upstream providers it peers with. An IP that announces routes through multiple upstream providers simultaneously, or that shows route origin changes in recent BGP history, may indicate route hijacking activity, which has been used to intercept traffic in several documented nation-state campaigns.
The April 2026 CVE landscape and the ongoing discussions around ROADtools abuse in cloud environments highlight a broader trend: threat actors are increasingly layering network-level evasion techniques on top of application-layer attacks. Understanding the ASN context of a suspicious IP helps you identify whether you are dealing with commodity threat actor infrastructure, a compromised legitimate host, or the kind of sophisticated routing manipulation associated with nation-state activity like that detailed in the ROADtools and cloud-targeting campaigns.
For practical use, flag any IP whose ASN shows a high ratio of abuse reports relative to its total IP allocation. A small ASN with 256 addresses and 50 abuse reports in the past 30 days represents a fundamentally different risk than a major cloud provider's ASN with millions of addresses and a similar abuse count.
Shodan, Censys, and FOFA: Scanning for What the IP Is Actually Running
Internet-wide scanning platforms provide a snapshot of what services are exposed on a given IP, which certificates it presents, and what banner information its open ports return. This layer of investigation answers a different question than reputation or registration data: what is this IP actually doing on the internet right now?
Shodan indexes banners from HTTP, HTTPS, FTP, SSH, and hundreds of other service probes. When you look up a suspicious IP in Shodan, examine the open ports carefully. A consumer ISP-allocated IP with open ports 22, 80, 443, 4444, and 8080 is running a different operational profile than what you would expect from a residential connection. Port 4444 in particular has long been associated with Metasploit listener defaults. The BTMOB Android RAT family, recently documented for its stealthy persistence mechanisms, used non-standard ports for C2 communication in a pattern that Shodan-based pivoting could help surface across related infrastructure.
Censys offers complementary coverage and is particularly strong on TLS certificate data. Certificate analysis is one of the most powerful pivoting techniques available in IP investigation. Threat actors frequently reuse self-signed certificates or certificates issued to the same organizational identity across their infrastructure. If a suspicious IP presents a certificate with a specific subject organization name or serial number, you can search Censys for all IPs presenting the same or similar certificates. This technique has uncovered entire C2 networks from a single initial IP.
Look at certificate validity windows. Certificates valid for exactly 90 days and issued through Let's Encrypt are common in both legitimate deployments and threat actor infrastructure, but a self-signed certificate valid for 10 years on an IP running an unusual service combination is worth flagging. Cross-reference the certificate details with passive DNS to see whether the domains associated with that certificate also appear in threat intelligence databases.
Threat Intelligence Platform Correlation: Connecting the Dots Across Sources
Individual OSINT sources answer narrow questions. Threat intelligence platforms aggregate and correlate across sources to surface relationships that individual lookups miss. OpenCTI, MISP, and commercial platforms like Recorded Future, ThreatConnect, and Mandiant Advantage let you pivot from an IP to related indicators including file hashes, URLs, domains, and threat actor profiles.
When running an active investigation, the workflow should move through these correlation layers systematically. Start with the IP, pull its passive DNS history, identify related domains, check those domains for associated file hashes in malware sandboxes like Any.run, Hybrid Analysis, or VirusTotal's sandbox results, and then work backward to identify other IPs that hosted those same domains or delivered those same files. This approach frequently reveals infrastructure clusters that allow you to block or monitor a set of related addresses rather than responding to each one individually.
MISP particularly shines for team-based investigation. When multiple analysts are working an incident simultaneously, shared MISP events let each person contribute findings in real time, building a growing picture of the threat actor's infrastructure. The 0ktapus campaign referenced earlier was ultimately mapped to a broader infrastructure cluster through exactly this kind of collaborative OSINT work, which enabled defenders to get ahead of the rotation cycle rather than chasing each new IP after the fact.
Geolocation Verification: Trusting the Data Appropriately
IP geolocation provides useful context but carries inherent accuracy limitations that matter operationally. MaxMind GeoIP2, ip-api, and ipinfo.io all provide geolocation data derived from a combination of WHOIS registration data, BGP routing information, and active measurement. City-level accuracy varies significantly by region and IP type.
The more important discipline is cross-referencing geolocation against ASN data and passive DNS. An IP that geolocates to Frankfurt but belongs to an ASN registered in Hong Kong with abuse contacts pointing to Eastern Europe, hosting domains with Russian-language content in its passive DNS history, represents a different threat profile than an IP that geolocates to Frankfurt and belongs to a Frankfurt-registered German hosting provider with clean ASN history.
VPN and proxy detection is an extension of this cross-referencing process. Services like IPQualityScore, IP2Proxy, and Spur.us maintain databases of known VPN endpoints, residential proxy nodes, Tor exit nodes, and hosting provider ranges. When a suspicious IP resolves as a residential address in geolocation but appears in proxy detection databases, that discrepancy is itself a meaningful signal. Residential proxy networks in particular have become a favored evasion technique because their IP addresses carry lower suspicion than datacenter ranges, yet they are being used to route malicious traffic through unwitting residential internet users' connections.
Documenting and Pivoting: Turning Investigation Into Operational Output
An IP investigation that produces context but no action is incomplete. The output of a structured OSINT investigation should feed directly into operational decisions and team knowledge bases.
For each investigation, maintain a structured record that includes the original IP, all related indicators discovered through pivoting, the data sources consulted, timestamps for when data was collected (because OSINT data degrades quickly), the confidence level of each finding, and the recommended action. Tools like Maltego automate much of the pivoting workflow and produce visual link graphs that make infrastructure relationships immediately apparent during incident briefings.
The recommended action categories for IP investigation findings typically fall into one of four buckets: block at perimeter, monitor with elevated alerting, submit to threat intelligence sharing platforms, or escalate for law enforcement referral in cases involving confirmed criminal activity. Each category has different implementation steps and team responsibilities, and having those defined in advance of an incident significantly reduces decision latency when a real threat is active.
NIST's recent NVD enrichment policy changes, which now prioritize vulnerabilities with confirmed attacker behavior signals, reflect the same operational philosophy: raw data without behavioral context produces false confidence. The same principle applies to IP investigation. An IP address is data. The passive DNS history, ASN context, certificate data, and threat intelligence correlations built around it are what transform that data into actionable intelligence.
Practical Implementation for Security Teams
Building an IP investigation workflow that functions under time pressure requires preparing the toolchain before an incident demands it. The following steps represent a baseline implementation that cybersecurity professionals and IT administrators can deploy without significant budget.
- Free tier tools to configure now: Shodan (free account with limited daily queries), Censys (free researcher account), VirusTotal, AbuseIPDB, BGPView, Hurricane Electric BGP Toolkit, and the ARIN/RIPE/APNIC RDAP APIs all provide substantial capability at no cost.
- Automate initial triage: Scripts using Python libraries like shodan, python-whois, and direct API calls to AbuseIPDB and VirusTotal can produce a structured initial report on any IP within 30 to 60 seconds. Having this automation ready means the first-level analyst can get enriched context before deciding whether to escalate.
- Create pivot templates: Document the specific queries and tools used for each pivot step so that any analyst on the team can execute the same workflow. This reduces the skill dependency that causes investigation gaps during off-hours incidents.
- Integrate with SIEM: Most modern SIEM platforms support threat intelligence enrichment through connector frameworks. Automating IP lookups against your threat intelligence sources at alert creation time means analysts see enriched context from the moment they open a ticket, rather than needing to initiate investigation manually.
- Establish a retention policy for investigation artifacts: OSINT data captured at the time of investigation is forensically valuable even after the threat actor has rotated their infrastructure. Preserve screenshots, API responses, and pivot maps with timestamps as part of your case documentation.
Closing the Gap Between Data and Decision
IP investigation is a skill that compounds with practice. Each investigation surfaces new infrastructure patterns, new hosting providers worth watching, and new pivot techniques applicable to future cases. The analysts who become effective at this work are those who treat every suspicious IP as an opportunity to build their understanding of the threat landscape, not just a checkbox to clear before moving on.
The scenario described at the opening of this article is preventable. Not because the threat actor made obvious mistakes, but because a structured investigation workflow would have surfaced the hosting provider's reputation, the recent ASN registration date, and the bulk domain provisioning pattern in the passive DNS record, all within a few minutes of that first authentication alert. That context would have changed the response decision from low priority to active investigation before the first account was compromised.
The tools exist. The methodology is documented. The gap is in consistent application under operational conditions, and closing that gap is a training and process problem as much as a technology one.
