A Scenario That Plays Out Every Week
It's 9:40 AM on a Tuesday. A Tier 2 analyst flags an authentication anomaly: repeated login attempts against your VPN gateway from an IP address that cleared your baseline reputation checks. The IP is registered to a cloud hosting provider in Frankfurt, the geolocation resolves cleanly, and nothing in your blocklist fires. On the surface, it looks like noise. But the cadence is wrong — attempts spaced exactly 3.2 seconds apart, targeting accounts in alphabetical order. Someone is running a credential stuffing run, and the infrastructure they chose was specifically selected to look unremarkable.
This is exactly the kind of scenario where Open Source Intelligence (OSINT) techniques separate analysts who find answers from analysts who write "inconclusive" in their incident notes. IP investigation through OSINT isn't glamorous work, but when executed systematically, it transforms a single suspicious address into a full picture of who is operating it, how long they've been operating it, what else they've pointed it at, and whether other organizations are already tracking it.
This article walks through the full investigative workflow — from initial passive enumeration through active correlation and attribution — with the kind of specificity that makes it useful when you're actually staring at an IP under time pressure.
Start With What the IP Announces About Itself
The first layer of IP investigation is purely passive. You're not touching the target. You're asking the internet's public record systems what they know about the address.
WHOIS and RDAP
WHOIS lookups are the obvious starting point, but most analysts stop at the first result and miss the layers beneath it. A WHOIS query on an IPv4 address returns the Regional Internet Registry (RIR) record, which tells you the organization the block is allocated to, the date of allocation, abuse contact details, and sometimes the downstream customer if the block was sub-allocated.
When an IP falls inside a large cloud provider's range — AWS, Azure, Google Cloud, DigitalOcean, Vultr, Hetzner — the WHOIS record alone tells you very little about the actual operator. This is where analysts need to cross-reference provider-specific IP range publications. AWS publishes its IP ranges as a JSON feed at ip-ranges.amazonaws.com. Azure publishes its service tags via Microsoft's download center. Google publishes its cloud ranges through SPF records and a dedicated JSON endpoint. Matching a suspicious IP against these feeds tells you not just which provider hosts it, but which service region and sometimes which product category.
RDAP (Registration Data Access Protocol) is the modern successor to WHOIS and returns structured JSON rather than free-text output. Tools like ipinfo.io's API and ARIN's RDAP portal surface RDAP data cleanly. RDAP records sometimes carry more granular org details and structured abuse contact information that WHOIS omits.
BGP and ASN Data
Every IP on the internet is announced through the Border Gateway Protocol by an Autonomous System. The Autonomous System Number (ASN) associated with an IP tells you which organization is actually routing the traffic, which is often different from the organization that registered the block. A threat actor may register infrastructure through a reseller, but the ASN reveals the upstream carrier.
BGPView (bgpview.io), Hurricane Electric's BGP Toolkit (bgp.he.net), and RIPE NCC's tools all provide ASN lookups for free. For each ASN, you can pull the full list of IP prefixes it announces. This is operationally valuable: if you're investigating one IP and it maps to ASN 12345 alongside 400 other prefixes, that's a starting point for a wider block-level threat hunt. If the same ASN is already associated with prior abuse reports, that context elevates the severity of your current alert significantly.
The April 2026 CVE landscape has reinforced how commonly threat actors provision infrastructure through bulletproof hosting ASNs and then rotate IPs within the same prefix range. An analyst who checks only the individual IP rather than the hosting context misses the pattern entirely.
Passive Reputation Intelligence
After building the registration and routing picture, the next step is checking what the broader security community already knows about the IP. Multiple platforms aggregate abuse reports, scan activity, and threat intelligence feeds that cover most IPs with any meaningful history.
AbuseIPDB
AbuseIPDB (abuseipdb.com) is a crowdsourced abuse reporting database that lets you query an IP's reported history. High-confidence matches return detailed reports including attack categories, report dates, and sometimes attacker behavior descriptions. An IP with 47 recent reports across SSH brute force, web application scanning, and credential stuffing is a different risk level than one with zero history, even if both appear clean in standard reputation lists. AbuseIPDB's API supports bulk lookups, which makes it useful for scripted enrichment pipelines.
VirusTotal
VirusTotal's IP lookup aggregates detection verdicts from dozens of security vendors, passive DNS history, communicating files, WHOIS records, and SSL certificate details. The passive DNS history here is particularly useful. If the IP has historically resolved hostnames associated with malware campaigns or phishing infrastructure, that context surfaces in VirusTotal's results even if the current DNS state is clean.
The BTMOB Android RAT campaign, which involved stealthy C2 infrastructure that rotated through clean-looking IPs before abuse patterns became visible, illustrates why historical DNS correlation matters. By the time an IP cleared reputation checks at the time of connection, it had already hosted C2 infrastructure for a prior campaign. VirusTotal's passive DNS data would have caught that association.
Shodan and Censys
Shodan and Censys are the two dominant platforms for passive internet-wide scanning data. Both continuously scan the public IP space and index open ports, service banners, TLS certificate details, and HTTP response headers. Querying an IP in Shodan or Censys tells you what services the address was running at the time of the last scan — which could be recent or weeks old depending on the platform's scan cadence for that region.
The intelligence value here goes beyond just seeing open ports. Service banners often include software version strings, default configuration markers, or vendor-specific identifiers that allow you to fingerprint infrastructure. An RDP banner on port 3389, an unusual custom HTTP header, or a self-signed TLS certificate with a specific subject CN can all become pivot points. If the same certificate CN appears on five other IPs, you've potentially identified the full infrastructure footprint of a single actor.
Shodan's search syntax supports filtering by certificate hash, which is one of the most powerful correlation techniques in passive OSINT. Threat actors frequently reuse TLS certificates across their infrastructure, either deliberately or because they're deploying from the same template. Searching for the SHA-256 fingerprint of a certificate found on your suspicious IP will surface every other host on Shodan running the same cert.
Passive DNS as a Pivot Mechanism
Passive DNS databases record DNS resolution history at scale, logging which domain names resolved to which IP addresses over time and when those associations changed. This historical record is invaluable for IP investigation because it answers the question: what was this IP doing before it started attacking you?
The major passive DNS data providers include Farsight Security's DNSDB, RiskIQ (now part of Microsoft Defender Threat Intelligence), SecurityTrails, and PassiveTotal. Several of these offer limited free query tiers alongside commercial subscriptions. For incident response scenarios, SecurityTrails and SecurityTrails' community tier provide enough resolution history to be useful without requiring a paid contract.
A practical passive DNS workflow starts with querying the IP directly to retrieve all hostnames that have resolved to it historically. If the IP shows associations with typosquatting domains, look-alike domains, or domains using patterns common to phishing kit operators (subdomains formatted as login-[company]-secure.domain.com), that's a meaningful signal. If the IP was hosting a known malware family's command-and-control domain six months ago and now appears in your VPN logs, the operator likely acquired the address secondhand but the hosting pattern is consistent with continued abuse.
Passive DNS also enables forward pivoting. Once you've identified a domain associated with the suspicious IP, you can query that domain's full resolution history to find every other IP it's pointed to. That second set of IPs then feeds back into the registration and reputation pipeline, building a cluster of related infrastructure.
SSL Certificate Intelligence
TLS certificate data is one of the most underused OSINT sources for IP investigation. Certificate Transparency (CT) logs — the public append-only logs required by browsers since 2018 — record every TLS certificate issued by publicly trusted certificate authorities. Tools like crt.sh provide free search access to CT log data.
Querying crt.sh for a domain associated with your suspicious IP returns all TLS certificates ever issued for that domain and its subdomains. This surfaces the full subdomain structure of an adversary's infrastructure, including staging servers, panel interfaces, and internal service names that the actor may have exposed unintentionally by requesting a cert for them.
Beyond crt.sh, both Shodan and Censys index TLS certificate data from their own scans. Censys in particular has strong certificate search capabilities and allows searching by certificate fields including the subject organization name, the issuer, and the certificate serial number. Searching by subject organization name can surface infrastructure clusters registered under the same fictional company name across different IP ranges and hosting providers.
Nation-state tactics in cloud environments — as documented in research around ROADtools usage for Azure Active Directory reconnaissance — frequently involve infrastructure that presents valid-looking TLS certificates specifically to evade detection. Validating the certificate's issuance date, the registrar, and whether the issuing CA matches the expected hosting provider is a quick sanity check that catches provisioned-for-attack infrastructure even when the certificate itself is technically valid.
Correlating Threat Intelligence Feeds
Once you have a complete picture of the IP's registration, routing, reputation, DNS history, and TLS infrastructure, the next step is cross-referencing against structured threat intelligence sources that operate on a higher level of curation than crowdsourced abuse databases.
MISP and OpenCTI
If your organization runs a MISP or OpenCTI instance, checking your suspicious IP against existing threat intelligence events should happen early in the workflow. Internal threat intel platforms aggregate indicators from information sharing communities including ISACs, FIRST, and MISP Communities. An IP that appears in an existing event linked to a known threat cluster elevates your response priority immediately and provides campaign context that raw OSINT cannot.
AlienVault OTX
AlienVault Open Threat Exchange (OTX) is a free community threat intelligence platform with a large base of contributor organizations. OTX pulses are structured intelligence packages built around specific campaigns, malware families, or threat actors. Searching an IP in OTX surfaces any pulses that include it as an indicator, along with the contributor's attribution tags and related indicators. OTX's API supports programmatic lookups and can be integrated directly into SIEM enrichment pipelines for real-time correlation.
Recorded Future and Commercial Platforms
For teams with access to commercial threat intelligence platforms — Recorded Future, Mandiant Advantage, Crowdstrike Falcon Intelligence, or ThreatConnect — IP lookups in these platforms return risk scores built from dark web monitoring, technical intelligence, and analyst-curated attribution data. These platforms are particularly useful for identifying whether an IP has been cited in threat actor profiles tied to nation-state groups or financially motivated criminal organizations.
The 0ktapus threat group, which victimized over 130 organizations through phishing infrastructure and SMS-based credential harvesting, operated infrastructure that appeared in Recorded Future's risk scoring system well before many of the victim organizations identified it in their own logs. Organizations with commercial threat intelligence subscriptions who built automated enrichment workflows caught the indicators faster than those relying solely on reactive lookups.
Active Investigation Techniques
Passive investigation doesn't touch the target. Active investigation sends traffic toward the IP and observes the response. Active techniques require more caution — both to avoid alerting a sophisticated actor that they're being investigated and to ensure your organization's acceptable use policies permit active probing.
Port Scanning and Service Fingerprinting
A targeted nmap scan against a suspicious IP reveals what services it's actively running at the time of investigation rather than at Shodan's last scan. For an IP observed attacking your network, port scanning is typically acceptable from an operational standpoint. Use nmap with service version detection (-sV) and OS detection (-O) to build a current service profile. Compare the results against Shodan's cached data to understand what has changed recently. New services standing up after an initial attack often indicate the operator preparing additional capabilities.
HTTP Response Analysis
If the IP has port 80 or 443 open, making a direct HTTP request reveals the response headers, any redirect behavior, and whatever content the server returns. Response headers frequently contain stack information: web server version, backend language hints, and sometimes custom application identifiers. Comparing the HTTP response from an investigator-controlled connection against what Shodan or Censys last recorded tells you whether the operator changed their configuration between the time of attack and the time of investigation.
In phishing infrastructure analysis, the HTTP response from the suspicious IP often reveals the phishing kit in use — even after the kit has been deactivated — through error pages, leftover directory listings, or cached page titles that contain campaign-specific strings.
Building the Attribution Picture
Attribution in IP investigation doesn't mean identifying the individual sitting at a keyboard. For operational purposes, attribution means building enough context to make informed decisions about the threat: Is this a single actor or a platform being resold to multiple operators? Is the infrastructure purpose-built for your organization or part of a broader scanning campaign? Does the hosting pattern match known threat actor infrastructure profiles?
The NIST NVD's 2026 enrichment policy change — prioritizing vulnerability records that include attacker behavior signals — reflects a broader shift in the security community toward behavior-based context rather than raw indicator lists. IP investigation should follow the same principle. An IP address is a data point. The attacker behavior around it — the ports they scan, the user agents they use, the timing of their attempts, the domains they've pointed at it — is what drives operational decisions.
Document every pivot you make during the investigation and record the sources. A structured investigation note should include: the original IP, its ASN and hosting context, its abuse history, its passive DNS associations, its TLS certificate fingerprints and any certificate cluster members, its presence in threat intelligence feeds, and the behavioral context from your own logs. That documentation becomes the foundation for a threat hunting campaign if you identify a cluster of related infrastructure, and it serves as evidence if the incident escalates to law enforcement referral.
Automation and Tooling for Repeated Investigations
Manual OSINT workflows are effective for deep investigations but don't scale for high-volume environments. Teams handling dozens of suspicious IPs per day need enrichment pipelines that automate the initial passive checks and surface results in a format analysts can act on quickly.
Several open source tools support automated IP enrichment workflows:
- Maltego: A graphical link analysis platform with transforms for WHOIS, Shodan, VirusTotal, PassiveTotal, and dozens of other data sources. Maltego is particularly effective for visualizing infrastructure clusters and pivot chains.
- TheHarvester: Primarily a domain-focused OSINT tool, but useful for correlating IP ranges with associated domains and email infrastructure during broader campaign analysis.
- Spiderfoot: An automated OSINT platform that runs concurrent queries against over 200 data sources for a given IP, domain, or ASN and returns correlated results in a single interface. Spiderfoot HX is the commercial version; the community edition covers most common sources.
- MISP with enrichment modules: MISP's enrichment module system includes native integrations for Shodan, VirusTotal, CIRCL passive DNS, and many commercial threat intelligence platforms. Feeding suspicious IPs into MISP triggers automated enrichment and correlation against existing threat events.
For teams building custom pipelines, Python libraries including ipwhois, shodan (official SDK), and requests against the VirusTotal and AbuseIPDB APIs can be combined into a lightweight enrichment script that produces a structured JSON report for any given IP within 30 seconds of execution.
Operational Security During IP Investigation
Conducting IP investigations without operational security hygiene can expose your organization's interest to a sophisticated adversary. Querying Shodan or VirusTotal from your organization's IP range reveals that your team is aware of and investigating the suspicious IP. For commodity threat actors, this makes no practical difference. For sophisticated actors conducting targeted intrusions, knowing that their infrastructure has been identified can prompt them to rotate infrastructure or accelerate their timeline.
Perform sensitive lookups from isolated investigation workstations using residential or commercial VPN exit nodes not associated with your organization. Use API keys registered to non-organizational email addresses for sensitive queries. When making active connections to suspicious IPs — port scans, HTTP requests — use dedicated investigation infrastructure that doesn't expose your production network range.
The container supply chain attack patterns documented in recent research into container escape techniques highlight a related risk: investigation workflows that pull data from untrusted or attacker-controlled infrastructure can themselves become a vector if the analyst's tooling processes attacker-controlled content without appropriate sandboxing.
From Investigation to Action
A completed IP investigation produces an evidence-backed risk assessment, not just a verdict of malicious or benign. The action you take depends on what the investigation found.
An IP with a clean registration profile, no prior abuse history, passive DNS associations with legitimate services, and behavioral anomalies consistent with misconfiguration warrants a temporary block at the firewall and an abuse notification to the hosting provider's security team. That's a very different response from an IP with ASN membership in a known bulletproof hosting range, passive DNS associations with five prior phishing domains, and certificate fingerprints that cluster with known threat actor infrastructure. The second scenario warrants permanent blocking, threat intelligence sharing with your ISAC, and a broader hunt for related indicators across your environment.
IP investigation through OSINT is not a magic attribution engine. It's a structured process for building context that makes your response decisions defensible and your threat hunting campaigns more targeted. Analysts who build this workflow into their standard operating procedure for suspicious IP handling find that the same techniques that take 45 minutes the first time take 8 minutes the twentieth time — and the organizations that invest in automation get that down to under 2 minutes for the initial enrichment layer, with analysts spending their time on the analysis rather than the data collection.
The Dashlane brute force incident that locked out users in 2026 involved infrastructure that, in retrospect, showed clear indicators in passive DNS and certificate transparency logs that would have flagged the campaign's hosting pattern before it reached production scale. The infrastructure wasn't novel. It was just uninvestigated until after the damage was done.
The tools exist. The data is largely public. The workflow is learnable. The gap between organizations that catch these campaigns early and those that catch them late is almost always a question of process, not capability.
