The Comfortable Lie About IP Investigation
Most cybersecurity teams treat IP investigation as a lookup task. An address appears in a log, someone pastes it into a threat intelligence portal, checks a reputation score, and makes a decision. That workflow feels thorough. It produces a result quickly. And it misses a significant portion of what open-source intelligence can actually surface when someone is willing to work through the full picture.
The deeper problem is structural. Security teams under alert pressure default to tools that return verdicts instead of evidence. A reputation feed says an IP is malicious and the analyst moves on. A geolocation database says the address resolves to Frankfurt and the ticket gets categorized accordingly. Neither result tells you who operates the infrastructure, how long they have used it, what other campaigns share the same fingerprint, or whether your organization is one of several targets in a coordinated operation.
The Snowflake extortion case that resulted in a Canadian man pleading guilty demonstrated exactly this gap. Investigators ultimately traced the campaign not through a single lookup but through infrastructure overlap analysis, registration patterns, and correlating attacker behavior across multiple victims. The IP addresses involved were not sitting in every threat feed from day one. The intelligence had to be assembled.
This article covers how to actually do that assembly work.
What Passive DNS Actually Shows You
Passive DNS is one of the most underused investigative layers available to security professionals, largely because its value is not immediately obvious from a single query. When you look up what hostnames have historically resolved to a given IP address, you are building a map of everything that infrastructure has been used for over time.
The practical workflow starts with a query against a passive DNS provider such as SecurityTrails, Farsight DNSDB, or RiskIQ (now part of Microsoft Defender Threat Intelligence). Submit the IP address and examine the full resolution history, not just current records. Look for patterns in naming conventions. Attackers reuse naming schemes across campaigns. A C2 server that previously hosted a domain following a particular format gives you a template to search for related infrastructure you have not yet encountered.
Project CAV3RN, which researchers have tracked as it evolves its Google Apps Script abuse and DNS-based C2 channel selection, illustrates this principle clearly. The campaign's infrastructure changes frequently, but the naming patterns and resolution behaviors leave traces in passive DNS that allow analysts to map new nodes as they spin up. The IP addresses rotate. The behavioral fingerprint does not.
When reviewing passive DNS results, pay attention to co-resolution: other IP addresses that have hosted the same domain name. This expands your investigation from a single address to a cluster of infrastructure that may include staging servers, secondary C2 channels, or fallback endpoints the threat actor has not yet activated.
ASN and WHOIS Investigation Beyond the Surface Read
Every IP address belongs to an Autonomous System Number. The ASN tells you who routes the traffic, which is often more informative than the registrant information on the IP block itself. Hosting providers, bulletproof hosters, and residential proxy services each have distinct ASN characteristics that carry investigative weight.
Start with a standard WHOIS query on the IP block, then query the ASN separately using tools like Hurricane Electric's BGP Toolkit, RIPE NCC's database for European addresses, ARIN for North American allocations, or APNIC and LACNIC for their respective regions. Cross-reference what the registration says against what the infrastructure actually does. A block registered to a generic hosting company that appears repeatedly in threat reports is a different situation than the same block appearing in investigations involving a bulletproof hosting network with known ties to criminal infrastructure.
The registration dates matter. Freshly registered IP space allocated to a small, unfamiliar organization that immediately begins appearing in attack logs is a meaningful signal. Compare the allocation date against the first appearance of the IP in your logs or in threat intelligence reports. A gap of days or weeks between allocation and malicious activity often indicates infrastructure purpose-built for a campaign.
The Armored Likho cyber-espionage group, which has expanded its toolkit in recent campaigns, demonstrates how sophisticated threat actors approach infrastructure management. Their operations involve deliberate use of hosting providers that create investigative friction. Tracing their IP addresses through WHOIS alone produces dead ends. The investigative progress comes from correlating ASN behavior, registration patterns, and passive DNS history across the cluster.
Certificate Transparency Logs as Investigative Infrastructure
TLS certificate issuance produces public records that many IP investigators overlook. Certificate Transparency logs, searchable through Censys, crt.sh, or Facebook's Certificate Transparency monitoring tool, reveal the hostnames associated with a given IP address at the time certificates were issued, including hostnames that may never have appeared in DNS queries you captured directly.
Query crt.sh for the domains associated with an IP address or its known hostnames. Look at certificate issuance timing relative to known attack campaigns. Examine the Subject Alternative Names in each certificate, which often list multiple hostnames on a single certificate and can immediately expand your infrastructure map. Phishing campaigns, C2 infrastructure, and watering hole operations all require valid certificates in the modern web environment, and every certificate leaves a permanent, searchable record.
The ScanBox keylogger campaigns that have targeted organizations through watering hole attacks relied on attacker-controlled infrastructure that required certificate issuance. Certificate transparency analysis of the IP addresses involved allowed researchers to identify the full scope of domains hosted on that infrastructure, including those not yet observed delivering malicious payloads. That advance mapping enables proactive blocking rather than reactive response.
When examining certificates, treat wildcard certificates with particular attention. A wildcard certificate on suspicious infrastructure suggests the operator intends to run multiple subdomains, which is consistent with phishing kit deployment, C2 subdomain generation, or domain fronting configurations.
Shodan, Censys, and Banner Grabbing at Scale
Internet-wide scanning databases index what services are running on IP addresses at the time of their last scan. Shodan and Censys are the most commonly used, and both support detailed queries that go well beyond a basic IP lookup.
When investigating a suspicious IP, pull the full service banner history from both platforms. Look at what ports are open, what software versions are disclosed, what HTTP headers are returned, and what SSL certificate details are exposed. Attackers frequently reuse configurations. A web server running a specific version of nginx with a particular header combination, or a Cobalt Strike listener with a specific malleable C2 profile signature, creates a fingerprint that can identify other servers operated by the same actor even across different IP addresses.
Censys supports structured queries that allow you to search for other hosts sharing specific certificate values, banner strings, or configuration details. If your investigation identifies a C2 server running on port 8080 with a specific HTTP response header, you can query Censys for all hosts returning that same configuration. The result is frequently a list of related infrastructure the threat actor operates globally.
Shodan's historical data is particularly useful for understanding how an IP address's exposed services have changed over time. An address that was running standard web hosting six months ago and is now exposing a Metasploit handler has a history worth understanding. That transition often corresponds to when the infrastructure changed hands or purpose.
Building the Timeline: OSINT in Chronological Order
Effective IP investigation produces a timeline, not just a snapshot. Each data source contributes temporal information that, assembled correctly, tells you when infrastructure was built, when it became active, when it was observed in campaigns, and how it has evolved.
Construct your timeline starting from the earliest available data point. WHOIS registration gives you the allocation date. Certificate transparency gives you first issuance. Passive DNS gives you when names began resolving to the address. Shodan historical data gives you when specific services appeared. Threat intelligence reports give you first observed malicious activity. Your own logs give you first contact with your organization.
This chronological assembly frequently reveals investigative leads that a snapshot approach misses entirely. An IP address that appears in your logs today may have been documented in a threat report three months ago under a different campaign name. The timeline makes that connection visible. It also shows you whether the address is still actively used for the same purpose or whether the infrastructure has been repurposed since the initial reports.
The 'Ransom Busters' campaign, in which ransomware actors posed as incident recovery services, used infrastructure with a history that predated the recovery service persona. Investigators who built timelines from the IP addresses involved found prior associations with ransomware deployment activity, which contradicted the persona the operators were presenting to victims. The timeline was the evidence.
Correlating Threat Intelligence Reports Against Infrastructure Evidence
Published threat intelligence reports, including those from commercial vendors, government agencies like CISA, and open-source researchers, frequently include IP addresses as indicators of compromise. These reports represent investigative starting points rather than complete pictures.
When an IP address from your logs appears in a published report, extract every other indicator from that report and run each one through your OSINT workflow independently. A report on a ransomware campaign may list twenty IP addresses. Investigating the overlap between those addresses through passive DNS, certificate transparency, and ASN analysis will surface shared infrastructure that the report itself may not have mapped explicitly.
The State of Ransomware data for Q2 2026 reflects continued use of infrastructure-sharing across ransomware groups, particularly in initial access operations. Groups lease infrastructure, share bulletproof hosting resources, and reuse tooling that leaves consistent fingerprints across campaigns attributed to different names. OSINT correlation across the IP addresses in those reports frequently produces evidence of infrastructure relationships that attribution analysis alone does not capture.
Cross-reference your findings against VirusTotal Graph, which allows you to visualize relationships between IP addresses, domains, files, and URLs. A suspicious IP connected through VirusTotal's relationship graph to known malware samples, malicious domains, or previously investigated infrastructure gives you evidentiary weight that a reputation score alone cannot provide.
Operational Security Awareness During Active Investigation
Active OSINT investigation of suspicious IP addresses carries operational security considerations that many practitioners handle poorly. Querying a C2 server directly, visiting a suspicious URL, or interacting with attacker infrastructure from your organization's IP space reveals that you are investigating. Sophisticated threat actors monitor connections to their infrastructure.
Route all active investigation traffic through dedicated analyst infrastructure that is not associated with your organization. Use virtual machines with clean network configurations and VPN routing that does not expose your organization's IP space. For any interaction with live infrastructure, treat the connection itself as a potential intelligence leak to the adversary.
Passive data sources avoid this problem entirely. Passive DNS, certificate transparency, WHOIS history, and Shodan data are all collected by third parties and do not require direct contact with the target infrastructure. Build your investigation primarily on passive sources and reserve active interaction for controlled environments where the exposure is intentional and managed.
The CopyCop campaign targeting AI investment in Armenia, which involved a sophisticated watering hole and social engineering component, monitored visitor traffic to its infrastructure as part of target profiling. Analysts who accessed the infrastructure without operational security precautions potentially contributed to the campaign's victim profile data. Clean investigation practices protect both the analyst and the investigation.
Documenting Investigation Findings for Operational Use
OSINT investigation produces value only when findings are documented in a format that supports downstream operational decisions. Raw data collected during investigation needs to be structured around specific questions: Is this IP currently active? What infrastructure does it share with known threat actors? What organizations or sectors have been targeted by infrastructure associated with this address? How confident is the attribution?
Use a consistent documentation format that captures the source, timestamp, and confidence level of each finding. An IP address linked to a threat actor through passive DNS overlap is a lower-confidence finding than one linked through a combination of passive DNS, certificate reuse, ASN overlap, and appearance in multiple published reports. The confidence level should be explicit in your documentation and should drive the operational response.
Share findings with relevant teams in a format they can act on. Firewall teams need IP addresses and CIDR ranges. Threat hunters need behavioral indicators and infrastructure patterns. Incident responders need the timeline and related indicators. SOC analysts need the verdict and the evidence summary. Producing a single document that serves all audiences produces a document that serves none of them well. Tailor the output to the consumer.
Consider feeding confirmed infrastructure findings back into your organization's threat intelligence platform so that future investigations can build on prior work. An IP cluster mapped during one investigation becomes a reference point for the next. Organizations that treat each investigation as isolated work lose the cumulative intelligence advantage that systematic documentation provides.
Where the Work Actually Pays Off
The return on thorough OSINT investigation is not immediate. It compounds over time as your organization builds an understanding of threat actor infrastructure patterns, establishes correlation between campaigns, and develops the institutional knowledge to recognize familiar fingerprints quickly when they appear in new incidents.
Security teams that invest in this work find that initial investigations are slow and labor-intensive while subsequent investigations involving related infrastructure become significantly faster. The first time you map a bulletproof hosting network's IP ranges through passive DNS and ASN analysis, it takes hours. The second time infrastructure from that network appears in your logs, recognition is near-immediate.
The practical payoff also extends to proactive defense. Infrastructure mapped before a campaign reaches operational intensity can be blocked before your organization receives its first probe. Certificate transparency monitoring for naming patterns associated with known threat actors gives you advance warning of new infrastructure deployment. Passive DNS monitoring for resolution changes on previously investigated addresses tells you when dormant infrastructure reactivates.
IP investigation built on OSINT disciplines produces intelligence that drives decisions. Reputation lookups produce verdicts. The difference between those two outcomes determines whether your security program understands the threats it faces or merely reacts to the alerts those threats eventually generate.
