Overview

T1590.005 (IP Addresses) is a pre-compromise reconnaissance technique where adversaries systematically gather information about a target organization's IP address space. Attackers use this intelligence to map externally visible infrastructure, identify which IPs are live, infer organizational size and hosting providers, and discover attack surface before launching active operations.

Because this activity often happens entirely outside the defender's environment — through public registries, passive DNS datasets, and third-party tools — it is one of the hardest reconnaissance techniques to detect directly. Security teams that build indirect detection (outbound query anomalies, honeypot hits, threat intel correlation) can identify targeting activity early enough to harden exposed assets before an attack begins.

Attacker Perspective

Before touching a single packet of a target's network, adversaries build a complete map of the organization's IP footprint using entirely passive or semi-passive means available through public services and tooling.

• WHOIS and ARIN/RIPE enumeration: Attackers query regional internet registries using tools like whois 203.0.113.0/24 or the ARIN web API to retrieve netblocks assigned to the target org, revealing the full IP range the organization owns.
• Passive DNS and certificate transparency lookups: Tools like dnsdumpster.com, amass intel -org "TargetCorp", or subfinder correlate domain-to-IP history across passive DNS databases, exposing historically used IPs that may still host live services.
• Shodan and Censys mass enumeration: Attackers run queries such as org:"Target Corporation" on Shodan or Censys to retrieve banner data, open ports, TLS certificate subjects, and service fingerprints across every publicly indexed IP in the target's netblock — no packets sent to the target.
• BGP and ASN lookups: Using tools like bgp.he.net or whois -h whois.radb.net AS12345, adversaries identify all IP prefixes announced by the target's Autonomous System Number, providing a comprehensive and authoritative list of the organization's routable address space.

This technique is attractive because it is nearly costless, legally ambiguous, generates no alerts in the victim's environment when done passively, and provides high-value targeting intelligence that directly enables every subsequent phase of the attack lifecycle.

Detection Strategy

Required Telemetry

• DNS query logs (recursive resolver or firewall): Enable full outbound DNS query logging on your internal resolvers (e.g., Windows DNS debug logging via dnscmd /config /loglevel 0x6101 or Bind query logging). Capture queries to known recon service domains such as shodan.io, censys.io, dnsdumpster.com, bgp.he.net, viewdns.info, and WHOIS service endpoints. In Sentinel or Defender, enable DNS logs via the DNS connector. In Splunk, forward Windows DNS debug logs (default path: %SystemRoot%\System32\dns\dns.log) using the Universal Forwarder.
• Firewall and proxy egress logs: Ensure your perimeter firewall or next-gen proxy logs all outbound HTTP/HTTPS with full URL, source IP, destination IP, user-agent, and bytes transferred. In Palo Alto, enable URL filtering logs. In Zscaler or Squid, ensure category and full URL are captured. This catches HTTP API calls to WHOIS REST endpoints, Shodan API, and Censys API from internal hosts — which may indicate an insider conducting competitor/self recon or a compromised host being used as a pivot for attacker tooling.
• Web Application Firewall (WAF) and edge logs: Your own infrastructure's edge — CDN logs (Cloudflare, Akamai, AWS CloudFront), load balancer access logs, and WAF logs — will show enumeration attempts hitting your public IPs. Enable logging for all request types including HEAD and OPTIONS. Cloudflare provides Logpush; AWS ALB logs go to S3. These show when external actors are hitting your IP space with recon patterns.
• Cloud provider flow logs and network telemetry: Enable VPC Flow Logs (AWS), NSG Flow Logs (Azure), or VPC Flow Logs (GCP) on all public-facing subnets. These capture source IP, destination IP, port, protocol, and bytes for every connection attempt — including systematic sweeps across your IP ranges. Ingest these into your SIEM. For AWS, enable via aws ec2 create-flow-logs targeting all VPCs with an IAM role that has logs:CreateLogStream permissions.
• Threat intelligence feed integration: Integrate a CTI platform (MISP, OpenCTI, Recorded Future, or TAXII feeds) that enriches source IPs in your logs with known scanner identity. Shodan's crawler ranges, Censys probe IPs, and common recon tool exit nodes are published and should be imported as reference sets in your SIEM. In Sentinel, use the Threat Intelligence Platforms connector; in Splunk, use the threatintel lookup tables populated via a TI feed integration.
• Honeypot and canary IP telemetry: Deploy at least one or two unused IPs within your registered netblock as honeypots (using tools like Thinkst Canary, OpenCanary, or a simple logging listener). Any connection to an IP that has never been in DNS or announced as a service is definitionally suspicious and indicates external IP range enumeration. Configure alerts for any traffic hitting these dark IPs.
• Endpoint process and network telemetry (for internal recon detection): Enable Sysmon (Event ID 1 for process create, Event ID 3 for network connections, Event ID 22 for DNS queries) on all endpoints. Configure Sysmon using a community schema such as the SwiftOnSecurity template. This catches cases where an attacker with internal access uses recon tools from a compromised host. Audit policy for process creation: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1.

