Why IP Investigation Demands More Than a Single Lookup
When an alert fires on a suspicious IP address, the instinct for many analysts is to drop it into a single threat intelligence platform, check the reputation score, and make a block-or-allow decision in under thirty seconds. That workflow misses the majority of what an IP address can tell you. Modern threat actors, including the infrastructure behind campaigns like OkoBot's cryptocurrency-targeting malware framework and the botnet activity detailed in the TuxBot v3 analysis, deliberately blend across hosting providers, rotate addresses, and exploit legitimate cloud services to obscure origin and intent.
OSINT-driven IP investigation treats an address as a starting point rather than a final answer. Done systematically, it surfaces the ownership chain behind the address, the behavioral history of the hosting infrastructure, associated domains, certificate transparency records, passive DNS data, and geolocation discrepancies that reputation scores alone will never show. This article walks through that workflow in practical terms, with the kinds of concrete steps that analysts can execute during an active investigation.
Setting the Threat Context Before You Touch Any Tool
Before querying anything, establish what you already know about the IP from your own environment. Pull the full session context: what ports were targeted, what protocol was used, what time of day the traffic arrived, and whether the address appeared in outbound or inbound flows. Cross-reference this against recent threat reporting. The Inc Ransomware campaign exploiting SonicWall SMA zero-days, for example, involved specific IP ranges tied to known ransomware affiliate infrastructure. Having that context means you know whether you're looking at opportunistic scanning or targeted intrusion activity before you spend time on attribution.
Document your starting hypothesis. If the traffic looked like reconnaissance, write that down. If it arrived during an off-hours maintenance window and touched internal management interfaces, note the anomaly. OSINT investigation is iterative, and your initial hypothesis will either be confirmed or redirected as data accumulates. Starting without one means you'll collect data without knowing what question you're trying to answer.
Passive Infrastructure Enumeration
WHOIS and RDAP Lookups
Start with registration data. WHOIS and the newer RDAP (Registration Data Access Protocol) queries return the registered owner of the IP block, the Regional Internet Registry (RIR) that governs the block, the abuse contact, and the date ranges of registration. For IPv4 space, check ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC depending on the regional assignment. RDAP is preferable where available because responses are structured JSON, which is easier to parse programmatically during bulk investigations.
Pay attention to the organization name and the netblock size. A /32 assignment registered to a residential ISP behaves differently from a /24 registered to a bulletproof hosting provider. If you see a large allocation registered to an entity with no visible online presence, that warrants deeper scrutiny. Cross-reference the organization name against corporate registries and search engines. Threat actors running infrastructure like the Gentlemen Ransomware group's command-and-control nodes often register hosting under shell company names with minimal publicly verifiable information.
ASN Enumeration and Routing History
Resolve the IP to its Autonomous System Number using tools like BGPView, Hurricane Electric's BGP Toolkit, or Routeviews. The ASN tells you which network operator is responsible for routing the address and often reveals the broader hosting ecosystem. Bulletproof hosters have recognizable ASNs that appear repeatedly in threat intelligence reporting. If the ASN hosting your suspicious IP also hosts known malware distribution infrastructure, that's a meaningful signal even if the specific IP is clean in isolation.
BGP routing history is particularly useful for catching infrastructure that has been reassigned after abuse. Services like RIPE RIS and RouteViews maintain historical routing tables. An IP that was routed through an ASN associated with spam operations six months ago and is now presenting as a clean cloud provider address deserves additional scrutiny. Routing history provides the temporal dimension that current-state lookups miss.
Passive DNS Resolution
Passive DNS databases record historical DNS resolutions, mapping which hostnames have resolved to a given IP over time and in what sequence. Tools like SecurityTrails, Farsight DNSDB, PassiveTotal (now part of Recorded Future), and the free VirusTotal passive DNS view all surface this data. For an IP under investigation, query the passive DNS record to identify every domain that has pointed to it.
A single IP hosting fifty domains with registration patterns suggesting domain generation algorithm (DGA) output is a different situation from an IP that hosts one domain registered years ago with consistent ownership. Passive DNS also reveals infrastructure reuse: if a domain previously associated with a phishing campaign now resolves to your suspicious IP, you have a concrete connection to a prior threat regardless of whether the current reputation score has caught up.
Active Reconnaissance Within Legal and Ethical Bounds
Banner Grabbing and Port Scanning
Shodan, Censys, and FOFA index internet-facing services continuously, making their databases an ethical substitute for active port scanning during initial investigation. Query these platforms with the IP address to retrieve which ports were open at last scan, what service banners were returned, and what TLS certificate is presented. This data can confirm or contradict what your network logs show.
Pay close attention to certificate data returned by Shodan and Censys. A server presenting a self-signed certificate for a domain unrelated to the apparent owner of the IP suggests the service is concealing its actual function. The Xdr33 variant of the CIA HIVE attack kit, for example, used crafted TLS configurations to blend its C2 traffic with legitimate-looking HTTPS services, a pattern that becomes visible when certificate metadata doesn't match expected infrastructure.
Certificate Transparency Logs
Certificate transparency logs are public append-only records of every TLS certificate issued by participating certificate authorities. crt.sh provides a searchable interface. Querying by IP address or associated domain names returns a list of certificates issued, which often reveals subdomains, organizational names used during registration, and certificate issuance patterns. Attackers who use Let's Encrypt certificates for phishing or C2 infrastructure leave traces in transparency logs that persist long after the certificate expires.
Look for wildcard certificates, which can cover entire domain namespaces and indicate that the operator expects to spin up subdomains quickly. Also look for certificates issued for internal-looking hostnames like admin.internal.example.com appearing on a public IP. That mismatch between the certificate's intended use and its public exposure is a meaningful anomaly.
Correlation and Enrichment Across Threat Intelligence Platforms
Multi-Platform Reputation Checks
No single reputation database is comprehensive. Query the IP across VirusTotal, AbuseIPDB, Shodan, IBM X-Force Exchange, and AlienVault OTX simultaneously. Divergent results between platforms are more informative than agreement. An IP with a clean reputation on VirusTotal but significant abuse reports on AbuseIPDB in the last 48 hours suggests recently weaponized infrastructure that threat intelligence feeds haven't caught yet.
AbuseIPDB allows you to filter by report confidence score and category. Filter for categories relevant to your investigation: SSH brute force, port scanning, web application attack, phishing, and C2 communication each indicate different threat profiles. An IP reporting primarily across brute force categories might be part of a credential stuffing operation. One reporting across C2 and malware categories needs immediate escalation treatment.
Threat Intelligence Feed Cross-Reference
If your organization subscribes to commercial threat intelligence feeds through platforms like Recorded Future, Mandiant Advantage, or CrowdStrike Falcon Intelligence, cross-reference the IP there. These platforms correlate across dark web sources, incident response engagements, and proprietary sensor networks that public tools don't access. For ISAC members, sharing the IP with your sector's information sharing group can rapidly surface whether other members have encountered the same address.
Recent reporting on the ISC Stormcast feeds has highlighted specific IP ranges associated with active scanning campaigns. Checking your investigation target against these rolling advisories takes minutes and can immediately contextualize whether you're seeing widespread opportunistic activity or something more targeted at your specific environment.
Geolocation Analysis and Discrepancy Identification
IP geolocation is a probabilistic estimation, not a definitive fact. MaxMind, IPinfo, and IP2Location each maintain geolocation databases with different accuracy rates at different geographic levels. Query at least two independent geolocation services and compare results. Significant disagreements between providers, especially at the country level, indicate that the address may be routed through a VPN, proxy, or anycast infrastructure that obscures the true origination point.
Compare the geolocation result against the WHOIS registration location and the ASN's registered country of operation. An IP registered to a German hosting provider, geolocating to the Netherlands, with traffic originating at 3 AM local time in a timezone consistent with Eastern European working hours creates a geographic narrative that's worth documenting. None of these data points alone is conclusive, but together they inform whether the activity pattern is consistent with automated scanning from a rented server or deliberate human-operated intrusion.
Also cross-reference the user-agent strings, HTTP headers, and TLS fingerprints (JA3/JA3S hashes) from your session logs against geolocation data. A session claiming to originate from Singapore but presenting a JA3 fingerprint associated with a Russian threat actor's known tooling is a discrepancy that no geolocation database surfaces on its own.
OSINT Investigation Checklist
- Record the raw IP, timestamp, and session context from your logs before beginning any external queries.
- Run WHOIS and RDAP lookups to identify the registered netblock owner and abuse contact.
- Resolve the IP to its ASN and check routing history via BGPView or Hurricane Electric.
- Query passive DNS records across at least two providers (SecurityTrails, Farsight DNSDB, VirusTotal).
- Check Shodan and Censys for open ports, service banners, and TLS certificate metadata.
- Search certificate transparency logs via crt.sh for certificates associated with the IP or its domains.
- Run reputation checks across VirusTotal, AbuseIPDB, IBM X-Force, and OTX simultaneously.
- Cross-reference with commercial threat intelligence if available and relevant ISAC feeds.
- Compare geolocation results from at least two providers against WHOIS and ASN registration locations.
- Cross-match JA3/JA3S fingerprints from session logs against known threat actor tooling databases.
- Search threat reporting platforms and recent advisories for any reference to the IP or its associated infrastructure.
- Document the full evidence chain before making a block, escalate, or monitor decision.
Pivoting: Expanding the Investigation From One IP to Full Infrastructure
A single IP is rarely the complete picture. Sophisticated threat actors run distributed infrastructure, and identifying one node often provides the pivot points to map the rest. Once you've identified domains associated with your suspicious IP through passive DNS, pivot on those domains to find other IPs they've resolved to. This technique frequently surfaces additional C2 nodes, staging servers, or exfiltration endpoints that share the same operational infrastructure.
Certificate data offers another reliable pivot. If a TLS certificate on your target IP was issued for a specific domain, query crt.sh for all certificates issued to the same domain or the same organizational unit. Attackers who register infrastructure under consistent organizational identifiers across certificates expose their full deployment through transparency logs. The Hive-derived Xdr33 campaign analysis demonstrated exactly this kind of infrastructure mapping, where certificate metadata tied together geographically distributed nodes that behavioral analysis alone wouldn't have connected.
Shodan's alerting functionality allows you to monitor for new hosts presenting specific banners, certificates, or service configurations. If your investigation identified a distinctive nginx configuration or a specific self-signed certificate on the suspicious IP, set a Shodan alert for that fingerprint. When the attacker deploys additional infrastructure using the same template, you'll know immediately.
Integrating OSINT Findings Into Your Security Stack
OSINT investigation should produce outputs that feed back into your operational controls. An IP confirmed as malicious through your investigation workflow shouldn't just be blocked at the perimeter; the associated ASN, the hosting provider abuse contact, and the related domain infrastructure should all flow into your threat intelligence platform for automated enrichment of future alerts.
Structure your findings as a formal indicator package: the primary IP, associated domains, related IPs discovered through pivoting, certificate hashes, ASN numbers, and any JA3 fingerprints identified. Import this into your SIEM as a watchlist and configure correlation rules that trigger when any element of the package appears in logs, even if the original IP never appears again. Infrastructure reuse by threat actors means partial matches against an indicator package are meaningful.
For confirmed malicious IPs with identified abuse contacts, submit reports to AbuseIPDB and notify the hosting provider's abuse team. This creates pressure on the hosting provider to terminate the account and contributes to the shared intelligence ecosystem that other defenders benefit from. Organizations that contribute to platforms like AbuseIPDB see measurably better coverage in return.
Implementation Pitfalls That Derail Investigations
Treating Reputation Score as a Final Answer
Reputation scores aggregate historical data. Freshly deployed attack infrastructure consistently scores clean because it hasn't accumulated enough reports. Newly registered domains used in phishing campaigns, VPS instances spun up for a single intrusion operation, and addresses rotated within bulletproof hosting pools all start with clean reputations. An IP with a low reputation score and a creation date three days ago warrants more scrutiny than an IP with a moderate reputation score that's been active for two years.
Querying Only One Passive DNS Provider
Passive DNS coverage varies significantly between providers based on their sensor network distribution. A domain that resolves actively in Southeast Asian networks might appear in APNIC-adjacent passive DNS feeds but not in North American ones. Restricting investigation to a single provider creates blind spots. Farsight DNSDB, SecurityTrails, VirusTotal, and RiskIQ each have different coverage strengths. For thorough investigation, especially when the traffic appears international in origin, use at least two providers with geographically distributed sensor networks.
Skipping the Geolocation Discrepancy Check
Analysts frequently accept the first geolocation result returned without cross-referencing. Given that VPN services, residential proxy networks, and anycast configurations all distort geolocation accuracy, accepting a single result means making decisions based on potentially incorrect geographic attribution. The operational significance of traffic appearing to originate from a NATO ally versus a sanctions-restricted country is substantial. Take the two minutes to cross-reference at least two providers and document any discrepancy before making attribution claims.
Failing to Timestamp and Document the Investigation
OSINT data is ephemeral. DNS records change, WHOIS data gets updated or obscured, and Shodan scan data reflects the last crawl rather than real-time state. Every query result you collect should be timestamped and stored. If the investigation later becomes part of an incident report, legal proceeding, or regulatory disclosure, undocumented queries from memory are useless. Use a structured case management tool or even a timestamped markdown document to record each query, the tool used, and the result returned.
Ignoring the Hosting Provider Context
Two IPs in different /24 blocks can behave very differently based solely on who hosts them. A suspicious IP on AWS, Azure, or Google Cloud infrastructure exists in a different operational context than the same traffic originating from a hosting provider with a long history of ignoring abuse reports. The hosting provider context shapes your response: cloud provider abuse teams are generally responsive and can act within hours, while bulletproof hosting providers in permissive jurisdictions may never respond. Knowing which situation you're in determines whether reporting to the provider is worth the effort and what escalation path makes sense if they're unresponsive.
Stopping Investigation at the Single IP
Threat actors rarely operate from a single IP. Stopping the investigation without pivoting to associated infrastructure means you've identified one node of what may be a larger campaign. The IoT botnet infrastructure detailed in the TuxBot v3 reporting operated across multiple controller nodes with shared configuration signatures. Identifying one node through your initial investigation and then pivoting via passive DNS, certificate data, and ASN analysis to find the others is what transforms a single alert response into genuine threat intelligence about the broader campaign.
Building Repeatable OSINT Workflows Into Your SOC
Ad hoc investigation produces ad hoc results. For OSINT IP investigation to consistently deliver value, the workflow needs to be standardized into a runbook that any analyst can execute without depending on institutional knowledge held by a single senior team member. Document the tools, the sequence of queries, the pivot points, and the decision criteria that distinguish a confirmed malicious IP from one requiring continued monitoring.
Automation handles the first-pass enrichment layer efficiently. SOAR platforms can execute passive DNS lookups, WHOIS queries, reputation checks, and ASN resolution automatically when an alert fires, presenting the analyst with structured enrichment data before they've even opened the case. This reserves analyst judgment for the interpretation layer: reading the patterns across enrichment data, identifying discrepancies, deciding what to pivot on, and determining what the evidence chain actually means for your specific environment.
Train your analysts on the pivot methodology specifically. The ability to move from an IP to its domains, from those domains to additional IPs, from certificate metadata to related infrastructure, and from ASN data to hosting provider patterns is the skill that separates an analyst who closes alerts from one who maps threat actor infrastructure. That skill compounds over time as analysts build familiarity with the patterns that indicate different threat categories and different levels of operational sophistication from the actors running the infrastructure they're investigating.
