The Gap Between Knowing the Tools and Actually Getting Answers
Most cybersecurity professionals have run a WHOIS lookup. Most have queried VirusTotal, checked an IP against AbuseIPDB, and glanced at Shodan. The tools are well-known, widely documented, and easy to find. The problem is not access to tools. The problem is that experienced analysts hit a wall the moment a moderately sophisticated attacker starts using residential proxies, cloud relay infrastructure, or autonomous system hopping to obscure origin. That wall appears during live incidents, during threat hunting sessions, and increasingly during post-incident reviews when teams are trying to reconstruct attacker paths through logs they did not know were important at the time.
This article is for cybersecurity professionals and IT administrators who have already cleared the beginner threshold and want to sharpen their OSINT methodology for IP investigations that go deeper than surface-level lookups. The scenarios drawn from recent threat activity, including watering hole campaigns pushing keyloggers like ScanBox, multi-year cybercrime operations distributing malware through piracy sites, and the active exploitation of newly disclosed vulnerabilities like PAN-OS CVE-2026-0257, all share a common pattern: the IP addresses involved were not obviously malicious until someone pulled the right thread in the right order.
Why Standard Lookups Fail at the Midpoint of an Investigation
A clean reputation score on an IP address is not evidence of benign behavior. It is evidence that nobody has reported that address recently, or that the threat actor rotated to it recently enough to avoid accumulating abuse history. The watering hole campaigns pushing ScanBox keyloggers that have been identified in recent threat intelligence reporting relied heavily on infrastructure with minimal prior detection history. Attackers running long-term operations, like the cybercrime gang that has been using piracy sites to infect users for years, specifically select IPs with low reputation scores and rotate before those scores accumulate.
Standard lookups also fail to surface temporal context. An IP that shows clean today may have hosted malware payloads three months ago, been part of a botnet six months ago, or been used for command-and-control infrastructure that was active during the period you are investigating. Static reputation queries do not answer timeline questions, and timeline questions are often the ones that matter most during incident reconstruction.
The other failure mode is jurisdictional attribution confusion. Geolocation databases disagree with each other by meaningful margins, especially for cloud provider address space, anycast ranges, and CDN edge nodes. An analyst who trusts a single geolocation source during an investigation involving VPN infrastructure or residential proxy networks will routinely draw wrong conclusions about attacker location, impacting everything from escalation decisions to legal hold considerations.
Building a Structured OSINT Workflow: Today
The first thing to do today is establish a consistent intake sequence. Every IP investigation should start with the same ordered set of queries before any analyst starts forming hypotheses. This discipline prevents confirmation bias from pruning useful data branches early in the process.
Start with passive DNS resolution history. Tools like SecurityTrails, PassiveTotal (now part of Recorded Future), and CIRCL's passive DNS give you a historical picture of what hostnames have resolved to an IP over time. An IP that currently shows no associated domains may have hosted dozens of malicious domains six months ago. If those domains match known malware distribution patterns, that historical association is actionable even when current reputation tools show nothing. Recorded Future's recently launched Impact and Metrics Dashboard is worth examining specifically because it surfaces this kind of historical context in a way that connects IP-level data to campaign-level threat intelligence.
Follow passive DNS with ASN and routing context. Use tools like BGPView, RIPEstat, or Hurricane Electric's BGP toolkit to understand the autonomous system the IP belongs to, its upstream providers, and whether the ASN has a history of hosting malicious infrastructure. A cloud hosting provider that has been consistently abused by threat actors in your threat model is a different risk signal than an enterprise network IP from a well-known company. The routing history also tells you whether the IP has been re-announced recently, which can indicate deliberate infrastructure rotation.
Then run the IP against multiple geolocation sources simultaneously: MaxMind, ip-api, ipinfo.io, and DB-IP at minimum. Where these sources agree, you can have reasonable confidence. Where they disagree, treat the geolocation as uncertain and flag it explicitly in your investigation notes. This matters more than most teams realize during active incidents, because geolocation uncertainty affects the downstream decisions about blocking, escalation, and attribution.
Certificate and Banner Intelligence: What Passive Scans Actually Reveal
Shodan and Censys both expose TLS certificate data and service banners for IP addresses that have been scanned. This data is passive from your perspective, meaning you are querying a database rather than reaching out to the IP directly, which is important for operational security during active investigations.
TLS certificate history is particularly valuable. An IP that is currently presenting a generic or self-signed certificate may have previously presented a certificate with an organization name, email address, or subject alternative name that connects it to other infrastructure. Certificate transparency logs, queryable through tools like crt.sh, let you trace the relationships between certificates issued to the same organization or email address across many domains and IPs. This is how analysts have connected seemingly unrelated infrastructure used in multi-stage attack campaigns, including the kind of long-running operations that rely on periodic infrastructure refresh to stay below detection thresholds.
Service banners tell you what is running on the IP. An IP that presents an unusual combination of services, for example SSH on a non-standard port, an HTTP server with a specific default banner, and an open SMTP relay, may match a known malware implant profile or a specific threat actor's infrastructure fingerprint. Shodan's search syntax allows you to query for IPs matching banner patterns, which is useful for pivoting from a single suspicious IP to a cluster of related infrastructure.
The June 2026 Patch Tuesday cycle, described in recent reporting as record-breaking in scope, included vulnerabilities in services that are commonly exposed in cloud environments. Checking Shodan or Censys for whether a suspicious IP has any of those vulnerable services exposed adds a layer of context to your risk assessment of that IP, particularly if you are trying to determine whether an IP is infrastructure managed by a threat actor or a compromised victim host.
This Week: Pivoting From a Single IP to a Campaign Picture
Once you have baseline context on an IP, the next phase is pivoting. Pivoting means using attributes of the IP you are investigating to find related infrastructure, related actors, and related campaigns. The goal is to move from a single data point to a cluster of evidence.
Start with shared infrastructure pivots. If passive DNS shows the IP has hosted a specific domain, check whether that domain's registrar, registration email, or nameserver is shared with other domains. Tools like DomainTools Iris, WhoisXML API, and RiskIQ (now Microsoft Defender Threat Intelligence) make this pivot systematic. A registration email address used across dozens of domains is a high-value pivot point that can expose the full scope of an actor's operational infrastructure.
Look at SSL certificate pivots separately. If a suspicious IP has a certificate with a specific organization name or CN, search Censys or Shodan for all other IPs presenting the same certificate or certificates issued to the same organization. Threat actors running automated infrastructure deployment often reuse certificates across their fleet, which makes this pivot disproportionately productive compared to the effort involved.
Check the IP against threat intelligence platforms that track campaign attribution. VirusTotal's graph feature, AlienVault OTX, and Threat Fox all allow you to see whether an IP has been tagged in the context of specific malware families or threat actor profiles. The ScanBox keylogger campaign referenced in recent threat reporting, for instance, used infrastructure that left identifiable fingerprints in certificate and banner data that connected multiple delivery IPs to the same campaign cluster.
Open-source malware repositories like MalwareBazaar and Any.run sandbox reports sometimes include network indicators extracted from malware samples. Searching these repositories for an IP you are investigating can tell you whether the IP has been used as a C2 endpoint, a payload delivery server, or a data exfiltration destination in samples that other analysts have already processed.
Forum, Paste, and Dark Web OSINT: Using Surface-Layer Sources Effectively
A significant amount of IP-relevant threat intelligence surfaces in publicly accessible places that do not require specialized access. Analyst-accessible forums, paste sites, and code repositories leak infrastructure details more often than most teams realize.
GitHub is a consistent source of accidentally exposed infrastructure data. Developers building malware, testing exploits, or running automated attack tooling sometimes push configuration files that include hardcoded C2 IP addresses, API keys, or infrastructure descriptions. GitHub's code search allows you to search for a specific IP address across all public repositories, and results occasionally include direct evidence of how the IP was used operationally. The phpBB authentication bypass vulnerability that went unpatched for a decade, recently disclosed and fixed, was the kind of vulnerability that threat actors discuss and operationalize in forums where those conversations sometimes reference specific IP infrastructure.
Paste sites like Pastebin, Ghostbin, and similar services are frequently used to publish stolen credential dumps, tool configurations, and operational notes. Searching these sites for a specific IP address occasionally surfaces contextual information about how that IP fits into a broader operation. Tools like IntelligenceX and Dehashed aggregate paste site data in searchable form, reducing the manual effort involved.
Underground forum monitoring is more specialized, but for teams that have access to dark web intelligence feeds or have time to conduct manual collection, forum posts discussing specific exploitation campaigns frequently mention IP ranges, hosting providers, and tool configurations. The multi-year campaign distributing malware through piracy sites referenced in recent threat reporting involved infrastructure discussion in forums that predated its public exposure by months.
This Quarter: Building Repeatable Processes Instead of One-Off Investigations
Individual OSINT skills degrade quickly when they are not embedded in a repeatable workflow. The teams that consistently extract useful intelligence from IP investigations are the ones that have systematized their methodology, built tooling around it, and developed institutional knowledge about which sources matter most for the threat types they face most often.
Build an investigation playbook that defines exactly which queries run in which order, what constitutes a pivot trigger, what the escalation thresholds are, and how findings get documented. This playbook does not need to be a long document. It should be a structured checklist that an analyst can execute under time pressure without omitting steps. The wardriving assessment conducted across Mexico in preparation for the 2026 World Cup offers a useful parallel: systematic data collection against a defined scope, executed consistently across a large geographic area, produces intelligence that ad hoc collection cannot match. The same principle applies to IP investigation workflows.
Automate the intake layer. The first set of queries, passive DNS, ASN context, multi-source geolocation, and reputation checks, should not require manual browser queries. Tools like SpiderFoot, Maltego, and theHarvester can automate the collection of this data for a given IP and output it in a consistent format for analyst review. Building this automation means analysts spend their time on interpretation and pivoting rather than data gathering, which is where human judgment actually adds value.
Develop source-specific reliability assessments. Not every OSINT source performs equally well for every use case. Passive DNS sources differ in coverage depth and historical range. Geolocation providers differ in accuracy for cloud versus residential versus mobile IP space. Reputation databases differ in latency between an IP being used maliciously and that use being reflected in their scoring. Documenting these differences for your team, based on your experience with the types of IPs you actually investigate, builds institutional knowledge that improves the quality of every investigation over time.
Operational Security During Active IP Investigations
Querying a suspicious IP directly during an investigation can alert the operator of that IP that they are being investigated. This is a genuine risk when the IP belongs to a threat actor who has deployed logging or alerting on their infrastructure. For most commercial OSINT tools, queries are sent to the tool's infrastructure rather than directly to the target IP, which provides some insulation. But analysts need to understand which tools make direct connections and which do not.
Shodan and Censys query their own pre-collected scan data, so no direct connection to the target IP occurs. Passive DNS platforms query their own databases. WHOIS queries are technically visible to the registrar and sometimes the registrant. Any active scanning or direct HTTP/HTTPS connections to the target IP are fully visible to that IP's operator.
For investigations involving active threat actors, particularly those related to ongoing exploitation of vulnerabilities like PAN-OS CVE-2026-0257 where threat actors are operationally active and monitoring their infrastructure, passive-only collection is the appropriate discipline until there is a specific operational reason to make direct contact.
Connecting IP Intelligence to Broader Threat Context
An IP address in isolation is a weak intelligence product. The value of IP OSINT comes from connecting it to campaigns, actor profiles, and observable behaviors in your own environment. This means IP investigation findings need to feed into, and draw from, your broader threat intelligence capability.
When an IP appears in your logs in a way that warrants investigation, the question is not just what is this IP, but what is this IP doing in the context of the traffic pattern that triggered the alert. Is it scanning, delivering payloads, attempting authentication, exfiltrating data, or relaying traffic for another actor? The answer to that question shapes which OSINT sources are most relevant and which pivots are most productive.
Framing this context matters for teams operating under the same security pressures that the recent focus on framing protection security headers highlights: defenders need to understand not just what an attacker is doing, but what the attacker is trying to achieve architecturally. An IP that is part of a watering hole delivery chain has different operational characteristics than an IP used for C2 heartbeat traffic, and the OSINT investigation of each should be optimized for those different roles.
The teams that get the most out of IP OSINT are the ones that treat every investigation as a data collection opportunity for future investigations. Document your findings in a structured format. Tag IPs with the campaigns they were connected to, the pivot methods that were productive, and the sources that provided the most useful data. Over time, this documentation becomes a searchable institutional knowledge base that makes every future investigation faster and more accurate.
Practical Takeaways for the Next Investigation You Run
- Run passive DNS, ASN context, and multi-source geolocation as your first three queries for every IP, in that order, before forming any hypothesis about what the IP represents.
- Check TLS certificate history on Censys and Shodan, and use crt.sh to trace certificate relationships to connected infrastructure.
- Search GitHub's code search and paste site aggregators for the IP before concluding your open-source collection phase.
- Use pivot triggers: any domain, registration email, nameserver, certificate organization, or banner pattern that appears during your investigation should be queried in turn to find related infrastructure.
- Document your sources and confidence levels explicitly, especially for geolocation data, where source disagreement is common and consequential.
- Automate the intake layer so analysts start from a complete baseline data package rather than running manual queries from scratch.
- Maintain passive-only collection discipline when investigating infrastructure associated with active threat actors to avoid alerting them to your investigation.
