The Assumption That Slows Every IP Investigation Down
Most security teams approach a suspicious IP the same way: run it through a reputation feed, check if it appears on a blocklist, maybe do a quick WHOIS lookup, and call it a verdict. That workflow produces a pass/fail answer when the actual goal is understanding context, intent, and infrastructure relationships. An IP address is not a conclusion. It is a starting point for a chain of evidence that frequently connects to threat actor patterns, shared hosting relationships, botnet infrastructure, and abused service providers that a single reputation check will never surface.
The teams that investigate IPs effectively treat each address as a node in a graph rather than a standalone indicator. The techniques described here are oriented toward cybersecurity professionals and IT administrators who need to move from a raw IP to actionable intelligence under realistic time constraints, without getting buried in tools that produce noise rather than answers.
Passive Reconnaissance Before You Touch the Target
The first principle of IP investigation is to gather as much as possible before generating any traffic toward the subject address. Active scanning tips off operators who monitor their infrastructure for reconnaissance, and sophisticated threat actors absolutely do this. Passive OSINT respects operational security while producing a surprisingly complete picture.
WHOIS and RDAP Data
Start with WHOIS and its modern replacement, RDAP (Registration Data Access Protocol). Both return registration information for IP blocks, including the registrant organization, abuse contact, registration and modification dates, and the assigned netblock. The critical habit here is recording the netblock, not just the individual IP. An IP registered to a known bulletproof hosting provider tells you something immediately. An IP inside a /24 where fifteen other addresses already appear in threat intelligence feeds tells you something more specific about infrastructure reuse.
RDAP queries can be made directly to regional internet registries: ARIN for North American resources, RIPE for European and Middle Eastern resources, APNIC for Asia-Pacific, LACNIC for Latin America, and AFRINIC for Africa. Tools like whois on Linux systems and web interfaces at each RIR handle this quickly. Note the ASN (Autonomous System Number) returned in every query because that number anchors the next phase of investigation.
ASN Context and Routing History
The ASN tells you which organization announces the IP prefix to the global routing table. BGP routing data, available through services like BGPView, Hurricane Electric's BGP Toolkit, and RIPE's RIS platform, shows you the current and historical routing state of that prefix. Threat actors frequently rotate IP allocations across ASNs, and routing history reveals those movements.
Comparing the ASN against known bulletproof hosting providers, residential proxy networks, and recently allocated blocks is a high-value step that most teams skip. The 911 S5 botnet, dismantled in 2024 but whose infrastructure relationships and affiliated IPs continue to appear in threat intelligence data today, operated heavily through residential proxy pools sourced from compromised endpoints across dozens of ASNs. Investigators who chased individual IPs without examining the ASN-level relationships repeatedly lost the thread. The ASN view surfaces provider-level patterns that individual IP lookups cannot.
Passive DNS: One of the Most Underused Tools in IP Investigation
Passive DNS databases record historical DNS resolution data, mapping which hostnames have resolved to which IP addresses over time. This is critical because malicious infrastructure frequently reuses IP space across multiple campaigns, and passive DNS exposes those connections without requiring any active interaction with the target.
Services like SecurityTrails, Farsight DNSDB, VirusTotal's passive DNS view, and RiskIQ (now Microsoft Defender Threat Intelligence) maintain large passive DNS corpora. Querying an IP in any of these platforms returns a timeline of hostnames that resolved to it. A single suspicious IP that served as a command-and-control node for a RAT campaign six months ago may currently host what appears to be a legitimate service. Passive DNS surfaces the full history.
The BTMOB Android RAT, which has been observed burrowing deep into Android devices in recent campaigns, relied on fast-flux DNS infrastructure where C2 hostnames rotated across a pool of IPs rapidly. Investigators who queried only current DNS resolution found single-hop dead ends. Those who pulled passive DNS history found the IP pool, then traced the registrant pattern across all of them. The difference in investigation depth came entirely from one additional data source.
Reverse DNS and PTR Records
PTR records for an IP sometimes reveal organizational context that WHOIS does not. Hosting providers assign PTR records based on customer naming conventions, and those conventions are often consistent enough to identify shared tenants. A PTR record formatted as static-203-0-113-45.malicious-hosting-provider.net tells a different story than one formatted as a corporate reverse DNS entry. When no PTR record exists, that absence is itself a signal worth documenting.
Certificate Transparency Logs
TLS certificates are logged publicly through the Certificate Transparency (CT) framework, and those logs are searchable by domain and IP. When an HTTPS service runs on a suspicious IP, the certificate it presents is almost certainly in the CT log. Querying platforms like crt.sh or Censys for certificates associated with an IP or its historically resolved hostnames frequently returns organizational names, email addresses used during certificate issuance, and related domains sharing the same certificate or issuer chain.
The DriveSurge campaign, which hijacked thousands of websites to deliver ClickFix and FakeUpdate attacks, used attacker-controlled infrastructure that appeared in CT logs months before researchers publicly documented the campaign. Certificates issued to domains that shared infrastructure with known malicious IPs were visible and queryable. Analysts running IP investigations on DriveSurge-adjacent infrastructure who pulled CT data found lateral connections to the broader campaign's hosting footprint that reputation feeds had not yet scored.
Shodan, Censys, and FOFA: Internet-Wide Scan Data
Passive internet scanning platforms index what services are listening on public IPs and what those services expose. Shodan, Censys, and FOFA each maintain massive databases of banner data, certificate information, open ports, and service fingerprints gathered through continuous scanning. Querying a suspicious IP in any of these platforms returns what was running on it at the time of the last scan without generating any traffic toward the target yourself.
Key things to examine in scan data include:
- Open ports and services: Unusual port combinations (for example, RDP on a non-standard port alongside an open SOCKS proxy) correlate with specific threat actor tooling and proxy resale infrastructure.
- Banner content: HTTP server headers, SSH banners, and SMTP banners contain version strings and configuration details that link infrastructure to specific campaigns or operators.
- Certificate subject data: Certificates presented by HTTPS services on the IP, which may differ from CT-logged certificates if self-signed certificates are in use.
- Historical records: Censys and Shodan both provide some historical scan data that shows what was running on the IP previously, extending the passive DNS timeline into service-level visibility.
In the context of the April 2026 CVE landscape, which has seen active exploitation of vulnerabilities in web-facing services and container environments, scan data frequently surfaces unpatched service versions before defenders have finished their patch cycles. An IP running a vulnerable version of a widely targeted service in a hosting block associated with known threat actors warrants significantly more investigation than a clean reputation score would suggest.
Threat Intelligence Platform Correlation
No single threat intelligence source covers the full scope of malicious IP activity. Effective IP investigation pulls from multiple feeds simultaneously and looks for overlapping indicators rather than treating any single verdict as authoritative.
VirusTotal
VirusTotal aggregates detections from dozens of security vendors and combines them with passive DNS, WHOIS data, and community-submitted context. The Relations tab for an IP shows linked domains, certificates, and files that communicated with it. This graph view is where investigations frequently branch into campaign-level intelligence rather than single-indicator analysis.
AlienVault OTX
AlienVault's Open Threat Exchange contains community-contributed pulses that tag IPs with campaign names, malware families, and TTPs. Cross-referencing an IP against OTX pulses provides context that automated reputation scoring does not capture, particularly for recent campaigns that have not yet propagated to commercial feeds.
AbuseIPDB
AbuseIPDB aggregates abuse reports submitted by network operators and security teams. The confidence score reflects how recently and how frequently the IP has been reported, and the report text sometimes includes the specific attack type (SSH brute force, web scanning, spam relay). For IPs involved in the Minecraft WeedHack campaign that infected over 116,000 systems, early abuse reports to AbuseIPDB preceded formal threat intelligence reporting by days, giving teams that regularly queried the platform advance warning.
Geolocation: What It Tells You and What It Does Not
IP geolocation databases map IP addresses to approximate geographic locations based on RIR data, BGP routing, and probe-based measurement. The resolution is reliable at the country level for most IP space and reasonable at the city level for statically allocated commercial IP blocks. It degrades significantly for residential IP space, cloud provider allocations, and any IP associated with VPN services or proxy networks.
The practical implication for investigators is that geolocation confirms ISP and country-level assignment with reasonable confidence but should not be used as evidence of attacker location. Threat actors operating through residential proxy pools, compromised endpoints, and bulletproof hosting services deliberately use IP addresses whose geolocation points away from their actual origin. Campaigns attributed to groups tracked in the ESET APT Activity Report for Q4 2025 through Q1 2026 consistently used infrastructure geolocated in multiple countries simultaneously to frustrate attribution and evade geo-based filtering policies.
Use geolocation as a triage signal and a network policy input, not as a forensic conclusion about attacker origin.
Pivoting Through Infrastructure Relationships
The most productive IP investigations move laterally through infrastructure relationships rather than staying focused on the original indicator. Several pivot paths consistently produce high-value findings:
- Same netblock, different IPs: When an IP is confirmed malicious, scan passive DNS and Shodan data for other IPs in the same /24 or /16. Threat actors frequently allocate multiple IPs from the same provider for redundancy and rotation.
- Shared SSL certificates: If the IP presented a certificate with a specific subject CN or organizational name, search CT logs for other certificates with the same attributes. Operators who reuse certificate configurations across infrastructure expose their full IP pool through this pivot.
- Registrant email address: When WHOIS data for associated domains includes a registrant email, searching that email across domain registrar databases and OSINT sources like DomainTools frequently surfaces the full domain portfolio associated with that operator.
- ASN peer relationships: BGP peering data shows which networks route traffic on behalf of a suspicious ASN. For bulletproof hosting providers that operate through upstream transit providers, those transit relationships identify organizations that can receive abuse reports and act on them.
- Malware sample submissions: Services like MalwareBazaar and VirusTotal Files allow searching for samples that contacted a specific IP or domain. Finding the malware family that used an IP as a C2 endpoint frequently produces YARA rules, behavioral signatures, and additional IOCs that accelerate investigation.
Operational Context: Cloud, Hosting, and VPN Classification
Before escalating an IP investigation into a blocking or reporting action, classify the IP's operational role. Several categories require different response approaches:
Cloud provider IP space: IPs allocated to AWS, Azure, Google Cloud, and similar providers are used by millions of legitimate customers. A malicious IP in AWS space warrants an abuse report to AWS Security rather than a blanket block of the prefix. Blocking the entire AWS prefix range to address one malicious IP creates operational disruption disproportionate to the threat.
CDN and reverse proxy IPs: Content delivery networks and reverse proxies sit in front of many origin servers. An IP associated with Cloudflare, Fastly, or Akamai may be the CDN edge node for a malicious site rather than the origin. Investigation should pivot to the hostname and then to the origin server behind the CDN.
Residential proxy networks: IPs in residential ranges that appear in proxy service databases represent a distinct threat category. The machine at that IP is frequently an unwitting participant: a compromised home router or an endpoint enrolled in a proxy service through deceptive software. The 911 S5 botnet's digital legacy continues to influence how security teams think about residential proxy infrastructure, where millions of compromised endpoints provided IP addresses that appeared entirely legitimate to reputation-based defenses.
Tor exit nodes: Exit node lists are publicly maintained and updated. Tor exit node traffic should be evaluated in context rather than treated as uniformly malicious, but the exit node classification changes the investigation priority and the type of threat most likely to use that path.
Documenting the Investigation for Operational Use
IP investigation findings lose most of their value when they are not documented in a way that can be acted on by other team members, integrated into detection rules, or recalled during a future incident. A minimal but effective documentation structure for each IP investigation includes:
- The original indicator and the alert or log source that surfaced it
- ASN, netblock, and registrant from WHOIS/RDAP
- Passive DNS findings with a timeline of associated hostnames
- Certificate data and any CT-derived relationships
- Scan data findings from Shodan or Censys
- Threat intelligence verdicts from each feed queried, with timestamps
- Geolocation classification and its confidence level
- Infrastructure pivot findings and any related IPs or domains surfaced
- Recommended action: block, monitor, report to provider, or escalate
This documentation creates a repeatable audit trail and builds institutional knowledge about threat actor infrastructure patterns that speeds up future investigations.
Automating the Repeatable Steps
Manual execution of the workflow above for every suspicious IP is not sustainable at scale. The repeatable steps, WHOIS queries, passive DNS lookups, threat intelligence feed queries, and Shodan checks, can be automated through APIs and orchestration tools. Platforms like TheHive with Cortex analyzers, MISP with feed integration, and custom Python scripts using the requests library against public APIs handle the bulk data gathering automatically and surface results for human review.
The critical discipline is keeping human judgment in the loop for the pivoting and context interpretation steps. Automated enrichment produces data. The pivot decision, recognizing that two IPs sharing a certificate subject means they belong to the same threat actor's infrastructure, requires an analyst who understands what they are looking at. Automation handles volume. Analysts handle insight.
Tying It to Current Threat Context
Effective IP investigation does not happen in isolation from the current threat landscape. The April 2026 CVE landscape includes active exploitation of vulnerabilities in container environments, WordPress plugins including the critical Kirki flaw being used to hijack admin accounts, and web-facing services broadly. IPs associated with scanning activity against these specific vulnerability classes deserve elevated priority during investigation because they indicate operators actively working current exploitation chains rather than running generic noise.
Similarly, the ESET APT Activity Report for Q4 2025 through Q1 2026 documents specific infrastructure patterns used by tracked threat groups, including IP ranges and hosting providers that appear repeatedly across campaigns. Cross-referencing a suspicious IP against the infrastructure patterns described in that reporting, and in similar vendor reports, connects individual indicators to tracked threat actor activity at a level that changes both the response priority and the appropriate escalation path.
IP investigation is most valuable when it is practiced as a disciplined, layered process rather than a quick reputation check. The tools and techniques here are available to any security team willing to build the workflow and practice it consistently. The teams that investigate effectively are the ones that treat every IP as a thread worth pulling, at least far enough to understand what it connects to.
