The Incident That Started With a Single IP Address
A mid-sized financial services firm noticed an unusual authentication spike originating from a single IP address against their customer portal. The alert fired at 2:47 AM. By morning, the on-call analyst had logged the IP, confirmed it was not in any internal blocklist, and closed the ticket as a probable false positive. Three days later, credential stuffing logs revealed 4,200 successful account validations tied to that same IP range. The IP had belonged to a residential proxy service, and the analyst had checked exactly one source before moving on.
This scenario plays out across organizations daily. The tools to conduct a proper IP investigation exist, most of them are free, and the workflow to use them under operational pressure is not complicated. What tends to break down is the absence of a repeatable process. This article walks through OSINT techniques for IP investigation that cybersecurity professionals and IT administrators can apply when an alert fires and the clock is already running.
What a Useful IP Investigation Actually Covers
A thorough IP investigation goes beyond asking whether an address appears on a blocklist. It answers a layered set of questions: Who owns this IP? What infrastructure does it belong to? Has it been observed in threat actor campaigns? What services is it running? Does its behavior pattern match a known category of abuse? Each question feeds the next, and skipping layers creates gaps that attackers have learned to exploit.
The April 2026 CVE landscape and the ongoing abuse patterns documented in campaigns like the 0ktapus group's infrastructure confirm that threat actors actively cycle through clean IPs, residential proxies, and cloud-hosted ranges specifically because defenders rely on reputation alone. A single-source lookup is insufficient. The goal is triangulation across multiple data sources, each with different visibility windows and update frequencies.
Step One: Passive Reconnaissance Without Touching the Target
The first principle of IP OSINT is that active scanning of a suspicious IP before you understand what it is can alert the operator, contaminate forensic evidence, or generate legal exposure if the IP belongs to legitimate infrastructure being abused. Start with passive sources only.
WHOIS and Regional Internet Registry Lookups
WHOIS remains the foundation. Query the Regional Internet Registry (RIR) directly rather than through aggregator sites, because aggregators sometimes cache stale data. For IP addresses in North America, ARIN's web interface at search.arin.net provides the authoritative registration record. RIPE NCC covers Europe, APNIC covers Asia-Pacific, LACNIC covers Latin America, and AFRINIC covers Africa.
A WHOIS record tells you the registered organization, the abuse contact email, the network range the IP falls within, and the registration date. An IP registered to a major cloud provider like AWS, DigitalOcean, or Linode in a block that was created in the last six months, paired with an abuse contact that bounces, is a signal worth escalating. Nation-state tactics documented in the ROADtools research show consistent use of freshly provisioned cloud infrastructure to avoid reputation-based filtering, which makes registration date and provider type meaningful data points rather than background noise.
BGP and ASN Data
The Autonomous System Number (ASN) associated with an IP tells you which network operator is responsible for routing that traffic. BGPView, Hurricane Electric's BGP Toolkit at bgp.he.net, and Team Cymru's IP-to-ASN mapping service all provide this without active probing. What you are looking for is whether the ASN belongs to a legitimate ISP, a major cloud provider, a bulletproof hosting operation, or a residential proxy network.
BGP history is also useful. An IP that has been reassigned between ASNs multiple times in a short window is a signal. Bulletproof hosting operators frequently move IP blocks between shell ASNs to avoid takedown efforts. Tools like RIPEstat's BGP Play feature let you visualize routing history for a given prefix over time.
Reverse DNS and PTR Records
A PTR record sometimes reveals the infrastructure class immediately. A hostname like mail.threatactor-domain.com is obvious, but more commonly you will see patterns like cloud provider naming conventions, which confirm the IP is a rented VPS, or residential ISP naming conventions like cpe-24-x-x-x.ispname.res.rr.com, which identifies it as a residential connection. Residential IP attribution matters because it often indicates the endpoint is a compromised device enrolled in a residential proxy botnet rather than dedicated attacker infrastructure.
Reputation and Threat Intelligence Lookups
After establishing the ownership layer, reputation data adds behavioral context. The key is querying multiple sources because each has different data collection methods, different update cadences, and different coverage gaps.
AbuseIPDB
AbuseIPDB aggregates reports from security professionals who have observed malicious activity from specific IPs. The confidence score and the category of reported abuse, such as port scanning, brute force, or web application attacks, give you behavioral history. An IP with a confidence score of 90 and 300 reports in the last 30 days is very different from an IP with two reports from two years ago. The Dashlane brute force attack campaign and similar credential stuffing operations leave heavy AbuseIPDB footprints specifically because they generate authentication failures at scale.
Shodan and Censys
Shodan and Censys are passive scanners that index internet-facing services by probing at regular intervals. Querying an IP on Shodan shows you what ports and services were visible the last time Shodan scanned it, what banners those services returned, and what SSL certificates they presented. This is operational intelligence. An IP running an OpenVPN service on a non-standard port, alongside an RDP listener and an SSH service with a generic banner, matches a pattern common to rented attack infrastructure.
SSL certificate data is particularly valuable. Certificates are tied to domain names, and if a suspicious IP has hosted a certificate for a known malicious domain in the past, that association persists in historical data even after the domain is abandoned. Censys's certificate transparency logs extend this visibility. The BTMOB RAT campaign and similar mobile malware operations have shown consistent patterns of reusing certificate infrastructure across IP ranges, meaning that a single pivot from IP to certificate to domain can map out a larger portion of the threat actor's operational infrastructure.
VirusTotal
VirusTotal's IP address lookup aggregates detection data from dozens of security vendors, shows URL and domain associations, provides communication samples from files that called back to the IP, and displays passive DNS data. The passive DNS section is critical for IP investigation because it shows every domain that has resolved to the IP over the history of VirusTotal's dataset. A single IP hosting fifty domains over two years, many with randomized strings in the hostname or .top/.xyz TLDs, is a reliable indicator of fast-flux or domain generation algorithm infrastructure.
Threat Intelligence Platforms
AlienVault OTX (Open Threat Exchange) provides community-contributed indicators organized into Pulses. Searching an IP often surfaces its appearance in named campaigns, alongside related indicators like associated domains, file hashes, and CVEs. Given the NIST NVD's recent enrichment policy change to prioritize vulnerabilities with attacker behavior signals, cross-referencing an IP against known exploitation campaigns has become more actionable because the CVE records themselves now carry behavioral context.
IBM X-Force Exchange, Recorded Future's free community tier, and Pulsedive all offer similar pivot capability. The workflow is to start with the IP, identify any campaign associations, then use those campaign names to pull the full indicator set and determine whether other IPs in your environment have touched the same infrastructure.
Passive DNS: The Investigation Multiplier
Passive DNS data deserves its own treatment because it is the most powerful pivot technique available for IP investigation. Passive DNS databases record every DNS resolution event observed by sensors across the internet. By querying a passive DNS provider for a given IP, you retrieve every domain name that has pointed to it, along with timestamps of when those resolutions were observed.
DNSDB from Farsight Security, SecurityTrails, and RiskIQ PassiveTotal all provide this capability. The free tier of SecurityTrails provides enough historical data for most investigations. The practical application is this: an IP that looks clean today may have hosted a C2 domain three months ago. If your endpoint logs show DNS queries for that old domain from inside your network, you now have a connection between a suspicious IP in your current alert and historical malicious activity, even though no current reputation feed flagged the IP.
This technique is directly applicable to the kind of nation-state cloud infrastructure described in ROADtools research, where attackers provision new IPs while reusing domain registration patterns and certificate templates from previous campaigns. The IP rotates, but the passive DNS history creates a durable thread.
Certificate Transparency Logs
Certificate transparency (CT) logs are public, append-only records of every TLS certificate issued by participating certificate authorities. crt.sh provides free search across CT logs and is the most accessible entry point. Querying crt.sh for an IP address shows certificates that have listed that IP in the Subject Alternative Name field, which is less common but does occur with infrastructure certificates. More useful is searching for a domain associated with the IP, then pivoting from that domain's certificate records to find other domains on the same certificate or issued by the same account.
Wildcard certificates are a common attacker operational security technique because a single wildcard like *.attacker-infrastructure.com covers unlimited subdomains without generating additional certificate requests. When you spot a wildcard certificate on a suspicious IP, the certificate's issuance date, the CA used, and the SAN entries all become investigation leads.
Geolocation Verification and the Gap Between Records and Reality
IP geolocation databases report the registered location of an IP, which frequently differs from the physical location of the operator. MaxMind GeoIP, ip-api.com, and ipinfo.io all provide geolocation data, and all three can return different results for the same IP. Cross-referencing multiple geolocation sources against the RIR registration country and the ASN's registered country of operation gives a more complete picture.
The practical implication is that geolocation alone is insufficient for attribution or blocking decisions. An IP registered in the Netherlands, routed through an ASN headquartered in Sweden, with a PTR record resolving to a German hosting provider, and geolocation databases returning conflicting results across providers, is a data quality problem rather than a threat intelligence finding. Use geolocation as one signal among many, specifically to identify inconsistencies that warrant deeper investigation, rather than as a definitive answer.
Pivoting Through Infrastructure Connections
Once you have gathered basic data about a suspicious IP, the investigation enters a pivot phase where each finding opens new threads. Effective OSINT investigations follow these pivots systematically rather than chasing each one independently.
- IP to ASN: Determine whether the ASN hosts other suspicious IPs. If an ASN shows 40 IPs flagged across your threat intelligence sources over the last 90 days, that ASN itself may warrant increased scrutiny or filtering.
- IP to certificate: Pull the TLS certificate from Shodan or Censys, then search for other IPs hosting the same certificate or certificates with the same organizational unit and common name patterns.
- IP to domain (via passive DNS): Every domain that has resolved to the IP becomes an investigation lead. Each domain can be queried for its own passive DNS history, registration data, and threat intelligence associations.
- Domain to registrant: WHOIS data for domains sometimes reveals registrant email addresses. Even when privacy protection is in place, the registrar, registration date, and name server choices often cluster with known infrastructure patterns.
- Domain to related domains (via registrant email or name server): If you recover a registrant email from a domain associated with the suspicious IP, searching that email across WHOIS databases often surfaces every other domain registered with it. This is how security researchers mapped large portions of the 0ktapus infrastructure.
Examining Open Port and Service Data in Context
Shodan and Censys data on open ports requires interpretation. An IP running HTTP on port 80, HTTPS on port 443, and SSH on port 22 is unremarkable. An IP running RDP on port 3389, VNC on port 5900, and a Cobalt Strike default listener on port 50050 is an immediate escalation. Knowing common threat actor port and service patterns is necessary to extract signal from this data.
Default Cobalt Strike configurations historically used port 50050 for the team server interface, though sophisticated operators change defaults. Metasploit's default HTTPS listener on port 4444 is another recognizable pattern. Havoc framework C2 traffic has been observed on ports 40056 and 443 with specific TLS fingerprints detectable through JA3 hash matching. Shodan indexes JA3 hashes for TLS connections in some queries, enabling fingerprint-based detection of known C2 frameworks even when the domain has rotated.
The practical step is to record the full port and service profile of a suspicious IP and compare it against known C2 framework signatures. JARM fingerprinting, which measures TLS implementation characteristics rather than certificate content, is available through Shodan and provides fingerprinting that survives certificate rotation.
Correlating OSINT Findings Against Internal Telemetry
External OSINT findings become operationally useful when correlated against internal data. After building an initial profile of a suspicious IP, the immediate question is whether that IP or its associated infrastructure has appeared in your own telemetry.
Query your SIEM or log management platform for the suspicious IP and any associated domains identified through passive DNS pivoting. Extend the search to include the full subnet, not just the specific IP, because attackers operating from hosting ranges often step through adjacent IPs. Check firewall logs, proxy logs, DNS query logs, and EDR telemetry in sequence. The sequence matters because an IP that appears only in firewall drop logs tells a different story than one that appears in successful outbound DNS queries followed by HTTPS connections from an endpoint.
Document the full timeline. When did the first connection occur? How many endpoints touched it? What user accounts were active on those endpoints at the time? These questions transform an IP investigation from a passive intelligence exercise into an active incident scoping effort.
Tooling Summary for Operational Workflows
The following tools support the workflow described above. All have free tiers adequate for individual IP investigations.
- ARIN / RIPE / APNIC / LACNIC / AFRINIC: Authoritative WHOIS and allocation data by region.
- BGPView and bgp.he.net: ASN lookup, BGP routing data, and prefix history.
- Shodan: Internet-wide port scans, service banners, certificate data, and JA3/JARM fingerprints.
- Censys: Certificate transparency integration, host data, and historical service records.
- VirusTotal: Multi-vendor detection, passive DNS, and associated domain mapping.
- SecurityTrails: Passive DNS, domain history, and IP-to-domain pivoting.
- crt.sh: Certificate transparency log search.
- AbuseIPDB: Community-reported abuse history with category tagging.
- AlienVault OTX: Campaign-linked indicator context and community intelligence.
- RIPEstat: BGP routing history and prefix allocation visualization.
- MXToolBox: DNS record lookups, blacklist checking, and mail server investigation.
- ipinfo.io: Geolocation, ASN, and hosting type classification including residential proxy detection.
Documenting the Investigation for Handoff and Escalation
OSINT investigations conducted under operational pressure often produce findings that get lost because the analyst who ran the investigation is the only person who understands the full context. Build investigation notes in a format that supports handoff. Record each source queried, the timestamp of the query, the raw result, and your interpretation of what the result means in context. Include screenshots for sources that do not provide exportable data.
A structured investigation document should include the original alert context, the IP address and associated infrastructure identified, the timeline of findings in order of discovery, the internal telemetry correlation results, a risk assessment based on the aggregated evidence, and recommended actions with the reasoning behind each recommendation. This format allows another analyst or a senior responder to pick up the investigation at any point without needing to re-query sources or reconstruct reasoning.
Given that supply chain and cloud-based attack patterns are increasingly documented across recent threat research, investigations that identify cloud-hosted C2 infrastructure should include escalation paths to cloud provider abuse teams. ARIN, RIPE, and the major cloud providers maintain abuse reporting channels, and reports that include structured evidence, specific IP addresses, timestamps, and indicator associations, receive faster responses than generic abuse submissions.
Building Repeatable Investigation Workflows
The most effective way to reduce investigation time under pressure is to build and rehearse a standard workflow before the incident occurs. Define a tiered investigation process: a five-minute triage level that covers WHOIS, ASN lookup, and a single reputation source; a thirty-minute standard level that adds passive DNS, certificate data, and Shodan; and a full investigation level for confirmed threats that adds historical timeline analysis, internal telemetry correlation, and infrastructure mapping.
Automate what can be automated. Tools like Maltego, Spiderfoot, and the open-source Recon-ng framework allow investigators to script multi-source lookups that run in parallel rather than sequentially. API keys for the sources listed above can be integrated into SOAR platforms to trigger automated enrichment when an IP-based alert fires, so that by the time an analyst opens the case, the first layer of OSINT data is already populated.
The analyst who closed the false positive at 2:47 AM was not wrong to triage quickly. The problem was the absence of a workflow that would have surfaced the residential proxy classification from ipinfo.io in the same time it took to check one blocklist. Workflows reduce the skill variance between analysts and ensure that high-pressure decisions rest on consistent data rather than individual familiarity with the tool set.
