The Alert Fires at 2:47 AM
A SOC analyst at a mid-sized financial firm sees an authentication spike from a single external IP. The IP is not on any blocklist. The geolocation data says it is in Frankfurt. The user account it is hammering belongs to a contractor who has not logged in for three weeks. Within ninety seconds, the analyst needs to decide: block it, monitor it, or escalate. That decision depends entirely on how quickly they can build a meaningful picture of that IP address using open-source intelligence.
This is the scenario where OSINT skills separate analysts who respond with confidence from those who respond with guesswork. What follows is a structured, practical walkthrough of how to investigate a suspicious IP from first observation to actionable conclusion, covering the tools, the sequencing, and the reasoning that holds up in real incident timelines.
Start With Passive Registration Data, Not Active Scanning
The instinct for many analysts is to immediately run an active scan against a suspicious IP. Resist that instinct. Active scanning alerts the operator of that IP to your interest and can complicate legal standing if the investigation escalates. Begin with entirely passive sources.
WHOIS data is the starting point. Query the IP against ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC depending on the regional registration block. What you are looking for is not just the registered owner but the registration date, the abuse contact, the network block size, and whether the registered organization matches the expected use of that IP. A large /16 block registered to a generic-sounding LLC with a registration date in the last six months should raise flags immediately.
Autonomous System Number (ASN) lookup follows naturally from WHOIS. Tools like Team Cymru's IP to ASN mapping, BGPView, or Hurricane Electric's BGP Toolkit will tell you which ASN the IP routes through and which organization controls that ASN. A suspicious IP routing through an ASN associated with bulletproof hosting providers, residential proxy networks, or recently hijacked address space significantly changes your risk assessment before you have looked at a single packet.
Check the abuse contact listed in the WHOIS record. Cross-reference that email domain against known disposable or fraudulent domain registrars. Legitimate hosting providers have stable, verifiable abuse contacts. Bulletproof providers often list addresses that bounce or route to generic inboxes.
Cross-Reference Against Threat Intelligence Platforms
Once you have the basic registration picture, move to reputation and history aggregation. Several platforms aggregate observed malicious behavior, scan history, and community-reported abuse without requiring you to interact with the target IP directly.
Shodan indexes what services the IP has been observed running across historical and recent scans. If the IP has been running an OpenSSH server, an exposed Redis instance, or a Cobalt Strike default TLS certificate, Shodan will likely have a record of it. Pay close attention to the port history, the banner data, and any associated hostnames. An IP that was running a legitimate nginx server six months ago but is now serving on unusual high ports is worth deeper scrutiny.
Censys provides similar indexing with stronger certificate transparency data. If the IP has hosted domains, those domains will often surface through certificate records even if the DNS records have been cleaned up. This is particularly useful when tracking infrastructure that rotates frequently, a tactic commonly associated with phishing operations and commodity malware campaigns.
VirusTotal holds community-submitted scan results, passive DNS records, and file relationships tied to IP addresses. Search the IP directly and review the communicating files, downloaded files, and referring files tabs. An IP that appears in submitted malware samples as a command-and-control callback address is a materially different risk than one with zero file associations.
AbuseIPDB aggregates reports from administrators and security teams who have manually submitted abuse observations. The confidence score and report count give you a quick signal, but read the individual comments. A pattern of SSH brute force reports is different from a pattern of credential stuffing or phishing hosting reports, and that distinction matters for your response decision.
AlienVault OTX and similar open threat exchange platforms allow you to search an IP against community-shared threat indicators. If the IP appears in a published pulse, note the associated malware families, campaign names, or threat actor attributions. In the context of current campaigns, this is increasingly relevant: the FortiBleed campaign that exposed credentials for more than 73,000 FortiGate systems demonstrates that once credentials are exposed, attacker infrastructure quickly picks up reconnaissance and exploitation activity. IPs associated with that campaign appeared in OTX pulses within hours of public disclosure.
Passive DNS and Hostname History
An IP address rarely operates in isolation. Passive DNS data records which domain names have resolved to a given IP over time, creating a historical map of infrastructure relationships that can be extraordinarily useful in connecting seemingly unrelated incidents.
Use platforms like SecurityTrails, RiskIQ PassiveTotal (now Microsoft Defender Threat Intelligence), or Farsight DNSDB to pull the full resolution history of the IP. Look for patterns in the domains: do they share a registrar, a naming convention, a certificate authority, or a registration date cluster? Attackers who operate at scale tend to register infrastructure in batches, and passive DNS often reveals those batches even after individual domains have been taken down or rotated.
If the IP has hosted phishing domains, those domains frequently follow recognizable patterns. A cluster of domains mimicking financial institutions that all pointed to the same IP over a two-week window last month is strong evidence of a coordinated campaign rather than an opportunistic scanner. This is particularly relevant given current purchase scam campaigns targeting major international events, where attackers build convincing storefronts on attacker-controlled infrastructure that cycles through IP addresses to evade blocklists.
Pivot from the domains to their registration details. Use WHOIS history tools to see whether the registrant email address or nameserver choice connects other domains. A single registrant email that has touched dozens of short-lived domains across multiple IPs is a threat actor fingerprint that extends your investigation far beyond the original suspicious IP.
Investigating the Certificate Layer
TLS certificates are persistently underused in IP OSINT. Certificate transparency logs record every publicly trusted certificate issued, and those logs are searchable by IP address, domain name, organization name, and common name patterns.
crt.sh is the most accessible entry point. Search by IP or domain and review the certificates issued. Pay attention to wildcard certificates, which indicate the actor planned for multiple subdomains. Look at the organizational fields: some actors use real organization names in certificate CSRs, creating a direct attribution lead. Others use obviously fake names, which is itself informative about their operational security posture.
Certificate reuse is a reliable pivot point. If the same certificate was served on multiple IPs across different ASNs, those IPs likely share operational ownership. This technique has proven effective in attributing infrastructure to specific threat actors even when they rotate IP addresses aggressively, because certificate management is often less disciplined than IP rotation.
Self-signed certificates with unusual validity periods, non-standard subjects, or subject alternative names that do not match the observed hostname are indicators of attacker-operated infrastructure. Cobalt Strike, Metasploit listeners, and many commodity RATs generate certificates with distinctive default patterns that Shodan and Censys catalog, and matching those patterns to the IP under investigation gives you a strong signal about the tooling in use.
Correlating With Leaked and Exposed Data Sources
Several OSINT sources index data that has entered public visibility through breaches, misconfigurations, or deliberate leaks. These sources require careful handling both legally and operationally, but they can provide context that no registration database or passive DNS record will show.
Pastebin, GitHub, and similar code and content sharing platforms frequently host accidentally or deliberately exposed configuration files, access logs, and credential dumps that reference IP addresses. Searching GitHub for an IP address in the format it appears in configuration files will occasionally surface exposed infrastructure data that directly ties the IP to a campaign or actor. The VBScript campaign recently distributed through WhatsApp deploying RMM software relied on infrastructure that had fingerprints across multiple public repositories before the campaign was fully attributed.
Shodan's historical data and internet scan datasets from projects like CAIDA or Rapid7's Open Data provide context about what an IP has been observed doing over time. An IP that was part of a known scanner range, then went quiet, then reappeared hosting authentication-facing services is exhibiting a lifecycle pattern consistent with purchased or rented attacker infrastructure.
Geolocation as Context, Not Conclusion
IP geolocation data appears at every stage of an IP investigation and deserves a precise understanding of its limitations. Geolocation databases map IP addresses to physical locations based on registration data, network topology inferences, and user-submitted corrections. They are accurate enough to identify the country of registration most of the time. They are frequently wrong about city-level attribution and almost never reliable for attributing an attacker's physical location.
An IP registered in Frankfurt and geolocating to Frankfurt may be a German server operated by an attacker in Brazil, a VPN exit node, a Tor exit node, a residential proxy endpoint, or a compromised legitimate server. Each of these scenarios demands a different response.
Use geolocation as one signal among many. If the geolocation is inconsistent with registration data, if the IP belongs to a known VPN or proxy provider, or if the ASN is a known hosting-only network with no residential subscribers, treat the location claim with skepticism. Confirm what you can confirm through certificate data, passive DNS, and BGP routing analysis before drawing conclusions about origin.
Building the Timeline
Effective IP investigation produces a timeline, not just a checklist of findings. Sequence what you have found across time.
When was the IP first observed in public scan data? When were the domains associated with it registered? When did abuse reports first appear? When did the certificate associated with it get issued? When did it appear in the passive DNS record against a known malicious domain? When did it first appear in your own logs?
The gap between when infrastructure goes live and when it appears in your environment is operationally significant. If attacker infrastructure was stood up two weeks before it appeared in your logs, that suggests a planned, targeted operation. If it appeared in your logs the same day it first showed up in public scan data, you are likely looking at opportunistic scanning or a commodity malware campaign hitting broad ranges.
Timeline construction also supports your response prioritization. An IP with a long history of abuse reports, multiple associated malicious domains, and known malware family associations warrants immediate blocking and escalation. An IP with no prior history, clean registration, and only a single anomalous behavior in your logs warrants monitoring and correlation before you act.
Pivoting to Infrastructure Clusters
A single IP is rarely the end of the story. OSINT investigation produces pivot points that extend outward into infrastructure clusters, and mapping those clusters is where the real intelligence value accumulates.
When you have identified associated domains, use their registration details to find sibling domains. Use certificate data to find co-hosted IPs. Use passive DNS to identify other IPs the domains have pointed to. Use ASN data to identify other IPs in the same hosting block. Use similar naming conventions in Shodan or Censys to find infrastructure that was set up using the same template.
This process mirrors the kind of infrastructure mapping that threat intelligence teams apply to named threat actors, but it is equally applicable to lower-tier attackers. The VBScript campaigns using WhatsApp as a delivery mechanism and deploying RMM tools for persistence used infrastructure that was traceable across multiple IPs through certificate commonalities and passive DNS clustering, even though individual IPs rotated frequently.
Emerging threats in the AI supply chain space, including cases like the Vertex AI model upload compromise that enabled cross-tenant remote code execution, demonstrate that attacker infrastructure can masquerade as legitimate cloud service endpoints. Passive DNS and certificate investigation become critical in those cases because the IP may itself belong to a legitimate provider while the specific hostname or path represents attacker-controlled content. Correlation across the full infrastructure picture distinguishes those cases from straightforward malicious hosting.
Documenting for Escalation and Response
OSINT investigation findings need to be documented in a format that supports both immediate response decisions and longer-term threat intelligence use.
For each IP you investigate, capture the following in a structured format: ASN and registered owner, abuse contact, registration date, observed services and banners from Shodan and Censys, associated domains from passive DNS, certificate details, abuse report history and confidence score, threat intelligence platform hits with associated malware families or campaign names, timeline of observed activity, and your assessed risk level with supporting rationale.
This documentation serves multiple purposes. It supports the decision to block or escalate with clear evidence rather than instinct. It provides context for incident response teams who need to understand attacker infrastructure. It feeds into threat intelligence workflows where the same IP or related infrastructure may appear in future incidents. It also supports potential law enforcement referral if the investigation reveals criminal activity.
Tooling That Fits Into Operational Workflows
The tools mentioned throughout this article are most effective when they are integrated into investigation workflows rather than used ad hoc. Several approaches make this practical for SOC teams and IT administrators who need to move quickly.
SpiderFoot automates passive OSINT collection across dozens of sources and presents the results in a relationship graph. Configure it with API keys for Shodan, Censys, SecurityTrails, and VirusTotal and it will pull and correlate data across all of them in a single run, significantly reducing the time from initial indicator to enriched picture.
Maltego provides a graphical relationship mapping environment that excels at visualizing the infrastructure cluster pivots described above. Its transform library includes integrations with most major OSINT data sources.
TheHive and Cortex, used together, allow SOC teams to create structured investigations for suspicious IPs and automate enrichment through Cortex analyzers that call OSINT APIs automatically when a new observable is added to a case.
For teams that need command-line tooling in investigation runbooks, ipinfo.io's CLI, shodan-cli, and whois combined with simple shell scripts can produce enriched IP reports in under a minute and feed that data into ticketing systems or SIEM platforms.
What OSINT Investigation Actually Tells You
After running a full OSINT investigation on a suspicious IP, you will know the following: who registered the infrastructure and whether that registration is consistent with legitimate use, what services it has been observed running and whether those services match known attacker tooling, what domains it has hosted and whether those domains are associated with known malicious campaigns, what malware families or threat actors have used that IP, and approximately when the attacker built and deployed that infrastructure relative to when it appeared in your environment.
What you will not know with certainty is the physical location of the attacker, their identity, or their complete infrastructure picture. OSINT gives you the context to make confident response decisions; it does not give you attribution. Keep that boundary clear when communicating findings to leadership or legal teams.
The practical value is substantial. An analyst who can build this picture in ten to fifteen minutes using structured workflows makes fundamentally better blocking, monitoring, and escalation decisions than one who acts on geolocation alone or waits for blocklist confirmation. In environments where attacks like the FortiBleed campaign credential exposure or AI supply chain compromises are moving quickly, that decision quality compounds into meaningful security outcomes.
