The Problem Nobody Warns You About Until You're Sitting With a Suspicious IP and No Context
An alert fires at 2:47 AM. Your SIEM flags an outbound connection to an IP address you don't recognize. The address isn't on any blocklist you subscribe to, geolocation returns a data center in Frankfurt, and your on-call analyst has roughly 20 minutes before they need to decide whether to isolate the endpoint or let the connection continue while investigation proceeds. This is the scenario where OSINT techniques either prove their operational value or reveal how underprepared most teams are when structured threat intelligence workflows don't exist ahead of time.
IP investigation using open-source intelligence is one of the most consistently undervalued skills in security operations. Not because analysts don't know the tools exist, but because the workflow connecting those tools into a coherent investigation chain rarely gets documented before it's urgently needed. This article builds that workflow, step by step, grounded in the kinds of threats security teams are actively dealing with in the current environment.
Understanding the Layers of Information an IP Address Contains
An IP address is not a single data point. It's an entry point into overlapping datasets that, when queried in the right sequence, reveal infrastructure ownership, hosting history, behavioral patterns, and network-level relationships. Before opening any tool, experienced investigators recognize that each query layer adds context that changes how subsequent results are interpreted.
The core layers of an IP investigation look like this:
- Registration data: Who registered the IP block and when, including ASN assignment and regional internet registry records
- Hosting and infrastructure context: Whether the IP belongs to a cloud provider, ISP, VPN or proxy service, or dedicated hosting company
- Passive DNS history: Which domains have resolved to this IP, both currently and historically
- Port and service data: What services were observed running on the IP across time
- Threat and abuse history: Reports of malicious activity, spam, scanning, or exploitation associated with the address
- Certificate transparency: TLS certificates issued for domains hosted on this IP
- Behavioral and relational data: Other IPs or infrastructure associated with the same actor or hosting fingerprint
Running these queries in sequence, rather than in parallel and without synthesis, is what separates an investigation from a tool dump.
Phase One: Today — The First 20 Minutes of an IP Investigation
Start With Registration and ASN Context
The first query should go to a Regional Internet Registry (RIR). For addresses in North America, ARIN handles this. For Europe, RIPE NCC. For Asia-Pacific, APNIC. For Latin America, LACNIC. For Africa, AFRINIC. Each registry provides WHOIS data that tells you the organization that holds the IP block, the allocation date, abuse contact information, and the ASN assigned to the address.
The ASN is particularly important because it identifies the network operator responsible for routing the IP. An IP resolving to AS14061, for example, places it inside DigitalOcean's infrastructure. AS16509 places it inside Amazon Web Services. These are legitimate providers that threat actors routinely abuse to host command-and-control infrastructure, precisely because outbound connections to major cloud providers blend into normal enterprise traffic.
The Kimwolf v7 botnet evolution documented in recent threat research demonstrates this clearly. Modern botnet operators architect their C2 infrastructure across multiple cloud-hosted IPs specifically to exploit the implicit trust that network teams extend to major ASNs. Blocking AS14061 or AS16509 wholesale is not operationally feasible for most organizations, which means the investigation has to go deeper than ASN-level filtering alone.
Tools for this phase: ARIN WHOIS, RIPE Stat, BGPView, ipinfo.io. All return ASN, organization, and allocation data in seconds.
Check Passive DNS Records
Passive DNS tells you which domain names have resolved to the IP you're investigating and when those resolutions were observed. This is one of the highest-value queries in an IP investigation because domain names are more expressive than IP addresses. They often reveal campaign naming conventions, actor infrastructure patterns, or connections to previously documented threat clusters.
If the IP in your alert has hosted five domains over the past six months, and three of those domains appear in existing threat intelligence as phishing or C2 infrastructure, that context changes your response posture immediately. The IP may not be on a current blocklist because it's new or recently reassigned, but passive DNS connects it to known malicious activity through historical association.
Tools for this phase: SecurityTrails, RiskIQ (now part of Microsoft Defender Threat Intelligence), Shodan's host history, VirusTotal's relations tab, CIRCL's passive DNS service, and Farsight DNSDB (paid, but operationally significant for depth of historical records).
When investigating infrastructure tied to campaigns like Project CAV3RN, where Google Apps Script and DNS-based channels are used for C2 relay and channel selection, passive DNS becomes essential. The use of DNS as a control mechanism means the IP addresses associated with the campaign may rotate frequently, but the domain patterns and resolution history leave a traceable record across passive DNS databases.
Query Threat Intelligence Aggregators
VirusTotal, AbuseIPDB, Shodan, and Censys should all be queried in the first phase. Each returns different signal types.
VirusTotal aggregates verdicts from over 70 security vendors. A clean result does not mean the IP is benign, but a result with multiple vendor flags provides immediate confirmation of known malicious activity. The relations tab in VirusTotal is particularly useful because it surfaces domains, files, and URLs associated with the IP.
AbuseIPDB aggregates community-reported abuse events. High confidence scores with multiple recent reports of scanning, brute-force activity, or spam are meaningful signals even when no formal threat intelligence exists.
Shodan and Censys scan the internet and store snapshots of what services are exposed on each IP. Investigators should look at what ports are open, what software versions are running, what TLS certificates are presented, and how the service fingerprint has changed over time. An IP running a Cobalt Strike Malleable C2 profile, for instance, often presents specific response characteristics that Shodan captures and that security researchers have documented as signatures.
Phase Two: This Week — Building Relational Context
Certificate Transparency Analysis
Every TLS certificate issued for a domain goes through a Certificate Transparency log, which is publicly accessible. When an attacker registers a domain and obtains a certificate to make their C2 or phishing site appear legitimate, that certificate gets logged. Certificate transparency logs let investigators pivot from an IP to associated domains and then to other certificates issued for similar domains, often revealing actor infrastructure before it becomes operational.
Tools for this phase: crt.sh, Censys certificates search, and Google's CT log viewer. Search for certificates issued to domains that resolved to your target IP, then look for wildcard certificates or certificate batches that suggest automated infrastructure provisioning, which is a common characteristic of large-scale botnet infrastructure like Evooo1Bot, the Linux botnet that has extended Mirai capabilities significantly beyond traditional DDoS operations.
Infrastructure Fingerprinting With Shodan and Censys
Service fingerprinting goes beyond checking whether an IP is known-malicious. The goal is to understand what the IP is doing technically and whether that behavior pattern matches known threat actor tooling or campaign infrastructure.
Specific indicators to investigate:
- Self-signed certificates with unusual or randomized common names
- Default Cobalt Strike or Metasploit response headers
- Specific Jarm TLS fingerprints associated with known C2 frameworks
- Open ports running services that don't match the declared organization's purpose
- SSH server banners with specific version strings linked to known implants
HoneyMyte's upgraded CoolClient backdoor, which now includes a kernel-level Windows rootkit component, illustrates why infrastructure fingerprinting matters. The communication infrastructure supporting that implant carries specific patterns observable through Shodan and Censys queries. Identifying those patterns across multiple IPs lets analysts map the campaign's full infrastructure footprint rather than responding to individual alerts in isolation.
Network Graph Analysis
Once you have IP addresses, domains, ASNs, and certificates connected through your investigation, graph visualization turns disconnected data points into a navigable map of related infrastructure. Maltego remains the standard tool for this work in commercial security environments. Free alternatives include Gephi for visualization after manual data collection, and SpiderFoot for automated OSINT collection that feeds graph analysis.
The value of graph analysis becomes apparent when investigating infrastructure like the C2 relay networks used in Project CAV3RN. Individual IPs may appear unconnected, but graph analysis reveals shared hosting providers, sequential IP allocations, or reused TLS certificates that establish organizational relationships across seemingly disparate infrastructure components.
Phase Three: This Quarter — Operationalizing Your OSINT Capability
Building Repeatable Investigation Runbooks
The most technically skilled analyst running a manual investigation under time pressure will still miss steps. Runbooks eliminate that variability by documenting the investigation sequence, the tools used at each step, the decision criteria for escalation or containment, and the artifacts to collect for documentation. A well-structured IP investigation runbook covers:
- Initial registration and ASN lookup with documented queries and expected output format
- Passive DNS query sequence with time range parameters
- Threat intelligence aggregator queries with scoring thresholds that trigger escalation
- Service fingerprinting checklist with specific indicators to check
- Certificate transparency lookups with pivot criteria
- Graph construction steps and relationship categories to document
- Evidence preservation requirements and chain-of-custody documentation
Runbooks should be stored where on-call analysts can access them during off-hours incidents, not in a shared drive that requires VPN access to reach during a network containment event.
Integrating OSINT Into Your SOC Workflow
Manual OSINT investigation at scale is not sustainable. Security teams managing significant alert volumes need enrichment automation that pulls OSINT data at alert creation time rather than requiring analysts to run lookups manually after triage.
SOAR platforms like Splunk SOAR, Palo Alto XSOAR, and open-source alternatives like TheHive with Cortex support automated enrichment playbooks that query VirusTotal, Shodan, AbuseIPDB, and passive DNS databases as soon as an alert fires. The analyst receives a pre-enriched alert with OSINT context already attached, which shifts their time from data collection to analysis and decision-making.
For organizations without SOAR infrastructure, n8n and custom Python scripts using public APIs from VirusTotal, Shodan, and SecurityTrails provide meaningful automation without enterprise tooling budgets. Even automating the first two layers of an investigation, registration data and threat aggregator lookups, frees significant analyst time for the higher-judgment phases of the workflow.
Threat Actor Infrastructure Tracking
Beyond reactive investigation, mature OSINT programs track known threat actor infrastructure proactively. This involves monitoring certificate transparency logs for patterns associated with specific actors, tracking ASN allocations favored by particular hosting services that abuse reports link to malicious infrastructure, and maintaining watchlists of IP ranges that have supported previous campaigns.
The Hugging Face compromise, which demonstrated how low-cost persistence methods can sustain unauthorized access to significant AI infrastructure, illustrates the value of proactive tracking. When attackers establish persistence using low-signature methods, reactive investigation after the fact often reveals infrastructure that was observable before exploitation if the right monitoring was in place. Token theft enabling resource abuse, as documented in recent research on AI resource hijacking, follows similar infrastructure patterns that OSINT monitoring can surface.
Handling Streaming Device and Consumer IoT IPs
Recent security reporting on TV streaming sticks highlights that consumer devices and IoT endpoints increasingly appear in enterprise-adjacent networks, whether through BYOD policies, work-from-home environments, or supply chain connections. IPs associated with these devices require a different investigative approach because the infrastructure behind them often belongs to legitimate manufacturers operating services that have nonetheless been compromised or abused.
When investigating IPs associated with connected consumer devices, investigators should check whether the address belongs to a manufacturer's cloud service infrastructure, whether that infrastructure has abuse reports tied to specific device models or firmware versions, and whether the communication pattern observed matches documented malicious behavior or normal device telemetry. Context prevents false positives that would otherwise disrupt legitimate operations.
Evidentiary Standards and Legal Considerations
OSINT investigations generate data that may need to support legal action, law enforcement referrals, or internal disciplinary processes. Investigators should document every query, the tool used, the timestamp, and the exact output returned. Screenshots should include browser address bars showing the query URL. API query logs should be preserved alongside results.
Data from public sources is generally usable in legal contexts, but the chain of custody matters. Evidence collected without documentation of when and how it was obtained loses credibility in proceedings. Establish documentation habits before you need the evidence, not after you realize you need it.
Attribution from OSINT alone carries inherent uncertainty that investigators should communicate clearly in reporting. An IP hosting C2 infrastructure that a passive DNS database connects to a known actor's campaign is meaningful intelligence. It is not proof of attribution sufficient to name a threat actor in an external statement or legal filing without corroborating evidence.
When OSINT Runs Out of Signal
Some IPs yield minimal open-source intelligence because the infrastructure is new, the operator has taken active steps to minimize exposure, or the relevant data exists in commercial threat intelligence databases that your organization doesn't subscribe to. When public OSINT sources return limited results, the investigation should shift to behavioral analysis of the traffic itself.
Network flow data, endpoint telemetry, and application logs provide behavioral context that complements OSINT. An IP with no threat intelligence history that is receiving encrypted connections from multiple internal endpoints at regular intervals may be benign or may be a C2 server that is simply too new to have appeared in threat databases. Behavioral analysis, examining connection frequency, data volume, timing patterns, and the internal endpoints making contact, fills the gap that OSINT cannot.
This combined approach, OSINT for external context and behavioral analysis for internal signal, gives security teams a more complete picture than either method alone. The most effective IP investigations run both tracks in parallel rather than treating them as sequential phases.
Phased Recommendations Summary
Today
- Run registration, ASN, passive DNS, and threat aggregator queries for every suspicious IP your team investigates manually. Document results consistently.
- Set up free accounts on VirusTotal, AbuseIPDB, Shodan, and Censys if your team doesn't already have access.
- Cross-reference any flagged IPs against passive DNS history before concluding an IP is clean because it's absent from current blocklists.
This Week
- Draft a basic IP investigation runbook covering the query sequence, tool selection, decision thresholds, and documentation requirements.
- Add certificate transparency lookups and infrastructure fingerprinting to your standard investigation process for high-priority alerts.
- Evaluate whether your current SIEM or SOAR platform supports automated enrichment for IP observables, and identify what API integrations would be required.
This Quarter
- Implement automated enrichment for IP alerts using SOAR playbooks or scripted API calls that populate alert records before analyst triage begins.
- Establish proactive monitoring for certificate transparency patterns and ASN allocations associated with threat actors relevant to your sector.
- Review evidentiary documentation practices to ensure investigation records meet standards that would support legal or regulatory proceedings if needed.
