When the Investigation Started With a Confident Assumption
A mid-sized financial services firm received alerts showing repeated authentication attempts from an IP address registered to a well-known cloud provider in Frankfurt. The security team flagged it, noted the European origin, and deprioritized the alert because the company had no EU clients and assumed the source was a misconfigured automated scanner. Three weeks later, during a routine review, a junior analyst noticed the same IP had established several successful connections during off-hours. The address belonged to a compromised cloud instance that had been rented and provisioned specifically to blend in with legitimate infrastructure traffic.
The investigation failed not because the team lacked tools, but because they carried assumptions into the process that the data never supported. OSINT-based IP investigation is a discipline built on verifying claims, not confirming them. This article addresses the most persistent myths that undermine that discipline, and replaces them with methods that hold up in real incidents.
Myth One: Registration Data Tells You Who Is Behind the Address
WHOIS and RDAP lookups are often the first stop in any IP investigation, and they produce output that looks authoritative. Registrant name, organization, contact email, abuse address. Security professionals sometimes treat this information as a reliable indicator of the actor behind the traffic.
In practice, registration data reflects the entity that controls the IP block at the ISP or hosting provider level, not the person or group generating the traffic. Cloud providers, VPS hosts, and residential proxy networks routinely appear in WHOIS records for IPs that are actively used by threat actors. The actor rents compute, routes traffic, and disappears. The WHOIS record still shows Amazon, DigitalOcean, or whatever legitimate hosting provider allocated the block.
The practical correction here is to treat WHOIS as infrastructure context, not actor attribution. Use it to answer questions like: Is this a residential ISP, a data center, a VPN provider, or a known bulletproof hosting AS? That classification informs what behavior you expect and what controls apply. RDAP queries through the appropriate Regional Internet Registry (ARIN, RIPE, APNIC, LACNIC, AFRINIC) give you the same data with structured output that integrates cleanly into investigation workflows.
Abuse contact information does have operational value. Filing reports to abuse@[provider] for cloud-hosted attacker infrastructure occasionally results in account termination, particularly with providers that maintain active abuse desks. Snowflake-related extortion activity, as seen in recent criminal cases involving compromised cloud credentials, has repeatedly traced through cloud provider abuse channels to help disrupt campaigns in progress.
Myth Two: A Single Reputation Score Settles the Question
IP reputation feeds assign scores or verdicts based on historical behavior: past spam activity, presence in blocklists, participation in known malicious campaigns. Security teams under time pressure often use these scores as binary decisions. High reputation score means safe, low score means block.
The structural problem is that reputation data ages. An IP that ran a phishing operation six months ago may now be assigned to a different cloud tenant running legitimate infrastructure. An IP that scores clean today may have been provisioned for an attack campaign that started yesterday. The Ransom Busters operation, in which a ransomware actor posed as an incident recovery service, used infrastructure that appeared benign in reputation feeds because the campaign was new and the addresses had no prior abuse history.
Operationalizing reputation data requires layering it against behavioral signals rather than using it as a standalone verdict. When investigating a suspicious IP, run it through multiple reputation sources simultaneously: VirusTotal, AbuseIPDB, Shodan, Censys, and any commercial threat intelligence feeds your organization subscribes to. Disagreement between sources is informative. An IP that scores clean on one feed and appears in active abuse reports on another warrants deeper review rather than a quick dismissal.
Pay attention to first-seen dates on reputation entries. An IP appearing in abuse databases for the first time within the last 48 to 72 hours is a different signal from one with a multi-year history of low-level spam activity. Recency often correlates with active campaign infrastructure.
Myth Three: Passive DNS Is Only Useful for Domain Investigations
When an IP address is the starting point, investigators sometimes bypass passive DNS entirely and focus on the address itself. Passive DNS is understood as a domain-centric tool, useful for finding what domains resolved to a given IP historically, but not considered essential when the artifact you have is an address rather than a hostname.
This misses a substantial portion of what passive DNS reveals about IP-based investigations. Running a reverse lookup against passive DNS databases surfaces every hostname that has ever pointed to that address. This reconstructs the operational history of the infrastructure. A single IP that has hosted ten different domains over eight months, with domains cycling every two to three weeks, describes a pattern consistent with rotating campaign infrastructure rather than a misconfigured server.
Tools like SecurityTrails, PassiveTotal (now part of the Recorded Future ecosystem), DNSDB, and the free RiskIQ Community interface provide passive DNS data with varying retention windows and query limits. For each domain surfaced, examine registration dates, registrar patterns, and whether other IPs in the same netblock hosted similar domain clusters. This process, known as infrastructure pivoting, frequently connects isolated-looking IPs to broader campaigns.
The Project CAV3RN activity, which has used Google Apps Script as a C2 relay and DNS-based channel selection, demonstrates why this matters operationally. The C2 architecture relied on DNS resolution to select active channels dynamically. Passive DNS analysis of IPs associated with early-stage CAV3RN activity would have surfaced the resolution patterns that characterized the campaign before behavioral signatures were widely available.
Myth Four: Shodan and Censys Are Interchangeable
Shodan and Censys both scan internet-facing infrastructure and index what they find. Security teams often treat them as functionally equivalent, picking one and ignoring the other. The two platforms scan at different frequencies, prioritize different ports and protocols, and present data with different structures. Using both, and understanding what each one captures that the other misses, substantially improves investigation quality.
Shodan maintains a broader historical banner database and provides richer integration options for automated queries. Its faceted search allows you to identify other IPs running the same service version, the same SSL certificate, or the same HTTP response headers as a known malicious host. Censys tends to prioritize TLS certificate data and offers more granular certificate transparency log integration, which makes it particularly useful for tracing campaign infrastructure that uses freshly issued certificates.
When investigating a suspicious IP, run both queries. Compare the banners, open ports, certificate subjects, and service versions each platform returns. Look for certificate subject alternative names (SANs) that reveal additional domains associated with the same certificate, then pivot those domains back into passive DNS to find additional IP infrastructure. Armored Likho, a threat group that has expanded its cyber-espionage toolkit in recent periods, has used certificate reuse across campaign infrastructure in ways that Censys certificate pivoting can surface.
Shodan's historical data view shows what services were running on a given IP at different points in time. An IP that currently shows no open ports may have been running a C2 service two months ago. That historical context changes the interpretation of current traffic from that address considerably.
Practical Certificate Pivoting Workflow
- Identify the TLS certificate on the suspicious IP using Censys or Shodan.
- Extract the certificate fingerprint (SHA-256 or SHA-1).
- Search for other IPs presenting the same certificate across both platforms.
- For each additional IP found, run passive DNS to identify associated domains.
- Check registration patterns across all discovered domains for shared registrar, registrant email, or nameserver clusters.
- Cross-reference all identified IPs against reputation feeds and your own traffic logs.
Myth Five: ASN Lookup Is the End of Network Context Investigation
Autonomous System Number lookup tells you which organization is responsible for routing a block of IP addresses. Security teams often stop there: they identify the ASN, note the owning organization, and move on. ASN data is more useful as a starting point than a conclusion.
After identifying the ASN, examine the full IP range allocated to that AS. Tools like BGPView, Hurricane Electric's BGP toolkit, and RIPE's routing registry expose the full prefix list for any ASN. If the suspicious IP is in a /24 that also contains known malicious infrastructure documented in public threat reports, that spatial relationship is significant. Attackers operating from cloud providers frequently provision multiple instances within the same prefix range.
ASN reputation is a separate signal from IP reputation. Some ASNs have documented histories of hosting abuse without meaningful enforcement. Monitoring traffic volumes from specific ASNs, and flagging deviations, gives you early warning of campaigns building in spaces your blocklists have not yet catalogued. The CopyCop operation targeting AI investment activity in Armenia involved infrastructure routed through ASNs that served as reliable indicators once the campaign was understood, but initial alerts came from behavioral anomalies rather than ASN blocklisting.
BGP hijacking introduces another layer of complexity. An IP that correctly maps to a legitimate ASN in current routing tables may have been temporarily routed through a different AS during the relevant attack window. Checking historical BGP routing data through services like RIPE RIS or RouteViews helps identify whether an IP's routing path was stable during the period of concern.
Integrating Multiple Data Sources Without Drowning in Output
The volume of data available through OSINT for a single IP address can exceed what any analyst can process manually during an incident. Structure matters more than tool count.
Build your investigation around a defined set of questions rather than running every available tool. The core questions for IP investigation are: Who controls this address at the infrastructure level? What services has it exposed to the internet and when? What domains have resolved to it and what does their registration history suggest? Does the behavioral pattern of traffic from this address match the technical profile of the infrastructure?
Documentation discipline prevents duplicate work and enables hand-offs. Tools like Maltego, SpiderFoot, and open-source alternatives like theHarvester provide graph-based or structured output that preserves the relationship between artifacts as the investigation expands. For teams without budget for commercial platforms, a structured investigation log in a shared document with explicit source citation for every data point achieves the same coordination goal at lower cost.
Watering hole campaigns delivering keyloggers like ScanBox depend on IP infrastructure that sits behind otherwise legitimate-looking domains. Full investigation of the IP layer, including hosting history, co-hosted domains, and certificate relationships, consistently surfaces campaign infrastructure before behavioral signatures propagate to detection platforms. The analysts who caught ScanBox delivery infrastructure early in past campaigns did so through infrastructure pivoting, not signature matching.
When OSINT Investigation Connects to Active Defense
Open source investigation produces intelligence. Intelligence has to connect to operational decisions to have defensive value. The handoff between investigation findings and defensive action is where many OSINT workflows break down.
Define in advance what findings trigger what actions. An IP confirmed as active C2 infrastructure through certificate pivoting and passive DNS correlation warrants immediate blocking and retrospective log review to identify all systems that communicated with it. An IP associated with a known VPN provider but showing no other malicious indicators warrants enhanced logging rather than blocking, because blanket VPN provider blocking creates significant false positive rates in environments with legitimate remote work.
Share findings through appropriate channels. Modern SOC operations increasingly emphasize identity and access context alongside network indicators. An IP investigation that surfaces a credential-stuffing campaign is more actionable when it connects to the identity systems that can respond, such as forcing re-authentication for accounts that authenticated from the flagged address during the relevant window. The identity front door framing that SOC teams are increasingly adopting makes this connection explicit: network-layer IP investigation findings feed directly into identity-layer response decisions.
Threat intelligence sharing, through ISACs, MISP instances, or community platforms, means that your investigation findings can protect organizations facing the same campaign infrastructure. The value of that sharing depends on the quality and specificity of the indicators you contribute. IP addresses with full infrastructure context, including associated domains, ASN information, certificate fingerprints, and behavioral notes, are operationally useful to recipient organizations. Raw IP lists without context contribute noise rather than signal.
Building Investigation Capacity That Holds Under Incident Pressure
OSINT IP investigation skills atrophy when they are only exercised during incidents. Regular practice against historical cases, threat intelligence exercises, and tabletop scenarios that require following an IP through the full investigation workflow keeps analyst capability current and surfaces gaps in tooling or data access before those gaps matter in a live investigation.
Document your investigation playbooks at the workflow level, not the tool level. Specific tools change, add paywalls, or disappear. The underlying workflow of: identify infrastructure owner, map historical services, surface associated domains, pivot certificate relationships, check BGP context, cross-reference reputation sources, and correlate against internal logs remains valid regardless of which specific platform you use for each step.
Access to current data sources requires maintaining active accounts and API keys for the platforms you rely on. Discovering that your Shodan API key expired, or that your passive DNS subscription lapsed, during an active investigation adds avoidable friction. Treat investigation tool access as operational infrastructure with its own maintenance requirements.
The most effective IP investigations combine automated enrichment for speed with analyst judgment for interpretation. Automation handles the data collection and correlation steps that are well-defined. Human judgment handles the interpretation of ambiguous signals, the decision about when a pattern is meaningful versus coincidental, and the determination of what action the findings actually support. Neither element alone produces reliable results under the conditions real incidents create.