Key Indicators

• Internal host querying recon service domains: In DNS logs, look for query_name matching shodan.io, censys.io, dnsdumpster.com, bgp.he.net, whois.arin.net, whois.ripe.net, whois.radb.net, viewdns.info, hackertarget.com, spyse.com, or securitytrails.com. Flag any internal source IP making these queries that is not a known security research or threat intel workstation.
• HTTP API calls to enumeration services: In proxy/firewall logs, look for http.uri or cs-uri-stem containing patterns like /api/info/ on shodan.io, /v2/hosts/search on censys.io, or WHOIS REST API endpoints. Also flag user-agent strings associated with recon tools: python-requests, Go-http-client, amass, subfinder, theHarvester, or custom UA strings with no browser identifier.
• Process execution of recon tools on endpoints: In Sysmon Event ID 1 or Windows Security Event ID 4688, look for process_name matching amass.exe, subfinder.exe, nmap.exe, masscan.exe, or theharvester.py. On Linux via auditd, look for execve syscalls with argv containing whois, dig +noall +answer, nmap -sn, or amass intel. Command-line example to flag: amass intel -org "TargetCorp" -whois or whois -h whois.arin.net "n TargetCorp".
• Traffic to dark/honeypot IPs: In VPC flow logs or firewall logs, any dst_ip matching your honeypot IP inventory with action = ACCEPT or even action = REJECT is significant. The source IP conducting the sweep and the timing pattern (sequential IPs, consistent inter-packet timing) are the key fields.
• Sequential sweep patterns in edge/flow logs: In flow logs or WAF logs, look for a single src_ip making connections to multiple dst_ip values within your registered netblock in a short time window (e.g., more than 10 unique destination IPs within 60 seconds). The dst_port may be consistent (80, 443, 22) indicating service discovery following IP enumeration.
• Known scanner IPs hitting your perimeter: Correlate src_ip in WAF or edge logs against threat intel lists of Shodan crawler IPs (published at https://shodan.io/api/info), Censys probe IPs, or mass scanning organizations (Rapid7, Stretchoid). A hit from these IPs means your org is being indexed — useful for awareness even if not directly actionable as an incident.
• Certificate transparency and passive DNS service queries referencing your domains/IPs: If you have a CASB or proxy logging outbound HTTPS with SNI inspection, flag lookups to crt.sh, api.certspotter.com, or passivedns.circl.lu originating from internal hosts not associated with your security team.

Detection Logic

Rule 1 (Broad — High Sensitivity): Internal Host Querying Known IP Recon Services
IF dns.query_name IN ["shodan.io","censys.io","dnsdumpster.com","bgp.he.net","whois.arin.net","whois.ripe.net","viewdns.info","securitytrails.com","hackertarget.com"] AND src_ip IN [internal_ip_range] AND NOT src_ip IN [approved_security_workstations] THEN alert(severity=MEDIUM)

This catches any internal host performing lookups to IP intelligence services. Expected volume is low to moderate depending on org size — your own security team's threat intel workflows may trigger this, so baseline approved workstations and service accounts first. Any hit from a workstation or server outside that approved list warrants review.

Rule 2 (Moderate Precision): Recon Tool Process Execution with IP Enumeration Arguments
IF event_id IN [4688, 1] AND (process_name IN ["amass.exe","nmap.exe","masscan.exe","subfinder.exe"] OR command_line CONTAINS "whois" OR command_line CONTAINS "amass intel" OR command_line CONTAINS "-sn" OR command_line CONTAINS "bgp.he.net") AND NOT parent_process IN ["authorized_pentest_tools.exe"] AND NOT user IN [pentest_service_accounts] THEN alert(severity=HIGH)

This catches direct execution of IP enumeration tooling on endpoints. In most production environments this should have near-zero false positives outside of scheduled penetration tests. Alert volume should be very low — any hit outside a scheduled pentest window should be treated as high priority.

Rule 3 (Precision — Honeypot Hit): Traffic to Dark IP Space
IF dst_ip IN [honeypot_ip_list] AND src_ip NOT IN [internal_monitoring_systems] AND (action = "ALLOW" OR action = "REJECT") THEN alert(severity=HIGH)

This is a near-zero false positive rule. Any external IP connecting to or scanning an IP that has never been published in DNS or announced as a service is performing IP range enumeration. Alert volume should be extremely low; treat every hit as confirmed reconnaissance activity and escalate immediately.

Rule 4 (Precision — Sequential Sweep Detection): Single Source Hitting Multiple IPs in Your Netblock
IF src_ip = X AND dst_ip IN [your_registered_netblock] AND COUNT(DISTINCT dst_ip) > 10 WITHIN 60 seconds AND dst_port IN [22, 80, 443, 3389, 8080, 8443] AND NOT src_ip IN [internal_ip_range, approved_scanners] THEN alert(severity=HIGH)

This catches active scanning that follows IP enumeration — an attacker who has gathered your IP ranges now sweeping them for live hosts and open services. Tune the threshold based on your netblock size and expected legitimate traffic; CDN health checkers and legitimate monitoring services will need to be excluded by source IP.

Tuning Guidance

• Security team threat intel workflows: Analysts and threat intel teams legitimately query Shodan, Censys, WHOIS, and BGP services as part of their day job. Maintain an approved list of workstation IPs and user accounts, and exclude src_ip IN [security_team_workstations] or user IN [threat_intel_team_accounts] from DNS and proxy-based rules. Require the security team to document their tools so you can build exclusions correctly.
• Penetration testing and red team activity: Scheduled internal pentests will trigger every rule in this playbook. Implement a change management or pentest notification process. Exclude by time window (timestamp BETWEEN pentest_start AND pentest_end), source IP of pentest jump hosts, or dedicated pentest service account names. Require pentest teams to register source IPs in advance.
• CDN and infrastructure health checkers: Services like Cloudflare, Akamai, Pingdom, UptimeRobot, and AWS Route 53 health checks will connect to multiple IPs in your netblock from known source ranges. Import their published IP lists and exclude them from sweep detection rules: src_ip NOT IN [cloudflare_ranges, pingdom_ranges, aws_healthcheck_ranges].
• Legitimate WHOIS and BGP lookups from infrastructure tools: Network management platforms (SolarWinds, Infoblox, ManageEngine) and some SIEM enrichment pipelines automatically perform WHOIS/BGP lookups for IP enrichment. Identify these service account source IPs and exclude them: src_ip IN [nms_servers, siem_enrichment_hosts].
• Known internet-wide scanning organizations: Shodan, Censys, Rapid7 Project Sonar, and CAIDA routinely scan the entire internet. Their published IP ranges hitting your honeypot or edge logs are interesting for situational awareness but are not targeted reconnaissance against your organization. Create a separate lower-severity informational alert for these rather than a high-severity incident alert, and exclude them from sweep-count thresholds.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and pull the raw event. Navigate to the originating log source (DNS debug log, proxy log, flow log, or SIEM event) and confirm the raw event matches what the alert triggered on — check that the timestamp, source IP, destination, and query/URI fields are intact and not an artifact of parsing. Do not proceed on a SIEM-only view; always confirm the underlying raw log exists.
2. Identify the affected host and user account — flag if privileged. Resolve the source IP to a hostname using your CMDB or Active Directory, then identify the logged-in user at the time of the event using Windows Security Event ID 4624 (logon events) or your EDR's session data. If the host is a server, domain controller, or the user holds admin or privileged roles, escalate severity immediately.
3. Pull the full command-line and parent process chain for any endpoint activity. If an endpoint alert triggered, use your EDR (CrowdStrike, Defender for Endpoint, SentinelOne) or Sysmon Event ID 1 to retrieve the full CommandLine, ParentProcessName, ParentCommandLine, and User fields. A recon tool launched by cmd.exe → powershell.exe → amass.exe with no human-initiated parent is far more suspicious than a direct analyst execution; document the full chain.
4. Check for associated network connections and files written to disk. Query Sysmon Event ID 3 (network connections) and Event ID 11 (file created) for the same host and time window. Look for output files from recon tools (e.g., amass_output.txt, nmap_output.xml, results.json) written to temp directories, and any outbound connections to paste sites, cloud storage (S3, Dropbox), or C2 infrastructure that may indicate exfiltration of gathered IP data.
5. Check for lateral movement from the affected host. Query Windows Security Event ID 4624 (Type 3 network logons), Event ID 4648 (explicit credential use), and Sysmon Event ID 3 for outbound connections from the host to other internal IPs in the same time window. In your EDR, run a process tree query scoped to the host. Recon activity followed by lateral movement is a strong indicator of an active intrusion rather than a misuse or benign event.
6. Search for persistence mechanisms added around the time of the activity. Check Windows Security Event ID 4698 (scheduled task created), Event ID 4697 (service installed), Sysmon Event ID 13 (registry value set) targeting run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), and any new startup folder entries. On Linux, check /etc/cron.d/, ~/.bashrc, and /etc/systemd/system/ for modifications within the relevant time window using auditd logs or your EDR's file integrity data.
7. Make the escalation decision — confirmed incident versus benign. Treat the activity as a confirmed incident requiring escalation if any of the following are true: recon tooling was executed by a non-security account, persistence was found, lateral movement occurred, data was written to disk and connections to external IPs followed, or a honeypot IP was hit. Treat as likely benign (but document) if the source is a known security team workstation, the activity matches a scheduled pentest window, or the only indicator is a passive DNS query to a recon service with no follow-on process or network activity.

