When the Alert Fires and the IP Tells You Nothing by Itself
A mid-size financial services firm received an after-hours alert: an internal workstation was making repeated outbound connections to an unfamiliar IP address in Eastern Europe. The on-call analyst pulled the IP, ran it through one threat intelligence feed, saw no flags, and closed the ticket as a false positive. Three days later, the same IP was confirmed as a command-and-control node in an active intrusion campaign targeting financial institutions. The workstation had been exfiltrating credentials the entire time.
The failure was procedural. The analyst had one data source and stopped there. OSINT-based IP investigation is not a single lookup — it is a layered, iterative process that builds a picture from multiple angles before drawing conclusions. This article walks through that process in practical terms, oriented toward cybersecurity professionals and IT administrators who need to move quickly without missing critical context.
What You Are Actually Trying to Establish
Before opening any tool, clarify the questions your investigation needs to answer. An IP address in isolation tells you very little. What you are building toward is a profile that covers ownership, infrastructure context, behavioral history, and relationship to known threat actors or campaigns.
The core questions for any IP investigation are:
- Who owns and operates this IP address and the infrastructure around it?
- What organization or ASN is responsible for the netblock?
- Has this IP appeared in threat intelligence feeds, abuse reports, or known attack campaigns?
- What services does this IP expose, and do those services match its claimed purpose?
- Does the IP show signs of being a proxy, VPN exit node, hosting provider, or residential address?
- What domains have resolved to this IP, historically and currently?
- Is this IP associated with other IPs or infrastructure that appears in your environment?
Each of these questions maps to a specific set of OSINT sources and techniques. Skipping layers is where investigations go wrong.
Passive Reconnaissance: Starting Without Touching the Target
Passive reconnaissance means gathering information without sending any traffic to the IP in question. This matters operationally because active probing can tip off an attacker monitoring their own infrastructure, and in some jurisdictions active scanning of systems you do not own carries legal risk.
WHOIS and Regional Internet Registry Data
Start with WHOIS data from the relevant Regional Internet Registry (RIR). For addresses in North America, that is ARIN. For Europe, RIPE NCC. For Asia-Pacific, APNIC. For Latin America, LACNIC. For Africa, AFRINIC.
WHOIS gives you the registered organization, the abuse contact email, the netblock range, and registration dates. Pay attention to netblock size. A single /32 assignment registered to an individual with a free email address is a different risk profile than a /24 assigned to a known cloud provider. Also check the organization name carefully — threat actors frequently register infrastructure under names that mimic legitimate companies, sometimes using slight misspellings or generic terms.
The RIPE database in particular has a route object system that shows which ASN is announcing a given prefix. Cross-reference the announcing ASN against the registered owner. When those two do not match, it can indicate IP hijacking or reseller arrangements that obscure the actual operator.
ASN Context and Routing History
The Autonomous System Number associated with an IP tells you a great deal. Tools like BGPView, Hurricane Electric's BGP toolkit, and RIPE's Routing Information System (RIS) let you look up current and historical route announcements.
Certain ASNs consistently appear in threat intelligence as bulletproof hosting providers — operators who knowingly or permissively host malicious infrastructure. When an IP resolves to one of these ASNs, your risk assessment shifts significantly even if the IP itself has no individual abuse history yet. The OceanLotus group, suspected of using PyPI to deliver ZiChatBot malware, routinely leverages hosting infrastructure in ASNs with permissive abuse policies precisely because individual IP reputation lags behind ASN-level patterns.
BGP routing history also reveals short-lived announcements. An IP that has been announced and withdrawn multiple times in a short window is behaving like infrastructure that gets recycled — a common pattern in command-and-control operations.
Passive DNS: The Historical Record of Hostnames
Passive DNS databases record DNS resolutions over time. When a domain resolves to an IP, that relationship gets logged. Later, even if the domain points somewhere else, the historical record remains searchable.
Services like Farsight DNSDB, SecurityTrails, PassiveTotal (now part of the RiskIQ service within Microsoft Defender Threat Intelligence), and VirusTotal all provide passive DNS data. For the IP under investigation, query which domains have historically resolved to it.
A cluster of domains all resolving to the same IP, especially domains that share registration patterns, hosting timelines, or naming conventions, is strong evidence of coordinated infrastructure. Look for domains that were registered recently, use privacy protection, share registrar accounts, or follow a naming pattern suggesting automation. This technique is how researchers pivot from a single suspicious IP to a full infrastructure map.
When SecurityScorecard acquired Driftnet to expand its threat intelligence capabilities, passive DNS pivoting was central to the value proposition — the ability to map adversary infrastructure by following the connections between IPs and domains over time rather than reacting to known-bad indicators in isolation.
Open Source Intelligence Sources for IP Context
Shodan, Censys, and FOFA
Shodan, Censys, and FOFA are internet-wide scan databases. They crawl the IPv4 address space continuously and store banners, certificates, open ports, and service fingerprints. Querying an IP in any of these services shows you what services that host is running, what TLS certificates it presents, and when it was last seen.
Certificate data is particularly useful. A self-signed TLS certificate on port 443 that shares a Common Name or Organization field with certificates seen on other IPs links those hosts together. The SHA-256 hash of a certificate can be queried across Censys to find every IP presenting the same certificate — a reliable method for finding infrastructure that belongs to the same operator.
Shodan's historical data shows when services appeared and disappeared. An IP that ran an open SOCKS proxy for two weeks and then went dark, followed by a new server appearing on the same netblock, is showing the recycling behavior common to adversary infrastructure. The VECT ransomware group, which researchers found operated as a wiper in some deployments, used exactly this kind of short-lived infrastructure to complicate attribution.
Pay attention to Shodan tags. Shodan categorizes hosts automatically as honeypots, Tor nodes, VPN endpoints, or malware C2s based on behavioral signals. These tags are not perfect, but they provide a fast triage signal.
Threat Intelligence Aggregators
Aggregator platforms pull data from dozens of feeds and normalize it into a single interface. VirusTotal, AbuseIPDB, AlienVault OTX, and ThreatFox all accept IP submissions and return crowdsourced detection data, file submissions from that IP, URLs associated with it, and community comments.
Treat aggregator results as one data point, not a verdict. An IP with zero flags in AbuseIPDB can still be actively malicious if it was freshly deployed. New infrastructure for known threat actors frequently has clean reputation scores because the feeds have not caught up. This is the gap that burned the financial services firm in the scenario that opened this article.
Recorded Future, named a leader in the 2026 Gartner Magic Quadrant for Cyberthreat Intelligence Technologies, emphasizes this temporal dimension — the most dangerous infrastructure is often the infrastructure that reputation systems have not yet catalogued. Analysts should weight recency of deployment and hosting context alongside reputation scores rather than using reputation alone as a gate.
Abuse and Incident Databases
Beyond the aggregators, several specialized databases track IP-level abuse. Spamhaus lists IPs associated with spam and malware distribution. SURBL and URIBL track URLs and their associated infrastructure. The Shadowserver Foundation maintains feeds tracking scanning, botnets, and amplification attack sources. Team Cymru's Bogon reference lists identify unallocated or reserved address space that should not be generating traffic.
Cross-referencing against multiple abuse databases is more reliable than relying on any single one. Each database has different ingestion pipelines, coverage areas, and update frequencies. An IP that appears in Spamhaus but not AbuseIPDB is still flagged — you just found it through a different source.
Active Reconnaissance: When Passive Data Is Not Enough
Active reconnaissance involves sending traffic to the target IP to gather additional information. Use this technique with deliberate intent, and only within the boundaries of your legal authority and organizational policy. Active scanning of IPs you do not own or have explicit permission to probe is restricted in many jurisdictions.
Port Scanning and Service Enumeration
When you have authorization to probe a target — typically when the IP has touched your own infrastructure and you are investigating potential intrusion activity — a targeted port scan gives you the current service profile. Nmap with version detection (nmap -sV) will identify running services, software versions, and in many cases the operating system.
Compare the current service profile against what Shodan or Censys recorded historically. If the current scan shows new services that did not exist in the historical record, the infrastructure has changed recently. If services that were present previously are gone, the operator may have cleaned up after detecting scrutiny.
Look for unexpected services on non-standard ports. Attackers running C2 infrastructure often put legitimate-looking services on standard ports (HTTP on 80, HTTPS on 443) while running actual C2 protocols on high-numbered ports that are less likely to trigger firewall rules or analyst attention.
TLS Certificate Inspection
Connecting to HTTPS services and inspecting the TLS handshake in detail reveals information beyond what Shodan records. Use OpenSSL or a tool like testssl.sh to retrieve the full certificate chain, check for certificate transparency log entries, and inspect Subject Alternative Names.
Certificate transparency logs, accessible through crt.sh, record every certificate issued by trusted CAs. An IP running a certificate issued for a suspicious domain, or for a domain that does not appear to have any legitimate business purpose, is a strong signal. SAN fields sometimes list multiple domains that reveal the scope of infrastructure under a single operator's control.
Pivoting: Turning One IP Into an Infrastructure Map
The most powerful OSINT technique is pivoting — using one piece of information to find related infrastructure. Every IP investigation should include at least one pivot step.
Infrastructure Pivots via Shared Attributes
When you find a domain associated with a suspicious IP, query that domain's current and historical DNS records. Look for the mail exchange records, name server assignments, and TXT records (which often include SPF or DKIM configuration that reveals the email infrastructure). Name server assignments are particularly useful: if a suspicious domain uses a name server that you can search across passive DNS, you may find dozens of other domains on the same name server — all likely belonging to the same operator.
SSL certificate pivots work the same way. Take the certificate fingerprint from a suspicious IP and search it across Censys or Shodan to find other IPs presenting the same certificate. If those other IPs also appear in your environment logs, you have found related infrastructure that your original alert did not surface.
WHOIS Registration Pivots
When WHOIS data includes a registrant email address, search that email across DomainTools, SecurityTrails, or similar WHOIS history databases to find every domain ever registered with that email. This technique has limitations because privacy protection hides registrant data for many domains, but when contact information is available, it often links to a larger domain portfolio.
Phone numbers and physical addresses in WHOIS records can be searched similarly, though adversaries frequently use fake or recycled contact information. Even fake contact data can be useful: if a threat actor used the same fake contact information for multiple registrations across time, those registrations cluster together as a group.
Geolocation Verification and Infrastructure Classification
IP geolocation databases frequently report inaccurate locations, particularly for cloud-hosted IPs, VPN exit nodes, and anycast addresses. When geolocation is operationally significant — for example, when you are trying to determine whether traffic from a supposedly domestic IP is actually originating abroad — verify geolocation through multiple methods rather than accepting a single database result.
Compare geolocation results from MaxMind, IPinfo, ip-api, and DB-IP. When these sources disagree significantly, treat the geolocation data as unreliable for that IP. Routing path analysis through traceroute can give you a rough sense of where traffic is actually traversing the network, though this is also manipulable with sufficient resources.
Classify the IP's infrastructure type. Cloud provider IPs (AWS, Azure, GCP, Oracle, and their equivalents) have published IP range lists. Hosting provider IPs from companies like Hetzner, OVH, or DigitalOcean occupy known ASNs. Residential ISP IPs typically come from ASNs registered to consumer broadband providers. The classification matters because it changes the probability interpretation: a threat actor running C2 from a residential IP is either using a compromised host or a residential proxy service, both of which require different response strategies than C2 running on a dedicated hosting server.
Correlating OSINT Findings with Internal Log Data
OSINT findings only become operationally useful when correlated against your own environment's data. Once you have built an IP's external profile, take that profile back into your SIEM and run it against your logs.
Search not just for the specific IP but for the entire netblock. If an attacker is rotating through addresses in a /24, alerting on only the specific IP that triggered your initial alert misses all the related activity. Query for all IPs in the same ASN that have appeared in your traffic over the past 30 or 90 days, and look for behavioral patterns — similar timing, similar destination ports, similar user agent strings or protocol fingerprints.
Search for domains associated with the suspicious IP across your DNS query logs. If passive DNS showed that ten domains have resolved to the suspicious IP, query whether any of those domains were ever queried from within your network. A single DNS query to a related domain that you had not flagged can confirm that the compromise scope is wider than the initial alert suggested.
The Canvas breach that disrupted schools and colleges nationwide is a reminder that supply chain and third-party infrastructure compromises spread quietly. OSINT-driven investigation of every third-party IP that touches your environment is not practical in real-time, but when an alert fires, the OSINT process should extend to any third-party infrastructure that shares characteristics with the suspicious IP.
Documenting and Sharing What You Find
OSINT investigation produces value beyond the immediate incident. Document your findings in a structured format that your team can search and reference later. At minimum, record the IP, the investigation date, every source consulted, the key findings from each source, the pivots performed, and the related indicators discovered.
When your investigation surfaces indicators of a broader campaign — especially if you identify infrastructure that matches known threat actor patterns — consider sharing those indicators through appropriate channels. ISACs (Information Sharing and Analysis Centers) for your sector accept and distribute threat intelligence. AlienVault OTX and MISP instances accept community contributions. Responsible sharing accelerates the community's ability to detect the same infrastructure before it causes additional harm.
When the Exploitation of PAN-OS Captive Portal zero-day was published, rapid sharing of the IP addresses and infrastructure associated with active exploitation allowed organizations to block attack infrastructure before their vendors had time to patch — illustrating how community intelligence distribution compresses the defender's reaction window.
Tool Stack for Practical IP Investigation
The following tools cover the workflow described in this article. Most offer free tiers adequate for individual investigations, with paid tiers providing bulk access and API integration for automated workflows.
- WHOIS and RIR Queries: ARIN WHOIS, RIPE NCC WHOIS, RDAP (the modern successor to WHOIS)
- ASN and Routing: BGPView, Hurricane Electric BGP Toolkit, RIPE RIS
- Passive DNS: Farsight DNSDB, SecurityTrails, VirusTotal Relations tab, PassiveTotal
- Internet Scan Data: Shodan, Censys, FOFA, ZoomEye
- Certificate Transparency: crt.sh, Censys certificates search
- Threat Intelligence Aggregation: VirusTotal, AbuseIPDB, AlienVault OTX, ThreatFox, Recorded Future (commercial)
- Abuse Databases: Spamhaus, Shadowserver Foundation, Team Cymru IP to ASN mapping
- WHOIS History and Domain Pivoting: DomainTools, SecurityTrails
- Geolocation Cross-Verification: MaxMind, IPinfo, ip-api
Where This Process Breaks Down and What to Do About It
OSINT-based IP investigation has real limitations. Privacy-preserving technologies, IPv6 deployment, carrier-grade NAT, and the rapid rotation of cloud-hosted IP addresses all reduce the reliability of passive intelligence.
IPv6 addresses are particularly challenging. The address space is large enough that historical databases have incomplete coverage, and many organizations have IPv6 traffic flowing through infrastructure their security tools were not configured to monitor. An attacker operating over IPv6 may leave a thinner OSINT trail than one using IPv4.
Attackers using residential proxy networks, such as those that powered the CallPhantom campaign against Android users, present addresses that belong to legitimate consumer ISPs. OSINT on those addresses returns clean results because the malicious behavior is layered on top of legitimate infrastructure. In these cases, behavioral analysis of the traffic itself — timing patterns, volume, protocol anomalies — becomes more informative than IP-level OSINT alone.
Zero-day exploitation, like the Cisco SD-WAN flaw exploited before patches were available, often involves attacker infrastructure that has no prior abuse history by definition. Fresh infrastructure used in zero-day campaigns will not appear in abuse databases. OSINT still provides value through infrastructure classification and ASN context, but it cannot replace behavioral detection and anomaly analysis for genuinely novel attack infrastructure.
Treat OSINT findings as probabilistic, not deterministic. A clean IP reputation increases your uncertainty but does not confirm safety. A flagged IP raises your suspicion but does not confirm malice. The investigation process is about building enough context to make a well-supported decision, and being explicit about what your evidence does and does not establish.
