Overview

Network Topology reconnaissance (T1590.004) is a pre-compromise technique where adversaries map out the physical and logical structure of a target's network — identifying routers, gateways, firewalls, subnets, and exposed services — before launching any active attack. The goal is to understand the attack surface: which systems are internet-facing, how internal segments are connected, and where high-value targets like domain controllers or OT systems might live.

Because this activity often occurs entirely outside the defender's perimeter — using passive OSINT, third-party data sources, or subtle active probing — it is one of the hardest reconnaissance techniques to detect. Teams that miss this phase lose the opportunity to identify threat actors early, before they have gained any foothold, making detection here one of the highest-value investments in your detection program.

Attacker Perspective

Before launching any attack, a skilled adversary will invest significant effort in understanding how a target network is structured so they can plan an approach with the lowest risk of detection and the highest probability of success.

• Passive DNS and BGP enumeration: Attackers use tools like dnsdumpster.com, Shodan, and BGPView to enumerate ASNs, IP ranges, and subdomains — all without sending a single packet to the target, making it completely invisible to the victim's sensors.
• Active traceroute and hop analysis: Tools like traceroute, tcptraceroute, and Nmap --traceroute reveal network path topology, including firewall and load balancer positions, by analyzing TTL-expired ICMP responses from intermediate hops.
• Certificate and TLS metadata harvesting: Attackers query certificate transparency logs via crt.sh or tools like amass to discover internal hostnames, subdomains, and infrastructure naming conventions leaked through TLS certificates.
• Exposed network diagrams and documentation: Job postings, vendor case studies, GitHub repositories, and misconfigured web servers sometimes expose Visio diagrams, Ansible inventory files, or Terraform state files that directly reveal network topology with zero active probing required.

This technique is attractive to attackers precisely because most of it generates no logs inside the victim environment — it is low-risk, low-noise, and directly enables higher-confidence targeting of every subsequent attack phase.

Detection Strategy

Required Telemetry

