When the Alert Gives You an IP and Nothing Else
A mid-sized financial services firm received an alert from their SIEM at 2:14 AM. A single IPv4 address had authenticated successfully to their VPN endpoint using valid credentials, then immediately began scanning internal RFC1918 ranges. The credentials belonged to a finance analyst who was, at that moment, asleep in Ohio. The IP address was the only artifact the security team had to work with.
What happened next determined whether the investigation took four hours or four days. The analyst on call ran the address through a single threat intel feed, got a clean result, and escalated it as a low-priority anomaly. By morning, the attacker had mapped three internal subnets and staged a lateral movement attempt toward the payroll system. The feed the analyst used had a 72-hour ingestion lag. The IP had been flagged as part of a credential stuffing campaign 48 hours earlier on two separate community platforms the team never monitored.
This scenario plays out constantly. The problem is not a lack of OSINT tools. The problem is investigators treating IP investigation as a single lookup rather than a structured workflow that layers multiple data sources, each contributing a different type of context.
Understanding What an IP Address Actually Tells You
An IP address is a routing identifier, not an identity. Before any lookup, investigators need to internalize what an IP can and cannot establish. It can indicate the network infrastructure used at a point in time. It can surface registration data, routing context, and historical behavior patterns. It cannot confirm the identity of the actor behind it, and in 2026, an increasingly high proportion of threat actor traffic routes through residential proxies, compromised cloud instances, or anonymization networks that deliberately poison geolocation inference.
The Head Mare APT group, which recently exploited vulnerabilities in unpatched TrueConf servers to deliver PhantomCore and PhantomGraph malware to video conference participants, is a clear example. Attribution attempts based solely on originating IPs failed early in that campaign because the group rotated through infrastructure hosted across multiple cloud providers in regions inconsistent with their actual operational base. Investigators who anchored their analysis to the first-hop IP lost the thread entirely.
Effective IP investigation starts by asking the right questions: Who registered the IP block? What autonomous system carries it? What has this address done recently, and on which networks? What services does it currently expose? Has it appeared in passive DNS, honeypot captures, or abuse databases? Each of these questions points to a different data source, and each data source has specific blind spots.
Registration and Routing Context as the First Layer
The Regional Internet Registry (RIR) databases are the logical starting point. ARIN covers North American address space, RIPE NCC covers Europe and the Middle East, APNIC covers Asia-Pacific, LACNIC covers Latin America, and AFRINIC covers Africa. A WHOIS query against the appropriate RIR returns the organization that holds the allocation, the abuse contact, and often the registration date of the block.
Investigators frequently skip this step because they assume it returns nothing useful for cloud-hosted or VPN-exited traffic. That assumption is incorrect. Even if the address belongs to a major cloud provider, the WHOIS record establishes the provider, which narrows down the subset of abuse reporting channels and often reveals whether the address sits in a range associated with consumer services, enterprise leasing, or datacenter hosting. Those distinctions matter for understanding the likely threat profile.
Autonomous System Number (ASN) lookup is the next step. Tools like Team Cymru's IP-to-ASN mapping, BGPView, or Hurricane Electric's BGP toolkit surface the AS name, the upstream providers, and the prefix the IP belongs to. A residential ISP ASN suggests different threat actor behavior than an ASN belonging to a bulletproof hosting provider. When the Gunra ransomware gang was exploiting Fortinet flaws and bypassing MFA earlier this year, their initial access infrastructure showed a consistent pattern of ASNs associated with offshore bulletproof hosts. Investigators who checked ASN reputation early in those incidents were able to pivot to other IPs in the same prefixes and find additional compromise indicators.
Passive DNS Reconstruction
Passive DNS (pDNS) databases record historical DNS resolutions. When a domain pointed to an IP, and when that mapping changed, becomes queryable through services like Farsight DNSDB, VirusTotal's passive DNS, SecurityTrails, or RiskIQ (now part of Microsoft Defender Threat Intelligence). For IP investigation, pDNS answers the question: what domains have resolved to this address over time?
This matters because attackers frequently reuse infrastructure. A phishing domain that rotated off an IP three weeks ago may share the same hosting history with a command-and-control domain that is active today. Running a pDNS lookup against the suspicious IP from the financial services scenario might surface five domains, two of which share registration patterns with known credential harvesting infrastructure. That connection would never appear in a reputation feed lookup.
When reading pDNS data, investigators should note the density of domains per IP (high counts often indicate bulletproof hosting or shared infrastructure), the registration age of resolved domains (newly registered domains pointing to an IP are a meaningful signal), and the timing gaps between resolutions (a gap that aligns with a known incident suggests infrastructure reuse after a brief cool-off period).
Investigators should also cross-reference pDNS findings against certificate transparency logs. Tools like crt.sh allow querying for SSL/TLS certificates issued for domains, and certificates often contain Subject Alternative Names (SANs) that cluster related domains together. An IP that hosts a domain with a certificate covering 12 subdomains gives you 12 additional investigative threads.
Active Reconnaissance Against the IP Itself
Passive data sources tell you what an IP has done. Active reconnaissance tells you what it is doing right now. Shodan, Censys, and FOFA index internet-facing services by scanning the entire IPv4 space continuously. A Shodan query against a suspicious IP returns open ports, banner information, SSL certificate details, and often the software version running on exposed services.
This layer of investigation is where investigators frequently find attribution anchors that reputation feeds miss entirely. An IP running an unusual combination of services, such as a non-standard SSH port alongside a specific version of a web framework, may match a fingerprint associated with known malicious tooling. The DeadLock ransomware group, which uses blockchain-based infrastructure to resist takedowns, leaves consistent fingerprints in their C2 panels that Shodan indexes reliably. Investigators who know the panel signatures can identify DeadLock infrastructure before it appears in any threat feed.
When running active queries against Shodan or Censys, the practical steps are:
- Query the IP directly for current port and service exposure
- Review the historical scan data for the same IP to detect infrastructure changes over time
- Extract SSL certificate serial numbers or fingerprints and use them as pivots to find other IPs using the same certificate
- Note HTTP response headers, favicon hashes, and HTML title tags, all of which can be used as search terms to find related infrastructure
Favicon hash searching deserves specific attention. Shodan supports querying by favicon hashes using the http.favicon.hash filter. Many attacker-controlled panels use default or slightly modified favicons that produce consistent hashes across their deployed instances. A favicon hash that appears on 40 IPs globally, and where your suspicious address is one of them, significantly changes the scope of what you are investigating.
Threat Intelligence and Abuse Feed Cross-Referencing
Reputation feeds are a necessary part of IP investigation but a deeply insufficient one when used in isolation. The financial services failure described at the start of this article illustrates why: a clean result from one feed means only that the feed has no record of this IP within its ingestion window. It says nothing about what other sources know.
The practical approach is to query multiple sources simultaneously and treat disagreement between sources as a signal worth investigating rather than noise to discard. Sources worth querying in sequence include:
- AbuseIPDB: Community-contributed abuse reports with timestamps, allowing investigators to assess recency and report volume
- VirusTotal: Aggregates results from dozens of detection engines and threat intel vendors, with URL and file associations
- IBM X-Force Exchange: Provides risk scoring alongside associated malware families and attack categories
- AlienVault OTX: Community pulse data that often surfaces emerging campaigns faster than commercial feeds
- Spamhaus: Particularly relevant for IPs associated with botnet infrastructure, spam operations, or SBL-listed ranges
- CINS Army list and Emerging Threats blocklists: Useful for identifying IPs currently active in scanning or attack campaigns
When an IP appears clean across commercial feeds but shows recent reports on community platforms like AbuseIPDB or OTX, the likely explanation is a lag in ingestion pipelines. Community platforms receive direct submissions from network operators and often reflect current abuse faster than curated commercial feeds. The inverse is also true: community platforms sometimes carry stale or inaccurate data, so corroboration across multiple sources before acting on a finding is standard practice.
Behavioral Context From Honeypot and Sensor Networks
Honeypot data gives IP investigation a behavioral dimension that registration records and reputation scores cannot provide. If an IP has interacted with honeypot infrastructure, the capture typically includes the protocol used, the payload sent, and the timing of the probe. This tells investigators something about intent and tooling rather than just identity.
The Threat Intelligence Report from July 27th of this year noted a surge in scanning activity targeting exposed management interfaces on network devices, with a consistent subset of source IPs appearing in honeypot captures across multiple independent sensor networks before appearing in any commercial feed. Investigators with access to honeypot-derived data through platforms like GreyNoise, Shodan's exposure data, or internal honeypot deployments had a lead time of 18 to 36 hours over teams relying exclusively on commercial threat feeds.
GreyNoise specifically classifies IPs as benign scanners (such as search engine crawlers and security researchers), malicious, or unknown based on behavioral analysis across its global sensor network. An IP that GreyNoise classifies as actively scanning for specific vulnerability fingerprints tells a very different story than one classified as benign background noise, even if both appear clean in a standard reputation check.
Pivoting Through Associated Infrastructure
The most productive phase of IP investigation often begins once you have a confirmed finding and start pivoting. Pivoting means using one attribute of the suspicious IP to find related infrastructure that shares that attribute. Common pivot points include:
SSL certificate fingerprints: Extract the certificate from the IP's open HTTPS port and search for other IPs or domains serving the same certificate. This technique regularly surfaces entire C2 infrastructure clusters in a single query.
ASN prefix enumeration: If the IP belongs to a prefix with a specific abuse history, enumerate the surrounding /24 or /22 and query those ranges against your behavioral data sources. Attackers who use dedicated abuse-friendly hosting frequently operate multiple IPs within contiguous ranges.
Registrant email or organization name: WHOIS data sometimes contains registrant contact information. Even where privacy protection is applied, the registrar and registration date can be used to find other domains registered through the same registrar in the same time window, which is a common signature of bulk infrastructure provisioning.
JA3 or JA4 TLS fingerprints: If you have packet capture data, TLS client fingerprints identify specific SSL library implementations. Malware families often produce consistent fingerprints that match observed fingerprints from other known-bad infrastructure. Network detection tools that log JA3/JA4 fingerprints make this pivot searchable within your own telemetry.
HTTP response fingerprinting: Web servers return headers, error pages, and response codes that can be fingerprinted. Tools like HTTPX or direct queries through Censys allow searching for IPs returning specific HTTP response patterns, which can cluster attacker infrastructure that uses the same panel software or default configuration.
Documenting the Investigation Chain
OSINT investigation without documentation is reconnaissance that expires. The value of IP investigation compounds over time only when findings are recorded in a way that allows future investigators to pick up the thread, extend the pivot chain, or recognize when the same infrastructure resurfaces under a different address.
Effective documentation for IP investigation includes:
- The original alert or investigative trigger with timestamp
- Each data source queried, the query used, and the result returned (including null results, which establish that a source was checked)
- The pivot logic used at each step: what attribute was extracted, what query was built from it, and what new IPs or domains resulted
- Confidence assessments for each finding, noting the source type and recency of the underlying data
- A summary of infrastructure relationships that can be converted into detection rules or blocklist entries
Graph-based visualization tools like Maltego, SpiderFoot, or even a well-structured draw.io diagram significantly improve the usability of documented findings when the pivot chain involves more than a handful of related nodes. The visual representation of infrastructure relationships has practical value during incident response briefings and when handing off investigations between shifts.
Translating Findings Into Defensive Action
An OSINT investigation that produces a detailed picture of attacker infrastructure has no operational value unless the findings drive concrete defensive changes. The translation from investigative context to defensive action involves several steps that security teams regularly skip under time pressure.
First, determine whether the suspicious IP represents isolated activity or part of a campaign using shared infrastructure. If the pivot chain revealed 15 related IPs across three ASNs, blocking the original address while ignoring the other 14 addresses the attacker will cycle through immediately leaves the door open.
Second, assess the confidence level of each finding before converting it into a block rule. An IP confirmed across five independent sources, with recent behavioral data from honeypot captures and an active pDNS record to a known malicious domain, warrants a hard block. An IP that appeared in one community abuse report six months ago and shows no other signals warrants a monitor-and-alert posture rather than immediate blocking.
Third, consider the false positive risk for each address in your specific environment. A cloud provider IP range that serves as a known egress point for legitimate SaaS tools your organization uses requires a more nuanced response than a dedicated server in a bulletproof hosting ASN. Microsoft's recent release of KB5120249 as an extended security update for Windows 10 environments, combined with the announcement of nearly 400 patched security vulnerabilities in a recent Patch Tuesday cycle, underscores that attackers actively hunt for freshly disclosed vulnerabilities from cloud-adjacent infrastructure. Blocking cloud provider ranges without accounting for legitimate dependencies will generate alert fatigue faster than the threat itself.
Fourth, feed confirmed findings back into your detection infrastructure. New IPs, domains, certificate fingerprints, and HTTP response patterns discovered during the investigation should become detection signatures. The investigation that starts with one suspicious address and ends with a confirmed C2 cluster should produce a corresponding set of indicators that your IDS, SIEM, and DNS filtering infrastructure can act on immediately.
Workflow Automation Without Losing Analytical Judgment
The volume of IP-related alerts in a mature SOC environment makes fully manual OSINT workflows impractical at scale. Automation is appropriate for the data collection phases: querying WHOIS, running ASN lookups, pulling pDNS records, and cross-referencing reputation sources can all be scripted or handled through SOAR playbooks. Tools like TheHive with Cortex analyzers, or custom Python scripts using libraries like ipwhois, shodan, and dnspython, can assemble the raw data layer within seconds of an alert firing.
The analytical judgment layer should remain with a human investigator. Determining whether the pattern of findings constitutes genuine threat infrastructure, assessing the confidence level of pivot relationships, and deciding on the appropriate defensive response all require contextual reasoning that automated scoring systems regularly get wrong under novel conditions. The Hugging Face incident earlier this year, while primarily focused on AI model security, illustrated a broader lesson about over-reliance on automated classification systems: when the training data does not reflect current attacker behavior, automated assessments drift from reality faster than teams notice.
The practical architecture is automated collection feeding into a structured analysis interface where investigators see pre-populated findings and can focus their time on interpretation and pivot decisions rather than running the same seven lookups manually for every alert.
Building the Habit Before the Incident Demands It
IP investigation skills atrophy without regular practice. Security teams that only run OSINT workflows during active incidents operate under the worst possible conditions: time pressure, incomplete context, and unfamiliarity with the nuances of tools they use infrequently.
Running investigative exercises against historical IPs from past incidents, ingesting threat intelligence reports and practicing the pivot workflows they imply, and maintaining up-to-date access credentials for the data sources described in this article all contribute to operational readiness that shows up measurably when a real incident fires.
The analyst who got it wrong at 2:14 AM in the scenario that opened this article was not incompetent. They were undertrained on a workflow that their organization had never made a priority. The attacker who authenticated with stolen credentials and started scanning internal ranges had almost certainly practiced their tradecraft extensively. The asymmetry between attacker preparation and defender preparation is a choice, and IP investigation methodology is one of the places where that choice is made in the quiet periods between incidents.