Response Playbook

Containment

• Isolate the affected host — leave it powered on for forensics. Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, SentinelOne Network Quarantine) to block all network traffic except the EDR management channel. Do not power off the system — volatile memory (running processes, network connections, encryption keys) is needed for forensics. Tag the host in your CMDB as under investigation.
• Disable the affected user account immediately if compromise is suspected. In Active Directory, use Disable-ADAccount -Identity [username] or the ADUC console. In Azure AD/Entra ID, disable via the portal or Update-MgUser -UserId [UPN] -AccountEnabled $false. If the account has MFA tokens or OAuth refresh tokens, revoke them: in Azure AD use Revoke-MgUserSignInSession -UserId [UPN].
• Block identified external IPs and domains at the perimeter. Push block rules to your perimeter firewall, web proxy, and DNS sinkholes for any external IPs or domains the host communicated with that are not accounted for by normal business activity. In Palo Alto, use Dynamic Address Groups or EDL feeds. In Zscaler, add to the custom URL category blocklist. At DNS, add NXDOMAIN overrides for identified C2 or data-exfiltration domains.
• Kill any identified malicious or unauthorized recon processes. If the EDR shows the process is still running, terminate it via the EDR console's remote process kill capability. Document the PID, process hash, and parent process before killing. Preserve any output files written to disk — do not delete them yet as they are evidence.
• Revoke active sessions and API keys associated with the compromised account. Check for active VPN sessions, remote desktop sessions (query with qwinsta /server:[hostname]), and cloud console sessions. Revoke any API keys or service account tokens the user or host had access to, particularly keys with access to cloud infrastructure or external-facing services that an attacker may have already copied.

