When an IP Address Becomes Your Starting Point
An alert fires. A suspicious connection shows up in your SIEM. A user reports something odd. In each of these scenarios, an IP address is often the first concrete artifact you have to work with. What happens next determines whether you build a clear picture of the threat or chase dead ends for hours.
OSINT-based IP investigation is one of the most practical and underutilized skills in defensive security. It does not require expensive tooling. It does require a disciplined workflow, an understanding of what public data sources actually reveal, and the judgment to know when a data point is meaningful versus misleading.
This article walks through that workflow in detail, grounded in the kinds of incidents that security teams are actually dealing with right now. The resurgence of modified CIA Hive implant variants circulating in criminal markets, the Kimsuky group's continued use of PebbleDash-based tooling against targeted organizations, and the 0ktapus campaign that compromised 130 firms all share a common investigative starting point: an IP address tied to command-and-control infrastructure, a scanning host, or a relay node. Knowing how to extract maximum context from that address is what separates a closed ticket from a real investigation.
What Public Data Sources Actually Tell You
Before running a single query, it helps to understand what the major OSINT data sources are actually measuring and where they fall short.
Passive DNS
Passive DNS records historical resolutions between hostnames and IP addresses. When an attacker rotates infrastructure, passive DNS is often where you find the thread connecting old domains to new IPs or vice versa. Tools like SecurityTrails, RiskIQ (now part of Microsoft Defender Threat Intelligence), and DNSDB give you resolution history that can stretch back years. This is directly relevant when tracking something like the Xdr33 variant of Hive, which researchers linked to earlier infrastructure through shared domain resolution patterns.
The limitation is staleness. A passive DNS record showing that a domain resolved to an IP six months ago does not mean that IP is still malicious or even still controlled by the same actor. Always check timestamps and corroborate with other sources.
WHOIS and Registration Data
WHOIS data for IP addresses tells you which organization holds the registered assignment and who to contact for abuse reporting. For IPv4 space, regional internet registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC) maintain this data. For most investigations, this gives you the autonomous system number (ASN), the organization name, the country of registration, and abuse contact details.
Be careful interpreting organizational data. A hosting provider, cloud provider, or VPN service can own the registered block while the actual actor using that IP is a customer with no visible footprint in WHOIS. Attribution stops at the registrant level unless you go further.
Shodan, Censys, and FOFA
These internet scanning databases give you a snapshot of what services an IP was running at the time it was last scanned. This is some of the most operationally useful data available. If a suspicious IP is running an unusual combination of services, a self-signed certificate with specific fields, or a banner that matches known malware infrastructure patterns, that is immediately actionable context.
Shodan indexes banners and certificates. Censys provides structured TLS certificate data with strong search capabilities. FOFA is widely used by researchers tracking Chinese threat actor infrastructure and has indexed a significant portion of global internet-facing services. Researchers tracking the Hive implant variants and related C2 infrastructure have used Censys certificate searches to identify clusters of servers sharing the same self-signed certificate organization fields, a technique that is highly effective against actors who reuse certificate templates across deployments.
Threat Intelligence Feeds and Reputation Services
Services like VirusTotal, AbuseIPDB, AlienVault OTX, ThreatFox, and Shodan's malware tagging give you crowdsourced signals about whether an IP has been reported or flagged by other researchers. These are useful for quick triage but carry significant false positive and false negative rates. An IP with no reputation hits is not clean. An IP with old reputation hits may no longer be active infrastructure.
Use reputation data to prioritize, not to conclude. A high AbuseIPDB confidence score should accelerate your investigation, not end it.
BGP and ASN Data
BGP routing data tells you which autonomous system is currently announcing a given prefix and can reveal routing anomalies, prefix hijacks, and infrastructure clustering. Services like BGPView, Hurricane Electric's BGP Toolkit, and Team Cymru's IP-to-ASN mapping give you this data. Knowing that an IP belongs to an ASN frequently associated with bulletproof hosting, a known VPN provider, or a Tor exit operator meaningfully changes how you interpret that address in context.
Building a Repeatable Investigation Workflow
The goal of a workflow is to make sure you cover the same ground consistently under pressure, especially when an incident is active and time matters. The following steps represent a practical field sequence for IP investigation using public sources.
Step 1: Initial Context Pull
Start with a single, fast lookup that gives you organizational and geographic context. Use Team Cymru's whois service, BGPView, or ipinfo.io to pull ASN, organization, country, and abuse contact in one request. Note whether the IP falls into a hosting provider range, a residential ISP range, a cloud provider range, or a specialized range like a VPN or Tor exit. This single data point shapes everything that follows.
A residential IP in a country consistent with the expected attacker profile means something very different from a data center IP in a country where the attacker has no known presence. When the 0ktapus campaign was being investigated, researchers noted that initial phishing infrastructure was hosted on providers that offered easy anonymous registration, which was visible at the ASN level immediately.
Step 2: Service and Certificate Fingerprinting
Run the IP through Shodan and Censys. Look at what services are exposed, what banners are returned, and what TLS certificates are present. Record certificate hashes, organization fields, common names, and validity periods. These become pivots for finding related infrastructure.
Specifically, search for the certificate SHA256 fingerprint in Censys to identify other IPs presenting the same certificate. Search for the certificate organization name to find clusters of infrastructure registered under the same identity. Search for unusual port combinations that match known malware profiles. Hive variants, for instance, have been identified through specific combinations of ports and self-signed certificate fields that researchers fingerprinted from known samples.
Step 3: Passive DNS Pivoting
Query passive DNS to find domains that have resolved to this IP and other IPs that the domains resolved to historically. This builds a graph of related infrastructure. SecurityTrails allows you to query both directions. RiskIQ PassiveTotal (now Microsoft MDTI) provides enriched data including registrar, creation date, and related infrastructure.
Pay attention to registration timing. Domains registered just before a known campaign date and resolving to a suspicious IP are high-value indicators. Domains registered through the same registrar with similar naming patterns are worth clustering and investigating together.
Step 4: Malware and Sample Correlation
Search VirusTotal, MalwareBazaar, and ThreatFox for any samples that communicate with this IP or domains associated with it. If you find a sample, pull its behavior report. Look at what other IPs it contacts, what registry keys it writes, what files it drops. This can connect a single suspicious IP to a broader campaign or threat actor profile.
In the case of Kimsuky's PebbleDash tooling, samples shared specific C2 communication patterns including user-agent strings and URL structures that allowed researchers to identify additional infrastructure beyond the initially flagged IP. Malware correlation is where individual IP investigation scales into campaign mapping.
Step 5: Cross-Reference with Threat Intelligence Reports
Search the IP and associated domains against public threat intelligence reports on platforms like Unit 42's blog, Recorded Future's public research, CISA advisories, and Mandiant's public publications. Many advanced threat actor campaigns have been documented in enough detail that an IP from that infrastructure will appear in a published report or associated IoC list.
GitHub repositories maintained by threat intelligence teams, such as those from abuse.ch and individual researchers, often contain IoC lists updated in near real-time. A simple GitHub search for the IP address in quotes can surface these references quickly.
Step 6: OPSEC Signal Assessment
After gathering data, assess what the actor's operational security choices reveal. Are they using shared hosting? Dedicated VPS infrastructure? Do certificate details suggest automated provisioning or manual configuration? Are domain registration patterns consistent with a sophisticated actor or an opportunistic one?
Sophisticated threat actors like those behind the modified Hive kit circulating in criminal markets show careful infrastructure compartmentalization. Less sophisticated actors reuse certificates, register domains through the same provider with similar naming patterns, and use the same hosting providers repeatedly. These OPSEC failures are what make OSINT investigation tractable even against well-resourced threats.
IP Investigation Checklist
Use this checklist during an active investigation to ensure consistent coverage across data sources and analysis dimensions.
- ASN and organizational context: Identify the registered organization, ASN name, and whether the IP falls in a hosting, residential, cloud, or specialized range.
- Abuse contacts: Pull the RIR abuse contact for potential reporting and coordination.
- Geolocation data: Note the registered country and compare against MaxMind or similar geolocation databases, acknowledging that geolocation accuracy varies significantly for VPN and proxy exits.
- Shodan service enumeration: Document all exposed ports, banners, and service versions visible in the most recent scan.
- Censys TLS certificate analysis: Pull certificate details, hash fingerprints, and pivot to related infrastructure sharing the same certificate.
- Passive DNS history: Identify all domains that have resolved to this IP and build a historical resolution timeline.
- Reverse DNS: Check PTR records for any hostname context that reveals provider, purpose, or naming convention.
- Reputation database queries: Check AbuseIPDB, VirusTotal, AlienVault OTX, and ThreatFox for existing flags and reports.
- Malware sample correlation: Search MalwareBazaar and VirusTotal for samples communicating with this IP or associated domains.
- BGP routing state: Verify the IP is routed, identify the announcing ASN, and check for any recent routing changes via BGP route views.
- Threat report correlation: Search published threat intelligence reports, CISA advisories, and GitHub IoC repositories for references to this IP or associated infrastructure.
- Related infrastructure graph: Document the network of IPs and domains connected through certificate, passive DNS, and registration pivots.
- Temporal analysis: Map the timeline of infrastructure registration, first seen dates in scanning databases, and campaign activity windows.
- OPSEC assessment: Evaluate what the actor's infrastructure choices reveal about their sophistication and resource level.
Practical Scenario: Tracing C2 Infrastructure from a Single Alert
Consider a scenario that mirrors real incidents in 2025 and 2026. Your EDR fires on an endpoint that has made an outbound connection to an IP on port 443. The connection used TLS but your SSL inspection did not capture certificate details because the traffic predated policy enforcement. You have the IP, a timestamp, and the process name that initiated the connection.
Starting with the IP in Shodan, you find that the host is running a self-signed certificate with an organization field of a generic tech company name, a common name that looks like a legitimate domain but uses a homoglyph character, and port 443 alongside ports 8443 and 4444. The port 4444 is significant given its historical association with Metasploit handlers and certain implant frameworks.
In Censys, you search the certificate SHA256 hash and find 14 other IPs presenting the same certificate. Eleven of those IPs are in the same /24 subnet and belong to the same ASN, a bulletproof hosting provider with a history of abuse complaints. The remaining three are in different countries and different ASNs, suggesting deliberate geographic distribution of infrastructure.
Passive DNS for the domain in the certificate common name shows it was registered 11 days before the alert and has resolved to six different IPs over that period. Four of those IPs also appear in the Censys cluster you identified. This is a clear infrastructure fingerprint.
Searching VirusTotal for the domain returns three malware samples submitted within the past week that communicate with it. Two of those samples were classified as a Hive variant by multiple AV engines, consistent with reporting about modified Hive tooling entering criminal markets. The third sample is flagged as a dropper associated with a known initial access broker.
At this point, you have moved from a single alert to a cluster of 17 IPs, a domain used for C2, two malware families, and a possible connection to a known threat campaign. Your response team can now block the full infrastructure cluster, hunt for other endpoints that may have connected to any of the 17 IPs, and correlate the malware samples against your EDR telemetry to identify any additional compromised hosts.
Tools That Actually Get Used Under Pressure
When an incident is active, tool overhead matters. The following tools are reliable, well-documented, and accessible without requiring enterprise contracts for basic investigation work.
Command-line WHOIS and BGP Tools
The standard whois command against a regional registry server returns organizational data quickly. Team Cymru offers a whois service at whois.cymru.com that accepts bulk IP input and returns ASN, ASN name, and country data in seconds. For routing state, RIPE's RIS Whois service and Hurricane Electric's BGP Toolkit provide detailed prefix and routing information.
Shodan CLI
Shodan's command-line interface supports scripted queries and integration into investigation workflows. You can pull host data, search by certificate fingerprint, and export results in formats compatible with analysis pipelines. The CLI makes it practical to query Shodan during incident response without context-switching to a browser.
SecurityTrails API
SecurityTrails provides programmatic access to passive DNS, WHOIS history, and associated infrastructure data. The free tier is limited but sufficient for individual IP investigations. For teams running frequent investigations, the API enables automated enrichment of IP indicators as they appear in alerts.
Maltego
Maltego provides a graphical interface for building relationship graphs across OSINT data sources. It is particularly useful for visualizing infrastructure clusters and communicating findings to stakeholders who are not comfortable reading raw data dumps. The community edition has rate limits but covers the core transforms needed for IP investigation work.
SpiderFoot
SpiderFoot automates OSINT collection across dozens of sources and can be self-hosted. It is useful for comprehensive coverage when time allows a more thorough sweep, though the volume of data it returns requires careful triage to avoid being buried in low-value results.
Implementation Pitfalls to Avoid
OSINT investigation for IP analysis looks straightforward until you encounter the patterns that consistently mislead investigators or slow down response. These are the most common operational mistakes teams make.
Conflating IP Registration with IP Use
An IP registered to a German hosting company does not mean the actor is German or that the server is physically in Germany. Cloud and hosting providers operate globally, and actors deliberately select infrastructure in jurisdictions that complicate law enforcement coordination. The registration country is a data point, not an attribution conclusion. Treat geolocation data as directional context rather than precise location.
Treating Reputation Score as Ground Truth
AbuseIPDB and similar platforms reflect what has been reported, not what is currently active. Actors rotate IPs frequently, and fresh infrastructure that has never been used for a prior campaign will have a zero abuse score right up until the moment it is used against your organization. High-volume scanning campaigns regularly use IPs with no prior reputation. The absence of a reputation flag is not clearance.
Ignoring IPv6 Infrastructure
IPv6 addresses are increasingly appearing in C2 infrastructure, and many investigation tools have weaker coverage for IPv6 space than for IPv4. If your investigation stops at the IPv4 connection and does not check whether the domain also has AAAA records pointing to IPv6 infrastructure, you may miss part of the actor's footprint. Passive DNS queries should explicitly include IPv6 resolution history.
Single-Source Investigation
Relying on one platform for investigation creates blind spots. Shodan and Censys have different scan schedules and coverage gaps. An IP that returns no results in Shodan may have detailed data in Censys or FOFA. Running the same query across two or three scanning databases before concluding an IP has no internet-facing services takes minutes and prevents false negatives that close investigations prematurely.
Static Snapshot Thinking
Internet infrastructure changes continuously. An IP that was running a known malware C2 port last week may now be running legitimate services because the hosting provider recycled the address to a new customer. Conversely, an IP that appeared clean in a database pull from three weeks ago may have been repurposed for malicious activity since then. Always check scan timestamps and prioritize recent data. When the data is stale, flag it as low confidence rather than treating it as current.
Skipping the Infrastructure Graph Step
Many investigators pull data on a single IP and stop there. The pivot to related infrastructure through certificate fingerprints, passive DNS, and registration patterns is where investigations become genuinely useful. A single blocked IP is trivially replaced by an actor. A fully mapped infrastructure cluster gives you durable blocking, hunting opportunities, and the basis for a meaningful threat intelligence report that helps your organization recognize the same actor if they return with new infrastructure.
Failing to Document the Chain of Evidence
OSINT investigation findings that are not documented thoroughly are difficult to act on, impossible to share with legal or law enforcement, and useless for future reference when the same actor resurfaces. Capture the source, the exact query, the timestamp, and the raw result for every data point you collect. Screenshot or export data from external sources because web pages change and investigation history in third-party platforms can be limited by retention policies.
Connecting Investigation to Response
The output of an IP investigation should directly feed operational decisions. A completed investigation should produce a structured set of artifacts: the IP and any confirmed related IPs, associated domains, certificate fingerprints, malware family associations if found, ASN and hosting provider details, and a confidence assessment for each finding.
Those artifacts feed immediate blocking decisions, EDR hunting queries to identify other affected endpoints, threat intelligence platform enrichment for ongoing monitoring, and abuse reports to hosting providers and RIRs when actionable. When the investigation surfaces a connection to a known campaign, the findings should be shared through appropriate channels such as ISACs, trusted sharing communities, and public disclosure when the timing is appropriate.
The Taiwan rail system hack that drew attention to cybersecurity gaps in critical infrastructure is a reminder that operational technology environments often have the same exposure to IP-based threats as IT environments but with far less mature investigation capability. The same OSINT workflow applies regardless of the environment. The IP infrastructure attackers use to target OT networks comes from the same hosting providers, uses the same certificate patterns, and leaves the same passive DNS footprints as infrastructure targeting enterprise IT. The investigation method is transferable.
IP investigation is a perishable skill if not practiced regularly. Teams that run tabletop exercises incorporating OSINT investigation steps, maintain familiarity with current data sources, and build scripted workflows for common queries will execute faster and more accurately when it matters. The difference between a 20-minute investigation and a two-hour one is usually preparation, not talent.
