The Alert That Started a Rabbit Hole
A mid-sized financial services firm received a spike in failed authentication attempts targeting their VPN gateway over a weekend. The source IPs rotated every few minutes, but a pattern emerged: several of them resolved to the same ASN, and a few appeared in no known blocklist. The security analyst on call had two choices — block and move on, or investigate. She chose to investigate, and within two hours had mapped a P2P botnet segment, identified infrastructure shared with a known threat cluster, and tied three of the IPs to a hosting provider with a history of abuse complaints. None of that came from a commercial threat feed. It came from systematic OSINT.
This article walks through the practical OSINT workflow for IP investigation that experienced defenders use in the field, covering tools, pivot techniques, and how to build a coherent picture from scattered data points.
Why IP Investigation Still Matters in 2026
IP addresses remain the connective tissue of network-based attacks. Even when threat actors rotate infrastructure, abuse cloud providers, or route through compromised routers (as Russian intelligence services did to steal Microsoft Office tokens by hijacking edge devices), the IP layer leaves fingerprints. Campaigns like those attributed to Lazarus Group consistently reuse hosting patterns, ASN clusters, and registration behaviors that OSINT surfaces when analysts know where to look.
P2P botnets, which continue to evolve as documented in ongoing monitoring research, present a particular challenge because their nodes are often legitimate residential or business IPs. Standard reputation lookups miss them. OSINT-driven investigation fills that gap.
Building Your Investigation Toolkit
Before walking through the workflow, it helps to have a clear picture of the tools you will actually use. These fall into a few functional categories.
Passive DNS and Registration Data
- Shodan — Indexes banners, services, and certificates. Essential for understanding what a host is running and when it first appeared.
- Censys — Similar to Shodan but with stronger TLS certificate indexing, useful for finding shared infrastructure through certificate subjects or serial numbers.
- WHOIS and RDAP — The baseline. Always run it, even when you expect the data to be privacy-protected. Registrar, registration date, and nameserver data remain useful even without contact details.
- PassiveDNS platforms (Passive Total, SecurityTrails, DNSDB) — Show historical DNS resolutions, revealing what domains an IP has hosted and what IPs a domain has pointed to over time.
Routing and Network Intelligence
- BGP.he.net (Hurricane Electric BGP Toolkit) — Shows ASN assignments, prefix announcements, and peering relationships. Free and fast.
- RIPEstat and ARIN Whois — Provide allocation history, abuse contacts, and route object data for IP blocks.
- Routeviews and RIPE RIS — For analysts who need raw BGP data to trace routing anomalies or hijacks.
Threat Context and Cross-Referencing
- VirusTotal — Aggregates detection results from dozens of engines and includes community comments, passive DNS, and related samples.
- AbuseIPDB — Community-reported abuse history. Useful for context, less useful as a sole decision point.
- Shodan InternetDB API — Lightweight API that returns open ports, tags, and hostnames for quick triage.
- CIRCL.lu Passive DNS — Free passive DNS service with solid coverage for European infrastructure.
Geolocation and Hosting Context
- ipinfo.io and ip-api.com — Fast geolocation and hosting type detection. Look for fields like org, hosting, and privacy to distinguish datacenter from residential.
- MaxMind GeoIP2 — The industry standard for geolocation databases, particularly when you need offline lookups at scale.
The Core Investigation Workflow
A structured workflow prevents the rabbit hole from becoming unproductive. The following sequence moves from triage through pivot analysis to attribution context.
Step 1: Initial Triage
Start with the basics before touching any pivot. For a given IP, establish:
- ASN and organization — Is this a datacenter, a residential ISP, a cloud provider, or a known hosting-for-hire service? Run a BGP lookup via Hurricane Electric or RIPEstat immediately. Datacenter IPs from providers with permissive abuse policies (certain Eastern European or Central Asian ASNs, for example) warrant higher suspicion.
- Geolocation — Note the country and city, but treat it as approximate. More important is whether the geolocation aligns with the stated organizational context.
- Abuse history — Query AbuseIPDB and VirusTotal. A clean score does not mean clean; it means unreported. A high abuse score is meaningful context.
- Open services — A quick Shodan or Censys lookup reveals what ports are open and what banners they serve. An IP running SOCKS5, OpenVPN, or unusual SSH configurations on non-standard ports is a signal.
Step 2: Passive DNS Pivoting
Passive DNS is where IP investigation becomes genuinely powerful. The goal is to answer two questions: what domains has this IP hosted, and do those domains connect to known bad infrastructure?
Query SecurityTrails or Passive Total for the IP. Look at the full resolution history, not just current records. Threat actors frequently reuse IPs across campaigns, so a domain resolved to the target IP six months ago may appear in prior threat reports. Search that domain in VirusTotal and cross-reference it against open-source threat intel repositories like abuse.ch or URLhaus.
Run the reverse query as well: take any suspicious domain you find and query what other IPs it has resolved to. This technique, sometimes called forward-then-reverse pivoting, often reveals entire infrastructure clusters from a single starting IP. During Lazarus Group campaign analysis, this method has repeatedly uncovered shared command-and-control infrastructure that no single IP lookup would have surfaced.
Step 3: Certificate Intelligence
TLS certificates are among the most consistent artifacts threat actors leave behind. Reusing certificates, or reusing certificate attributes like organization names, email addresses, or subject alternative names, connects infrastructure that appears unrelated at the IP level.
In Censys, search for a certificate thumbprint or subject CN associated with your target IP. Identify other hosts presenting the same certificate. Even self-signed certificates are useful here because threat actors often generate them with identical parameters across deployments. The TeamPCP group's recent SAP-targeting campaign showed exactly this pattern: infrastructure that appeared dispersed at the IP level shared certificate metadata that connected it decisively.
Crt.sh is a free certificate transparency log search tool. Search for a domain or organization name and review certificate issuance history. Newly issued certificates from providers like Let's Encrypt on infrastructure that appeared recently and lacks other context are worth flagging.
Step 4: Banner Grabbing and Service Fingerprinting
When you have access to active scanning capabilities (in authorized environments or through Shodan's pre-collected data), service banners tell you a great deal about infrastructure purpose and operator habits.
Specific things to look for include:
- SSH server versions and hostnames in banners, which are often consistent across an operator's infrastructure
- HTTP server headers including unusual Server values, custom X- headers, or default web application pages that indicate a specific tool or framework
- JARM fingerprints (available in Shodan and through standalone tools) for TLS server identification — JARM has proven effective at identifying Cobalt Strike, Metasploit, and other offensive toolkits at scale
- Favicon hashes, which Shodan indexes and which can link hosts running identical web applications
The modified CIA Hive implant that has appeared in criminal markets includes recognizable service behaviors. Analysts familiar with its original Vault7 documentation can identify deployments through banner and response characteristics, demonstrating how OSINT techniques translate directly to detecting specific attacker tooling.
Step 5: Network Graph Construction
By this point you likely have multiple related IPs, domains, ASNs, and certificates. The next step is making those relationships visible. Even a simple spreadsheet with columns for entity type, value, relationship type, and source creates a structured record. Purpose-built tools add visual clarity.
Maltego is the traditional choice for visual link analysis, with transforms for Shodan, VirusTotal, PassiveTotal, and many other OSINT sources built in. For analysts who prefer a free option, SpiderFoot automates much of the pivoting workflow and produces relationship graphs from a starting IP. For lightweight ad-hoc work, draw.io or even Obsidian with a graph view works well for manual mapping.
The goal of the graph is to identify shared infrastructure nodes: IPs connected to many domains, domains that appear across multiple campaigns, ASNs that host a disproportionate share of suspicious endpoints. These hubs are where attribution context emerges.
Step 6: Cross-Referencing Threat Intelligence Sources
With a cluster of related IPs and domains in hand, move to structured threat intelligence sources to see whether any of these indicators appear in prior research.
- MISP instances (including the public CIRCL instance) — Search for your IPs and domains. MISP events often contain campaign context, MITRE ATT&CK mappings, and related indicators that dramatically accelerate analysis.
- OpenCTI — If your organization runs OpenCTI, it aggregates multiple feeds and provides relationship context that connects your indicators to threat actor profiles.
- Abuse.ch Feodo Tracker and ThreatFox — Specifically focused on banking trojans, botnets, and malware C2 infrastructure. Essential for industrial and financial sector incidents.
- Twitter/X and Mastodon threat intel community — Researchers frequently publish real-time findings about new infrastructure before any formal platform indexes it. Searching for an IP or ASN in these communities often surfaces cutting-edge context.
For P2P botnet investigation specifically, cross-referencing against P2P network monitoring data (projects like the Shadowserver Foundation's tracking of Mirai variants or specialized academic monitoring efforts) can identify whether a suspicious IP is acting as a peer node, a tracker, or a command node in a distributed botnet architecture.
Real-World Scenario: Tracing a Scanning IP Back to a Campaign
Consider a concrete example. A web application firewall logs repeated requests probing for SAP NetWeaver vulnerabilities from a single IP: 185.220.x.x. Here is how the investigation would unfold using the workflow above.
Initial triage reveals the IP is allocated to a Tor exit node operator in Germany. This context matters: it means the actual threat actor is not at that geographic location, but it also means the actor is using Tor to anonymize scanning activity, which is common among more operationally aware threat groups.
However, the passive DNS history for that IP shows it also hosted a domain — call it update-cdn[.]net — outside of its Tor exit window two months prior. That domain resolves in VirusTotal as associated with a downloader campaign. Certificate transparency logs show update-cdn[.]net shares a Let's Encrypt certificate with three other domains, two of which appear in MISP events tied to a specific initial access broker cluster.
A BGP lookup on the ASN hosting those two additional domains shows it is the same provider used in the TeamPCP SAP-targeting campaign documented recently. The scanning IP, through passive DNS and certificate pivoting, connects to infrastructure that extends well beyond a simple Tor exit probe.
The response is now targeted: block the associated domains at DNS, add the certificate thumbprint to TLS inspection rules, notify the SAP team to prioritize patching, and escalate the MISP event findings to the threat intelligence team for formal tracking.
Industrial and OT Network Considerations
The Q4 2025 threat landscape report for industrial automation systems highlighted an increase in reconnaissance activity targeting ICS-exposed interfaces. OSINT-based IP investigation has direct application here. Shodan's ICS-specific filters (searching for Modbus, DNP3, or BACnet banners) allow defenders to verify whether their own infrastructure is inadvertently exposed and to identify external IPs that have been observed scanning for those same protocols.
For OT defenders, the workflow above applies with one adjustment: passive DNS pivoting on IPs that probe ICS protocols should include checking against the ISC SANS Internet Storm Center's daily reports, which frequently document scanning campaigns against industrial protocols with source IP data. Cross-referencing your incident IPs against ISC DShield data is fast and often reveals whether you are seeing targeted probing or widespread automated scanning.
Operational Security During Investigation
Active querying against threat actor infrastructure carries risk. When you query a domain or IP directly (rather than through pre-collected data), you can generate DNS or HTTP traffic that a sophisticated operator may notice. For high-priority investigations, use a VPN or dedicated investigation infrastructure that does not resolve back to your organization.
Use APIs rather than web interfaces where possible for the same reason. Shodan's API, Censys's API, and SecurityTrails's API all return data without generating referrer headers that might tip off a target. For particularly sensitive investigations, route queries through a residential proxy or use a cloud-hosted analyst workstation in a neutral geography.
Documenting and Acting on Findings
OSINT investigation produces value only if the findings are documented and actioned. A standard investigation report should include:
- The starting indicator and investigation trigger
- Each pivot step with the tool used, the query, and the result
- The relationship map as an exported image or structured data file
- Confidence levels for each attribution claim (observed fact versus reasonable inference versus speculative connection)
- Recommended defensive actions with specific implementation targets (firewall rules, DNS sinkhole entries, EDR detections)
Feeding confirmed indicators back into your SIEM and threat intelligence platform closes the loop. IPs and domains identified through OSINT investigation today become detection rules and blocklist entries that protect against the next campaign using the same infrastructure.
Where OSINT Meets Its Limits
OSINT is powerful but bounded. It surfaces publicly available information and historical data. A fresh IP with no history, no associated domains, and no banner fingerprint match is genuinely opaque to passive analysis. In those cases, behavioral analysis of the traffic itself (volume, timing, payload patterns) becomes the primary signal, which is a separate discipline from what this article covers.
Attribution conclusions drawn from OSINT alone should be held provisionally. Infrastructure overlap can reflect shared hosting providers, not shared operators. The Lazarus Group's continued effectiveness demonstrates that sophisticated actors are aware of OSINT techniques and deliberately introduce noise into their infrastructure patterns to complicate attribution. Treat OSINT findings as investigative leads and corroborate them with additional sources before drawing firm conclusions.
Putting It Into Practice
The next time an unfamiliar IP appears in your logs, resist the impulse to simply check a single reputation database and move on. Run the triage sequence, pull passive DNS history, check certificate intelligence, and map the network relationships. The process takes fifteen to thirty minutes for a basic investigation and can surface campaign context that changes your defensive response entirely.
Build the workflow into a runbook so that junior analysts can execute it consistently. Create saved searches in Shodan and Censys for your organization's IP ranges so you receive alerts when new services appear on your infrastructure. And contribute findings back to community platforms: the abuse reports, MISP events, and threat intelligence published by organizations that share create the very data that makes OSINT investigation possible for everyone.