Eradication

• Remove all identified persistence mechanisms. Delete unauthorized scheduled tasks using schtasks /delete /tn [taskname] /f, remove malicious registry run keys using reg delete [key_path] /v [value_name] /f, and disable or delete unauthorized services using sc delete [service_name]. On Linux, remove unauthorized cron entries, systemd unit files, and SSH authorized_keys modifications. Document each artifact removed.
• Locate and delete all dropped payloads, recon tools, and output files. Use your EDR's file search capability or Sysinternals Autoruns to find all files dropped during the incident. Hash every file before deletion and submit unknown hashes to VirusTotal or your internal sandbox. Pay particular attention to temp directories (%TEMP%, /tmp), user profile directories, and any directory the malicious process had write access to.
• Reset credentials for all accounts that executed malicious activity or were present on the host. Reset passwords for the affected user account and any service accounts with credentials stored on the host (check Credential Manager, browser stores, and application config files). Use Set-ADAccountPassword or your IAM platform's forced reset. Ensure the new password is generated randomly and not communicated over potentially compromised channels.
• Hunt for additional backdoors on all hosts the compromised account or host touched. Query your EDR and SIEM for any host where the compromised account authenticated (Event ID 4624) or the host made network connections within the incident window. Run the same persistence checks (scheduled tasks, registry run keys, new services, modified startup items) on each of those hosts. Expand scope if additional indicators are found.
• Rotate all secrets and API keys that may have been exposed. Inventory credentials accessible from the compromised host — this includes cloud IAM keys in environment variables or config files, application database passwords, SSH private keys in ~/.ssh/, and any secrets in tools like password managers or CI/CD pipelines the user had access to. Rotate all of them and audit their recent usage logs for unauthorized access.

