Overview

T1590.006 covers adversary reconnaissance of a target's network security appliances — firewalls, proxies, bastion hosts, content filters, and network-based intrusion detection systems (NIDS). By mapping which defensive tools are deployed and how they are configured, attackers identify gaps, blind spots, and exploitable weaknesses before launching their actual intrusion. This is a pre-compromise activity, meaning it typically happens entirely outside the victim's environment.

Because this technique lives in the PRE phase, direct telemetry is limited — you will rarely catch it happening in real time inside your own logs. However, the downstream signals matter: external scanning activity, unusual queries against your public-facing infrastructure, and suspicious information-gathering behavior from internal hosts that may already be compromised all provide actionable detection opportunities. Teams that ignore pre-compromise reconnaissance miss the earliest opportunity to identify adversary interest in their organization.

Attacker Perspective

Before launching an intrusion, adversaries systematically profile a target's defenses to find the path of least resistance into and through the network.

• Active firewall and IDS fingerprinting: Attackers use tools like nmap --script firewall-bypass, nmap -sA (ACK scan to map firewall rule sets), or hping3 --firewall to determine which ports are filtered versus closed, inferring firewall presence and rule logic from differential responses.
• Proxy and bastion host enumeration: Tools like masscan combined with banner grabbing (curl -v https://target.com and inspecting Server: or Via: headers) reveal reverse proxy products, versions, and internal routing paths that an attacker can later abuse for bypass or pivoting.
• Passive OSINT collection: Attackers query Shodan.io, Censys.io, and ZoomEye for the organization's IP ranges, exposing firewall management interfaces, VPN endpoints, and appliance banners without sending a single packet to the target.
• Job posting and document metadata harvesting: Using theHarvester or manual searches of LinkedIn and vendor case studies, adversaries identify specific security products in use (e.g., "Palo Alto PA-5200 series" or "Cisco Firepower") by mining job descriptions, RFP documents, and conference presentations the organization has published.

This technique is attractive precisely because most of it generates no log entries inside the victim's environment, giving attackers a detailed defensive map at nearly zero risk of detection.

Detection Strategy

Required Telemetry

• Perimeter firewall and IDS/IPS logs: Enable logging for all deny, drop, and reject decisions, including source IP, destination IP/port, protocol, and rule matched. For Palo Alto, enable Threat logs and Traffic logs at all security zones. For Cisco ASA/Firepower, enable logging trap informational and send to syslog. Without this, you cannot see who is knocking on your perimeter.
• Web Application Firewall (WAF) logs: Enable full request logging including User-Agent, X-Forwarded-For, URI, HTTP method, and response code. AWS WAF, Azure Front Door, Cloudflare, and F5 all support this — confirm it is actually enabled and forwarding to your SIEM, not just stored locally.
• DNS query logs: Enable passive DNS logging on your recursive resolvers and authoritative servers. For Windows DNS servers, enable DNS Debug logging (Event ID 3008 for queries) or deploy DNS analytical logging via Microsoft-Windows-DNS-Server/Analytical channel. For BIND/Unbound, enable query logging in the config. This catches reverse lookups and enumeration of your domain space.
• VPN and remote access gateway logs: Enable authentication attempt logging (success and failure) plus session metadata from Cisco AnyConnect, Pulse Secure, GlobalProtect, or equivalent. Failed authentication spikes against VPN endpoints are a common signal that an adversary is confirming the VPN product and testing credential lists derived from their reconnaissance.
• Network flow data (NetFlow/IPFIX/sFlow): Collect flow records at your internet edge and DMZ boundaries. This provides source/destination IP, port, protocol, byte counts, and packet counts even when payload inspection is not available. Essential for detecting systematic port scans that evade signature-based detection.
• Cloud infrastructure audit logs: Enable AWS CloudTrail, Azure Monitor Activity Log, or GCP Cloud Audit Logs. Attackers increasingly query cloud APIs to enumerate security group rules, WAF policies, and network ACLs. Specifically, watch for DescribeSecurityGroups, ListWebACLs, GetNetworkAcl, and DescribeNetworkInterfaces API calls from unfamiliar principals.
• Windows Security Event Log — Network and authentication events: Enable audit policy for Audit Logon Events (Success and Failure) to capture Event ID 4625 (failed logon) and 4624 (successful logon) on perimeter-adjacent Windows hosts and jump servers. Enable Audit Object Access for network shares if bastion hosts use Windows file shares as part of their operation.
• Proxy and web gateway logs: Enable full URL logging including User-Agent, referrer, destination IP, response code, and bytes transferred on Bluecoat, Zscaler, Squid, or equivalent. These logs show internal hosts making outbound connections that may indicate a compromised system conducting secondary reconnaissance on behalf of an attacker.

Key Indicators

• Port scan signatures on firewall logs: In firewall deny logs, look for source_ip generating drops to more than 10 distinct destination_port values within a 60-second window. ACK-scan patterns specifically show tcp_flags = ACK with no corresponding SYN — this is characteristic of firewall rule mapping with nmap -sA.
• Nmap and scanner User-Agent strings in WAF/proxy logs: Check http.useragent or cs(User-Agent) field for values containing Nmap Scripting Engine, masscan, zgrab, nuclei, Shodan, or censys. These strings are often left in default scanner configurations.
• Banner grabbing behavior: In proxy or WAF logs, watch for HTTP requests to management ports (destination_port IN [8080, 8443, 4443, 8888, 9090, 10443]) with minimal or no request body and short session duration — characteristic of banner grabbing rather than legitimate application traffic.
• Systematic enumeration of cloud security APIs: In CloudTrail or Azure Activity logs, look for event_name IN [DescribeSecurityGroups, ListWebACLs, GetNetworkAcl, DescribeFirewallPolicies] called in rapid succession (more than 5 distinct security-related API calls within 2 minutes) from a source_ip not associated with your automation or infrastructure-as-code pipeline accounts.
• Reverse DNS and PTR record enumeration: In DNS query logs, a single external source IP issuing PTR queries for more than 20 addresses in your registered IP space within a short window (query_type = PTR and source_ip not in known crawler allowlists) suggests systematic mapping of your public IP infrastructure.
• VPN endpoint probing: In VPN gateway authentication logs, look for auth_result = FAIL with more than 5 distinct username values from a single source_ip within 10 minutes — this pattern suggests credential stuffing combined with VPN product confirmation rather than a single user forgetting their password.
• Internal host connecting to Shodan or Censys APIs: In proxy logs, flag outbound connections from internal hosts to api.shodan.io, search.censys.io, or api.zoomeye.org — a compromised internal host conducting secondary reconnaissance will often use these services to look up your own organization's infrastructure from the inside.

Detection Logic

Rule 1: External Port Scan Against Perimeter — High Sensitivity
IF log_source = "firewall_deny" AND source_ip NOT IN known_scanners_allowlist AND COUNT(DISTINCT destination_port) > 15 AND time_window = "60s" GROUP BY source_ip THEN alert(priority=medium)

This catches broad reconnaissance sweeps against your perimeter. Expected volume is moderate — legitimate vulnerability scanners, cloud health probes, and search engine crawlers will trigger this. Use the tuning guidance below to suppress known sources. The value is in catching novel, unlisted scanning sources early.

Rule 2: Cloud Security API Enumeration Burst — Medium Precision
IF log_source IN ["aws_cloudtrail", "azure_activity", "gcp_audit"] AND event_name IN ["DescribeSecurityGroups", "ListWebACLs", "GetNetworkAcl", "DescribeFirewallPolicies", "DescribeNetworkAcls", "ListFirewallPolicies"] AND COUNT(DISTINCT event_name) >= 4 AND time_window = "120s" GROUP BY source_ip, user_identity AND NOT user_identity IN [terraform_service_accounts, ci_cd_pipeline_accounts] THEN alert(priority=high)

This targets adversaries who have obtained cloud credentials and are using them to map your cloud security posture before moving laterally. Excluding known automation accounts significantly reduces false positives. A human user calling five different security-describe APIs in two minutes is unusual and warrants immediate investigation.

Rule 3: Scanner User-Agent or Known Recon Tool Header in WAF Logs — High Precision
IF log_source = "waf_or_proxy" AND http_user_agent MATCHES ["Nmap", "masscan", "zgrab", "nuclei", "nikto", "sqlmap", "dirbuster", "gobuster", "shodan", "censys"] THEN alert(priority=high)

This is highly precise — legitimate browsers and applications do not present these strings. False positive rate is very low, so these alerts should be treated as confirmed reconnaissance activity and triaged quickly. Volume will be low, making each alert meaningful.

Rule 4: Internal Host Querying External Recon Platforms — Indicator of Compromise
IF log_source = "proxy_or_dns" AND (destination_domain IN ["api.shodan.io", "search.censys.io", "api.zoomeye.org", "fofa.so"] OR dns_query MATCHES ["shodan.io", "censys.io"]) AND source_ip IN internal_ip_ranges AND NOT source_ip IN [security_team_workstations, approved_pentest_hosts] THEN alert(priority=critical)

An internal host reaching out to Shodan or Censys APIs is a strong signal that the host is compromised and an attacker is using it to conduct secondary reconnaissance against your own organization. This rule has very low expected volume and should be treated as critical when triggered.

Tuning Guidance

• Legitimate vulnerability scanners: Your internal security team likely runs Tenable Nessus, Qualys, or Rapid7 InsightVM on a schedule. These will trigger Rule 1 and potentially Rule 3. Maintain a documented allowlist of scanner source IPs and exclude them with source_ip NOT IN approved_scanner_ips. Audit this allowlist quarterly — stale entries create blind spots.
• Search engine and CDN crawlers: Googlebot, Bingbot, and CDN health check probes will trigger port scan rules. Suppress by adding source_ip NOT IN known_crawler_cidr_ranges using maintained blocklists from Google, Bing, and your CDN vendor. These IP lists change, so automate the feed rather than hardcoding them.
• Terraform, Ansible, and CI/CD pipelines: Infrastructure-as-code tools running in your environment call cloud security APIs constantly to check current state before applying changes. These will massively inflate Rule 2 alerts. Identify the IAM roles or service accounts used by these tools and exclude with user_identity IN [terraform_role_arn, ansible_service_account]. Never use broad exclusions like "all service accounts" — be specific.
• Security team and penetration test activity: Authorized red team or penetration test exercises will look identical to attacker reconnaissance. Establish a formal process to pre-notify the SOC with source IPs, time windows, and scope before any authorized testing. Add source_ip IN [approved_pentest_hosts] as a time-bounded exclusion that expires automatically when the test window closes.
• Third-party monitoring services: Uptime monitoring vendors (Pingdom, DataDog synthetics, StatusPage probes) regularly connect to your perimeter services and may trigger banner-grabbing rules. Identify their probe IP ranges from vendor documentation and add them to your allowlist with a label noting the vendor name for audit clarity.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the raw log record directly from your SIEM (Splunk: use index=firewall sourcetype=pan:traffic with the exact timestamp and source IP; Sentinel: use KQL to query the specific table like CommonSecurityLog). Confirm the fields match what the detection rule fired on — rule logic bugs can cause phantom alerts.
2. Identify the source IP and determine whether it is external or internal. Run the source IP through your asset inventory and threat intelligence feeds (VirusTotal, AbuseIPDB, your SIEM's built-in TI). If the IP is internal, immediately escalate priority — an internal source conducting security appliance reconnaissance almost certainly represents a compromised host, not an external scanner.
3. Pull the full scope of activity from that source IP across all log sources. Search all available telemetry (firewall, WAF, DNS, VPN, proxy, cloud audit logs) for any event where source_ip matches the alerting IP in the past 7 days. Build a timeline of every interaction — this reveals whether this is an isolated scan or part of a sustained, multi-stage reconnaissance campaign targeting your environment.
4. Characterize the specific technique being used. Determine whether the activity is passive (OSINT, no packets hitting your network), active scanning (firewall drops, WAF hits), or internal (a compromised host conducting recon from inside). Review the destination_port pattern, http_user_agent, and API call names to identify the specific tool — this informs both attribution confidence and the evasion capability of the adversary.
5. Check whether any reconnaissance probes received a successful response. In firewall and WAF logs, filter the same source IP for events where action = allow or response_code IN [200, 301, 302, 400] — these indicate the attacker received useful information back. A successful response to a management interface probe (e.g., port 8443 returning a login page) is significantly more concerning than all-drops and requires escalation.
6. Search for related activity suggesting follow-on actions. Using the same source IP or any correlated infrastructure (check passive DNS for shared hosting, WHOIS for shared registrants), look for subsequent activity in VPN logs (authentication attempts), phishing gateway logs (inbound email from related domains), or identity provider logs (Azure AD / Okta) for login attempts. This reveals whether the reconnaissance has already transitioned to an intrusion attempt.
7. Make the escalation decision based on evidence of intent and capability. Treat the activity as a confirmed threat requiring incident response if any of the following are true: the source is internal, a probe received a successful response to a management interface, correlated follow-on activity exists (VPN brute force, phishing), or the source IP appears in threat intelligence as associated with a known threat actor. If none apply and the source is an external scanner with no successful responses, document the IOCs, add them to blocklists, and close as reconnaissance-only with a monitoring note.

Response Playbook

Containment

• Block the scanning source at the perimeter immediately: Add the source IP and any identified related CIDR ranges to a deny-all rule on your edge firewall or WAF. For cloud environments, add the IP to your AWS WAF IP set or Azure Front Door block list. Document the rule with a ticket number and expiry review date — permanent blocks without review create firewall rule sprawl.
• If the source is an internal host, isolate it at the network layer without powering it off: Move the host to a quarantine VLAN using your NAC solution (Cisco ISE, Aruba ClearPass) or apply a restrictive ACL at the switch port. Keeping the host powered on preserves volatile memory (running processes, network connections) for forensic investigation. Do not reimage until forensics are complete.
• Disable the associated user account if internal activity is confirmed: In Active Directory, use Disable-ADAccount -Identity username or the Azure AD portal to disable the account. Simultaneously revoke all active sessions in your identity provider (Okta: Admin → User → More Actions → Clear User Sessions; Azure AD: Revoke Sign-In Sessions). This prevents an attacker from pivoting using stolen credentials while investigation proceeds.
• If cloud API enumeration is confirmed, rotate the affected credential immediately: Deactivate the IAM access key in AWS IAM console or Azure AD app registration, and issue a new one only to the legitimate automated process. Do not delete the old key until you have confirmed the replacement works — deleting without replacement can break production pipelines and cause pressure to undo containment steps prematurely.
• Implement temporary enhanced logging on targeted assets: If the adversary probed specific management interfaces or VPN endpoints, temporarily increase logging verbosity on those specific systems and set up a watch alert for any authentication attempts or configuration changes for the next 72 hours.

Eradication

• If an internal host was involved, conduct full forensic triage before eradication: Use your EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) to pull a process tree, network connection history, and file write events for the host. Identify exactly how the host was compromised and what tools were installed before you attempt to remove anything.
• Remove identified attacker tools and dropped payloads: Search for files written to common staging locations (C:\Users\Public\, C:\Windows\Temp\, /tmp/, /var/tmp/) around the time of the initial compromise event. Use your EDR's file search capability to hunt for known scanner binaries (nmap, masscan, zgrab) if installed on the compromised host.
• Remove any persistence mechanisms discovered during forensics: Check scheduled tasks (schtasks /query /fo LIST /v), startup registry keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), installed services, and cron jobs (crontab -l for all users). If a web shell was deployed on a perimeter-facing server, remove it and audit all files in the web root for modification timestamps around the compromise date.
• Reset credentials for all accounts that touched the compromised host or related systems: This includes the local administrator account, any domain accounts that logged into the host during the suspicious window (pull from Event ID 4624 logs), and any service accounts whose credentials were stored on that host. Force password reset and invalidate all existing tokens.
• Audit and tighten the specific exposure that was being probed: If the attacker was mapping your firewall rules, review whether any management interfaces are unnecessarily exposed to the internet and remove those exposures. If VPN was being probed, verify MFA is enforced for all VPN authentication and review which accounts are VPN-enabled.

