When the Alert Was Right and the Investigation Had Nowhere to Start
A financial services firm's SOC analyst flagged an outbound connection to an unfamiliar IP address at 2:47 AM on a Tuesday. The endpoint was a domain controller. The destination was a single IPv4 address that no threat feed flagged as malicious. The IP reputation score was clean. The geolocation said Amsterdam. The analyst had fifteen minutes before the shift handoff and no internal runbook covering this scenario.
What followed was a scramble through browser tabs, disconnected tools, and manual lookups that produced contradictory data. The investigation stalled. Forty minutes later, a second analyst picked it up and discovered the IP belonged to an autonomous system associated with bulletproof hosting infrastructure that had been linked to three separate APT campaigns over the prior eight months. None of that context surfaced in the initial lookup because nobody had a structured OSINT workflow.
This is not an unusual situation. IP investigation is one of the most time-pressured activities in security operations, and most teams execute it inconsistently. This article walks through a structured OSINT methodology for IP investigation, with the kinds of details that actually matter when you are under pressure and the data is messy.
Why IP Investigation Deserves Its Own Methodology
IP addresses appear in every layer of security operations: firewall logs, IDS alerts, phishing headers, malware sandbox reports, threat intelligence feeds, and incident tickets. The problem is that an IP address alone tells you very little. What tells you something is context: the autonomous system it routes through, the hosting provider that owns the infrastructure, the domains that have pointed to it, the ports it has historically exposed, and whether other researchers have seen it in active campaigns.
Building that context requires pulling from multiple open sources in a logical sequence. Skipping steps or pulling data from a single tool introduces blind spots. The recent evolution of campaigns like Kimwolf v7, where botnet infrastructure is rebuilt continuously to evade static blocklists, and Project CAV3RN's use of Google Apps Script as a C2 relay with DNS-based channel selection, demonstrate exactly why single-source lookups fail. Infrastructure tied to sophisticated campaigns is designed to look clean at any single query point.
Layer One: Ownership and Routing Context
Start with registration data. The first question is: who owns the IP block, and what routing infrastructure does it use?
WHOIS and Regional Internet Registry Data
Query the relevant Regional Internet Registry directly. For North American addresses, that is ARIN. For European addresses, RIPE NCC. For Asia-Pacific, APNIC. Each RIR provides allocation records that show the organization that received the block, the date of allocation, and the contact information on file.
Pay attention to allocation age. A freshly allocated /24 with minimal abuse contact history is a different risk profile than a block that has been held by a regional ISP for twelve years. Bulletproof hosting providers frequently rotate IP blocks or operate under layered shell organizations. If the registrant name resolves to a company that appears to have no web presence, no business history, and contact emails on free webmail domains, that is a meaningful signal.
Autonomous System Number Analysis
Every routable IP address belongs to an autonomous system. The ASN provides the routing identity of the network and is more stable than the IP address itself. Look up the ASN using tools like BGP.he.net, RIPE's routing registry, or Team Cymru's IP-to-ASN mapping service.
Once you have the ASN, check it against ASN reputation databases and abuse history. Some ASNs have documented histories of hosting malicious infrastructure. Others are legitimate cloud providers that host both benign and malicious content. The distinction matters. An IP on AWS or Google Cloud requires a different response than one on an ASN that primarily serves as a transit provider for networks in jurisdictions with limited abuse enforcement.
This technique is directly relevant to the HoneyMyte APT group's recent upgrade of the CoolClient backdoor with kernel-level Windows rootkit capabilities. Campaigns like that one rely on carefully chosen infrastructure that blends into legitimate-looking ASNs while maintaining persistence. ASN-level analysis often surfaces patterns that IP-level analysis misses.
Layer Two: Passive DNS and Historical Domain Association
An IP address is often more informative in the context of what domains have pointed to it than in isolation. Passive DNS data captures DNS resolution history, showing you which hostnames have been associated with an IP across time.
Using Passive DNS Effectively
Tools like Farsight DNSDB, RiskIQ PassiveTotal, and SecurityTrails provide passive DNS data at varying depths. When you query an IP, you are looking for several things:
- How many domains have pointed to this IP, and over what time window?
- Are those domains clustered in registration date, suggesting bulk registration?
- Do the domain names follow naming patterns consistent with DGA (domain generation algorithm) output or typosquatting?
- Have any of those domains appeared in threat intelligence reporting?
A single IP that has hosted dozens of domains registered within a narrow window, particularly domains with random-looking strings or look-alike spellings of legitimate brands, is a strong indicator of malicious infrastructure even if the IP itself has no current threat feed hits.
The Linux botnet Evooo1Bot, which has expanded Mirai capabilities beyond DDoS to include additional exploitation techniques, relies on infrastructure that rotates domains while keeping IP blocks relatively stable. Passive DNS investigation would surface the rotation pattern even when a current lookup returns nothing alarming.
Forward DNS and Current Resolution
Run forward DNS lookups on all domains you discover through passive DNS. What do those domains resolve to today? If the IP has been abandoned by its previous infrastructure but the domains still resolve elsewhere, you can trace the infrastructure migration. If the domains have expired or been sinkholed, that itself is informative.
Layer Three: Open Port and Service Fingerprinting
Banner grabbing and port scan data from passive sources give you a picture of what services an IP has historically exposed without requiring you to actively probe the target, which may be illegal or operationally inadvisable depending on your context.
Shodan, Censys, and FOFA
Shodan, Censys, and FOFA are the primary platforms for passive service enumeration. Each crawls the internet and indexes banners, certificates, and service responses. Query the IP on each platform and examine the historical records, not just current state.
Look for:
- Open ports associated with known malware C2 protocols (4444, 8443, 8080 used atypically, non-standard SSH ports)
- Self-signed certificates with suspicious common names or organizational fields
- TLS certificate hashes that appear on multiple IPs, indicating shared infrastructure
- Web server banners that match known malicious tool fingerprints
Certificate pivoting is particularly powerful. When a TLS certificate appears on multiple IP addresses across different ASNs, it links infrastructure that would appear unrelated at the IP level. This technique was instrumental in tracking C2 infrastructure for campaigns using tools similar to those described in the Project CAV3RN research, where C2 channels were distributed across seemingly unrelated endpoints.
Default Credential Exposure and Streaming Devices
It is worth noting that recent advisories around TV streaming sticks and similar consumer devices highlight a risk that extends into corporate environments: devices with default credentials or unpatched firmware regularly appear in Shodan results with administrative interfaces exposed. When investigating IPs associated with lateral movement, checking Shodan for exposed management interfaces can confirm whether a compromised device is acting as a relay node rather than a true origin.
Layer Four: Threat Intelligence Cross-Reference
Once you have the ASN, passive DNS history, and service fingerprint data, cross-reference everything against threat intelligence sources. The goal here is not to get a verdict from a single feed, but to triangulate across sources.
Free and Open Sources
Several open threat intelligence platforms offer lookup APIs that can be integrated into investigation workflows:
- VirusTotal: Aggregates detection verdicts from multiple security vendors and shows community comments. Check both the IP and all associated domains.
- AlienVault OTX: Crowd-sourced threat indicators with pulse associations that link IPs to named campaigns.
- AbuseIPDB: Community-reported abuse data with timestamps and reported abuse categories.
- Urlhaus: If the IP has hosted malware distribution URLs, they appear here with campaign context.
- MalwareBazaar: Search for malware samples that have communicated with the IP during sandbox execution.
The Hugging Face infrastructure compromise, where attackers used cheap persistence techniques to maintain access, is a useful reminder that threat intelligence cross-reference has to cover identity and token abuse patterns as well as network indicators. Investigating an IP that appears in authentication logs requires checking whether associated infrastructure has been linked to token theft campaigns, not just traditional malware distribution.
Sandbox and Malware Analysis Reports
Search ANY.RUN, Hybrid Analysis, and Joe Sandbox for reports that reference the IP. If the address appears as a C2 endpoint in sandbox detonations, you gain campaign context, malware family attribution, and sometimes indicators that link back to known threat actors. This is how analysts build attribution chains from a single suspicious address.
Layer Five: Social Context and Research Reporting
Open-source threat research is indexed and searchable. Threat actor infrastructure frequently appears in security blogs, academic papers, and conference presentations before it is formally indexed in commercial threat feeds.
Searching Research Publications
Query the IP address in quotes across the following sources:
- Google Search with site-specific operators targeting known threat research blogs (Recorded Future, Mandiant, Secureworks, Unit 42, ESET, Kaspersky ICS-CERT)
- GitHub, where researchers frequently publish indicators associated with malware campaigns
- Twitter/X, where the security research community shares fresh indicators, often hours before they reach formal feed systems
- Pastebin and similar paste sites, where threat actors sometimes inadvertently expose configuration data including C2 addresses
The APT group HoneyMyte's upgraded CoolClient backdoor, with its kernel-level rootkit component, appeared in research publications with associated network indicators before any commercial feed carried those indicators at scale. Analysts who searched research sources directly had that context earlier than those relying exclusively on feed-based detection.
Dark Web and Underground Forum Monitoring
For higher-tier investigations, searching dark web markets and cybercriminal forums for references to the IP or associated infrastructure can surface context that open-source research does not capture. This requires appropriate tooling and legal clearance depending on your organization's policies. The student loan data breach that exposed 2.5 million records, for example, was followed by rapid monetization activity where exfiltrated data appeared on forums alongside the infrastructure used for exfiltration. Correlating IP addresses with forum activity can connect infrastructure to specific campaigns or threat actors.
Building a Repeatable Workflow
Ad hoc investigation is the bottleneck. The difference between a fifteen-minute investigation and a ninety-minute one is usually whether the analyst has a defined sequence and pre-authenticated API access to the tools they need.
Tooling and Automation
Several open-source frameworks support structured IP investigation workflows:
- Maltego: Visual link analysis with transforms for WHOIS, passive DNS, Shodan, and threat feeds. Useful for visualizing infrastructure relationships across large investigations.
- SpiderFoot: Automated OSINT aggregation that can query dozens of sources in parallel and present results in a structured report.
- TheHarvester: Email and domain discovery that supplements IP investigation when you need to trace associated organizational infrastructure.
- MISP: For teams sharing indicators internally, MISP provides structured storage and correlation of investigation findings.
For SOC environments, enriching IP indicators automatically before they reach an analyst reduces investigation time significantly. SOAR playbooks that fire on IP-based alerts and pre-populate passive DNS, ASN data, and VirusTotal results give analysts a running start rather than a blank page.
Documentation and Knowledge Capture
Investigations that do not produce documented findings are investigations that have to be repeated. When an analyst completes an IP investigation, the output should include the ASN with abuse history notes, passive DNS findings with a time range, service fingerprint data from Shodan or Censys, threat feed cross-reference results, and any research publication links that reference the infrastructure. That documentation should be linked to the original alert in your ticketing system and tagged for correlation with future alerts involving the same ASN or certificate infrastructure.
Tradeoffs and Caveats to Build Into Your Practice
OSINT investigation produces probabilistic context, not binary verdicts. Several factors introduce uncertainty that analysts need to account for:
- Shared hosting creates false associations. An IP on a content delivery network or cloud provider may have hosted malicious content in the past without the current tenant having any connection to that history. Time-stamp every finding and weight recent activity more heavily.
- VPN and proxy exit nodes aggregate reputation. An IP that appears to belong to a VPN provider may carry abuse history from thousands of different users. Investigating VPN exit IPs requires confirming whether the infrastructure is shared before drawing conclusions about the specific connection you are investigating.
- Infrastructure reuse cuts both ways. Threat actors reuse infrastructure. But so do legitimate hosting customers who inherit IP blocks with existing abuse history. The presence of a threat feed hit is a starting point for investigation, not a conclusion.
- Data freshness degrades quickly. Passive DNS records that are six months old may no longer reflect current infrastructure use. Treat historical data as contextual evidence rather than current state confirmation.
What Good Investigation Looks Like in Practice
Returning to the financial services scenario at the start: a structured OSINT workflow applied to that 2:47 AM alert would have produced, within ten minutes, the ASN allocation history showing the bulletproof hosting association, passive DNS records linking the IP to domains used in prior APT campaigns, a Shodan fingerprint showing an open port consistent with a known C2 framework, and a research publication reference tying the infrastructure to a named threat actor. The analyst would have had enough context to escalate confidently rather than stalling on a clean reputation score.
That outcome requires preparation before the alert fires: pre-built queries, authenticated API access, documented sequences, and a team that practices the workflow regularly enough that the steps are automatic under pressure.
The threat landscape that produces campaigns like Kimwolf v7, Evooo1Bot, and Project CAV3RN is not going to simplify. Infrastructure is designed to look clean in single lookups and only reveal itself under multi-source investigation. Building that investigation capability into standard operating procedure is what separates teams that catch threats early from teams that find out they were inside the network for months.