Recovery

• Verify the host is clean before reconnecting — re-image if confidence is low. Run a full EDR scan, check all startup locations with Autoruns, and compare the host's running processes and file hashes against a known-good baseline. If any uncertainty remains about the completeness of eradication — particularly if the attacker had dwell time measured in hours or more — re-image from a clean gold image rather than attempting to clean the live system. A re-image is always safer than a partial cleanup.
• Re-enable the user account only after confirming no persistence remains on any affected host. Before re-enabling, confirm with the user that they did not initiate the suspicious activity (or, if insider threat is suspected, involve HR and Legal before any communication). Re-enable with Enable-ADAccount -Identity [username] and enforce a password reset at next logon. Brief the user on what was observed and what they should watch for.
• Monitor the affected host and user account intensively for 72 hours post-remediation. Create temporary high-sensitivity detection rules scoped to this host and user — alert on any process execution, network connection, or authentication event that falls outside their normal baseline. In your SIEM, add the host IP and username as watch-list entries with a 72-hour expiry. Check in daily with the EDR console for any new anomalies.
• Document the complete incident timeline and close with lessons learned. Write a structured incident report covering: initial detection timestamp, first evidence of attacker activity, full timeline of actions taken, IOCs discovered, systems affected, and remediation steps. Share the timeline with the broader security team in a lessons-learned session. File the incident in your case management system with all evidence preserved for potential legal or regulatory requirements.
• Update detection rules with any new IOCs and review coverage gaps exposed by this incident. Add newly discovered tool hashes, C2 IPs, domains, and behavioral patterns to your detection rules and threat intel feeds. Evaluate whether any gap in your detection logic allowed the activity to proceed further than it should have, and create a backlog item to address it. Consider whether additional honeypot IPs, expanded egress logging, or threat intel feed coverage would have detected the activity earlier.