Recovery

• Re-image the compromised host if confidence in complete eradication is less than certain: A forensic investigation that cannot definitively trace every attacker action means unknown implants may remain. Rebuild from a known-good golden image and restore data from a pre-compromise backup rather than risk reconnecting a dirty system to the production network.
• Re-enable affected user accounts only after confirming no persistence remains: Before re-enabling the account in Active Directory or your IdP, verify that no new accounts were created, no group memberships were modified, and no new app registrations or OAuth grants were added during the compromise window. Review Azure AD Sign-In logs and AWS IAM Access Advisor for any activity under the account during the suspicious period.
• Monitor the previously affected host and user account intensively for 72 hours post-recovery: Configure a temporary watch rule in your SIEM that alerts on any event from the recovered host's new hostname or the re-enabled user's UPN with priority escalation to the analyst who handled the original incident. Attackers sometimes return to previously compromised targets after they observe that access was revoked.
• Add newly identified IOCs to your permanent blocking and detection infrastructure: The source IPs, domains, user-agent strings, and API call patterns identified in this investigation should be added to your firewall blocklists, WAF rules, threat intelligence platform, and SIEM detection rules. Tag them with the incident ticket number so future analysts understand the provenance.
• Conduct a lessons-learned review and document the full incident timeline: Record the first evidence of reconnaissance, every action taken, and how long each phase took. Present findings to leadership with specific recommendations: Was the detection rule that fired adequate? Were there signals that were missed? What telemetry gap, if any, did this incident reveal? Use this to drive concrete improvements to the detection strategy before closing the incident formally.