• DNS query logs (recursive resolver): Enable query logging on your internal DNS servers (Windows DNS debug logging: dnscmd /config /logLevel 0x8100, or enable via DNS Manager → Debug Logging). For cloud DNS, enable query logs in Route53, Azure DNS, or Google Cloud DNS. These logs should capture every outbound DNS lookup including reverse lookups (PTR records) and zone transfer attempts (AXFR/IXFR).
• Firewall and perimeter device logs: Ensure your edge firewall (Palo Alto, Fortinet, Cisco ASA, AWS Security Groups) logs all inbound connection attempts — especially ICMP, UDP, and short-lived TCP sessions that may represent probing. Enable denied traffic logging in addition to allowed traffic. Export to your SIEM via syslog or native connector.
• Network flow data (NetFlow/IPFIX/sFlow): Configure your routers and switches to export flow telemetry to a flow collector (e.g., ntopng, Elastic with flow integration, or your SIEM's flow ingestion). Flow data captures source/destination IP, port, protocol, byte counts, and duration — critical for detecting sweep patterns.
• Web server and load balancer access logs: Collect access logs from internet-facing web servers (Apache, Nginx, IIS) and load balancers (F5, AWS ALB). These logs capture User-Agent strings, source IPs, and URL paths — useful for spotting automated reconnaissance tools hitting non-standard paths.
• Endpoint process execution logs (Windows): Enable the following audit policies via GPO or directly in the registry:
  • Process Creation auditing: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success — generates Event ID 4688.
  • Command-line logging in process creation: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1 — adds full command-line to Event ID 4688.
  • PowerShell Script Block Logging: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1 — generates Event ID 4104.
  • PowerShell Module Logging: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1 — generates Event ID 4103.
• Linux/macOS endpoint audit logs: Deploy auditd with rules targeting network reconnaissance commands. Add the following to /etc/audit/rules.d/recon.rules:
  • -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/traceroute -k net_recon
  • -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/nmap -k net_recon
  • -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/dig -k net_recon
  • -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/host -k net_recon

  Alternatively, deploy Sysmon for Linux or Auditbeat to forward structured events to your SIEM.

• Cloud provider audit logs: Enable AWS CloudTrail (focus on DescribeVpcs, DescribeSubnets, DescribeRouteTables, DescribeNetworkInterfaces), Azure Activity Log (focus on Microsoft.Network/virtualNetworks/read, Microsoft.Network/routeTables/read), and GCP Cloud Audit Logs (compute.networks.list, compute.routes.list). These API calls are the cloud-native equivalent of network topology mapping.
• Threat intelligence / external honeypot signals: If your organization runs internet-facing honeypots or subscribes to an ASN monitoring service (e.g., GreyNoise, Censys, Shodan Alerts for your own IP ranges), configure alerts for scanning activity targeting your registered IP space — this catches passive and active reconnaissance before it reaches production systems.

Key Indicators

• DNS zone transfer attempts: In DNS server logs, look for query_type = AXFR or query_type = IXFR from source IPs that are not authorized secondary DNS servers. Field: dns.question.type = AXFR.
• High-volume PTR (reverse DNS) lookups: A single source IP issuing hundreds of PTR lookups against your IP ranges within a short window is a strong indicator of automated topology mapping. Field: dns.question.type = PTR, threshold: more than 50 unique PTR queries in 5 minutes from one source.
• ICMP TTL-exceeded responses (traceroute behavior) at the perimeter: In firewall logs, look for outbound protocol = ICMP with icmp_type = 11 (Time Exceeded) in response to inbound probes — this reveals that external systems are performing traceroute through your network boundary. Field: icmp.type = 11.
• Sequential IP sweep (ping sweep or port sweep): In flow data, look for a single source IP connecting to more than 20 distinct destination IPs within your registered ranges within 60 seconds, each with session duration under 2 seconds. Fields: src_ip, dst_ip count distinct, flow_duration.
• Nmap or scanning tool signatures in web logs: Web access logs showing User-Agent strings matching known scanners: user_agent CONTAINS "Nmap Scripting Engine", "masscan", "zgrab", "shodan", or "censys". Field: http.request.headers.user_agent.
• Suspicious process execution on endpoints (Windows Event ID 4688): Look for processes like nmap.exe, tracert.exe, pathping.exe, route.exe print, netsh.exe interface, or arp.exe -a launched by unusual parent processes (e.g., cmd.exe spawned by outlook.exe or powershell.exe spawned by winword.exe). Fields: process.name, process.command_line, process.parent.name.
• PowerShell network discovery commands (Event ID 4104): Script block logging revealing commands such as Test-NetConnection, Resolve-DnsName, Get-NetRoute, Get-NetIPConfiguration, Get-NetAdapter, or calls to tracert via Invoke-Expression. Field: powershell.scriptblock.text.
• Cloud API calls enumerating network resources: In CloudTrail logs, a single IAM principal calling ec2:DescribeVpcs, ec2:DescribeSubnets, and ec2:DescribeRouteTables in rapid succession (within 60 seconds) from an unusual source IP or at an unusual time. Fields: eventName, userIdentity.arn, sourceIPAddress.
• Shodan/Censys scan hits on your IP space: GreyNoise or your threat intel feed flagging source IPs as known scanners that are hitting your perimeter. Cross-reference these IPs against firewall denied logs to confirm contact.

Detection Logic

Rule 1 — Broad: External IP Performing High-Volume DNS Lookups Against Internal Ranges
IF dns.question.type IN ["PTR", "AXFR", "IXFR"] AND src_ip NOT IN [authorized_secondary_dns_servers] AND COUNT(DISTINCT dns.question.name) > 50 WITHIN 5 MINUTES GROUP BY src_ip THEN alert(severity=MEDIUM)

This catches automated DNS enumeration tools (dnsdumpster, fierce, dnsrecon) performing bulk reverse lookups or unauthorized zone transfer attempts. Expected volume: low on well-managed networks, but noisy if you have many external DNS queries from threat research IPs — tune by adding a GreyNoise "known benign scanner" exclusion list.

Rule 2 — Moderate: Sequential Host Sweep Detected in Flow Data
IF flow.protocol IN ["ICMP", "TCP", "UDP"] AND COUNT(DISTINCT flow.dst_ip) > 20 AND flow.duration_seconds < 2 AND flow.src_ip NOT IN [vulnerability_scanners, monitoring_hosts] WITHIN 60 SECONDS GROUP BY flow.src_ip THEN alert(severity=MEDIUM)

This detects ping sweeps, port scans, or network mapping tools touching many hosts in a short window — the core behavior of tools like Nmap and Masscan. Expected volume: medium, because legitimate IT tools (vulnerability scanners, SIEM forwarders, monitoring systems) do this constantly. Exclusion of known scanner IPs is essential before deploying this rule to production.

Rule 3 — Moderate: Reconnaissance Process Launched by Suspicious Parent on Endpoint
IF process.name IN ["nmap.exe", "tracert.exe", "pathping.exe", "arp.exe", "route.exe"] AND process.parent.name IN ["winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "mshta.exe", "wscript.exe", "cscript.exe"] AND event.id = "4688" THEN alert(severity=HIGH)

This catches an adversary who has gained initial access via a phishing document and is now running network discovery commands from within an Office process. This parent-child relationship is almost never legitimate and should produce very few false positives. Expected volume: very low — treat any hit as a priority investigation.

Rule 4 — Precise: Cloud Network Enumeration API Burst by Single Principal
IF cloud.event.name IN ["DescribeVpcs", "DescribeSubnets", "DescribeRouteTables", "DescribeNetworkInterfaces", "DescribeSecurityGroups"] AND COUNT(DISTINCT cloud.event.name) >= 4 WITHIN 60 SECONDS GROUP BY cloud.user.arn AND cloud.source_ip NOT IN [known_devops_ips, cicd_pipeline_ips] THEN alert(severity=HIGH)

This detects a compromised IAM credential being used to rapidly map cloud network topology — a common step after credential theft or SSRF exploitation. An attacker enumerating VPCs, subnets, and route tables in under a minute is distinct from a human operator doing this manually. Expected volume: very low outside CI/CD pipelines; high-fidelity when combined with IP exclusions.

Tuning Guidance

• Authorized vulnerability scanners: Tools like Tenable Nessus, Qualys, Rapid7 InsightVM, and Greenbone perform exactly the same behaviors as attacker scanning tools. Identify all scanner source IPs and hostnames and add them to a reference list exclusion: src_ip NOT IN [vuln_scanner_ips]. Review this list quarterly.
• Network monitoring and SNMP polling systems: Zabbix, PRTG, SolarWinds, and Nagios perform continuous ICMP and SNMP sweeps. Exclude their source IPs from flow sweep rules: src_ip NOT IN [monitoring_platform_ips].
• IT operations staff running legitimate diagnostics: Network engineers routinely run traceroute, arp, nmap, and dig from their workstations. Create a named group of IT admin accounts and exclude them from endpoint rules: user.name NOT IN [network_ops_accounts]. Consider instead alerting on these users running recon tools outside business hours as a separate, lower-threshold rule.
• CI/CD pipelines and DevOps tooling: Terraform, Ansible, and AWS CDK deployments routinely call cloud describe APIs to validate infrastructure state. Exclude known pipeline service account ARNs: cloud.user.arn NOT IN [cicd_service_principals].
• Security research and threat intelligence crawlers: Shodan, Censys, and GreyNoise will appear in your perimeter logs. Subscribe to their published IP range lists and add them as a known-benign exclusion in firewall alert rules. This prevents alert fatigue while keeping alerts for unknown scanners.
• DNS resolvers and CDN infrastructure: Cloudflare, Akamai, and Google DNS resolvers generate large volumes of PTR lookups that can trigger DNS enumeration rules. Exclude known CDN and resolver IP ranges from DNS sweep alerts using published IP range feeds.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Navigate directly to the raw log source (DNS server debug log, firewall syslog, CloudTrail, or Windows Security Event Log) and confirm the triggering event exists with all expected fields populated. Do not rely solely on the SIEM parsed fields — validate the raw event to rule out parsing errors or data forwarding issues.
2. Identify the affected host and user: Extract the source IP, hostname, and associated user account from the alert. Cross-reference the IP against your CMDB or asset inventory to determine if it is an internal endpoint, a server, a cloud instance, or an external IP — and immediately flag if the account holds privileged roles (domain admin, network admin, IAM power user).
3. Pull the full command-line and parent process chain: If the alert originated on an endpoint, retrieve the complete process tree from Windows Event ID 4688 logs or EDR telemetry (CrowdStrike, Defender for Endpoint, SentinelOne). Document the full command-line argument string, the parent process, and the grandparent process to determine whether execution was interactive, scripted, or spawned by a suspicious application.
4. Check for network connections and files written to disk: Query your EDR or Sysmon Event ID 3 (Network Connection) logs for outbound connections made by the suspicious process around the same timestamp. Also search Sysmon Event ID 11 (File Create) for any output files, scripts, or reconnaissance result files dropped to disk — attackers frequently redirect nmap or traceroute output to a file for later exfiltration.
5. Correlate with perimeter and flow data: Pull your firewall logs and NetFlow data for the 30-minute window surrounding the alert, filtering on the source IP. Look for connection attempts to unusual destination IPs, scanning patterns across multiple hosts or ports, or any successful outbound connections to external IPs not seen in baseline traffic — this helps establish the scope of what was enumerated.
6. Search for lateral movement from this host: In your SIEM, query Windows Event IDs 4624 (successful logon) and 4648 (explicit credential logon) for any authentication events sourced from the suspicious host in the 24 hours following the first recon alert. Also check for SMB lateral movement (Event ID 5140, 5145) and WMI or PSRemoting usage originating from this host.
7. Escalation decision: Escalate to a confirmed incident if you observe any of the following: recon commands spawned by an Office process or web-facing application (indicating active compromise), recon activity from an external IP that successfully connected to internal systems, or cloud API enumeration followed by resource creation or IAM modification. Treat the alert as likely benign if the activity is fully attributable to a known IT admin account, a documented scanner IP, or a CI/CD pipeline — but document your reasoning and close with evidence.

Response Playbook

Containment

• Isolate the affected endpoint immediately: If the recon activity originated from an internal host and you have confirmed suspicious process execution, use your EDR platform (CrowdStrike → "Network Contain", Defender for Endpoint → "Isolate Device", SentinelOne → "Network Quarantine") to cut off the host's network access while keeping it powered on so memory and process state are preserved for forensics. Do not reimage before forensic collection.
• Disable the associated user account: If a specific user account is tied to the suspicious activity, immediately disable it in Active Directory (Disable-ADAccount -Identity [username]) or the IdP (Azure AD, Okta). For cloud accounts, attach an explicit deny policy to the IAM principal using an AWS SCP or Azure Policy before disabling the account to prevent race conditions.
• Block identified external scanner IPs at the perimeter: Add any confirmed malicious external source IPs to your edge firewall's deny list and to your DNS RPZ (Response Policy Zone) if they resolved hostnames. Also push the IPs to your WAF's IP block list if web reconnaissance was detected. Document the block with a ticket reference so it can be reviewed for expiry.
• Revoke active sessions and tokens: Force sign-out of the compromised user's active sessions in your IdP. Revoke any OAuth tokens, API keys, or temporary credentials (AWS STS tokens) that the account held. In AWS, use iam:UpdateAccessKey to disable access keys and check for active STS sessions with sts:GetCallerIdentity from the compromised ARN.
• Notify your network and cloud teams: Alert the network operations and cloud infrastructure teams to monitor for any topology changes, new firewall rules, or infrastructure deployments that might have been initiated based on the reconnaissance — attackers sometimes act quickly after a successful mapping phase.

Eradication

• Remove any persistence mechanisms identified: On the affected endpoint, check for new scheduled tasks (Event ID 4698, or Get-ScheduledTask), new registry run keys (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKLM\...\Run), new services (Event ID 7045), and new startup folder entries. Remove any items that cannot be attributed to known-good software.
• Delete dropped tools and scripts: Search the filesystem for any reconnaissance output files (e.g., *.xml Nmap output, *.txt files in temp directories, PowerShell scripts in %APPDATA% or %TEMP%) and any binaries not in the original system image. Use your EDR's file search capability or deploy a YARA rule scan targeting known recon tool signatures.
• Reset credentials for all accounts involved: Reset the password for any user account that executed suspicious commands, any service account used on the host, and any account whose credentials may have been visible in process memory or command-line arguments during the incident. Force MFA re-enrollment for the affected user.
• Audit and remediate cloud permissions: If cloud API enumeration was detected, review the IAM permissions of the involved principal and apply least-privilege remediation — remove any wildcard ec2:Describe* or network:* permissions that are not operationally required. Rotate all API keys and secrets associated with the account.
• Search lateral movement targets for backdoors: For every system the compromised account authenticated to in the 24 hours before and after the alert, run an EDR threat hunt or at minimum check for new local admin accounts (Event ID 4720 + 4732), new services, and new scheduled tasks. Do not assume only the initially identified host is affected.

Recovery

• Verify the host is clean before reconnecting: Before removing network isolation, confirm with your EDR that no active malicious processes, network connections, or persistence mechanisms remain. If confidence is low, or if the host was compromised before EDR was deployed, reimage from a known-good baseline and restore data from pre-incident backups rather than risking reintroduction of a hidden implant.
• Re-enable the user account only after validation: Restore the user account in Active Directory or the IdP only after confirming no persistence remains on their workstation, their credentials have been fully reset, and MFA has been re-enrolled. Brief the user on the incident and instruct them to report any unusual activity immediately.
• Monitor intensively for 72 hours post-remediation: Create a temporary, high-sensitivity watchlist in your SIEM containing the affected host, user account, and any IPs or domains identified during the investigation. Alert on any activity from these indicators for 72 hours — attackers frequently return using secondary access paths if they believe their primary access was disrupted but not fully eradicated.
• Update detection rules with new IOCs: Add any newly discovered scanner IPs, tool hashes, command-line patterns, or domain names to your detection rules and threat intelligence platform. If the attacker used a previously unknown tool, write a new YARA or Sigma rule and share it with your ISAC or threat intel community.
• Conduct a full incident retrospective: Document the complete attack timeline from first evidence of reconnaissance to containment, including all IOCs, affected systems, actions taken, and response time at each stage. Use this to identify gaps in telemetry coverage (e.g., "we had no DNS query logs for the first 4 hours"), update runbooks, and brief leadership. File lessons learned in your detection engineering backlog to drive measurable improvements.