Overview

T1590 — Gather Victim Network Information — describes the pre-attack phase where adversaries collect details about a target's network topology, IP ranges, domain names, ASN data, and operational infrastructure. Attackers use this intelligence to map the environment before launching active attacks, identifying high-value targets, exposed services, and trust relationships they can later exploit.

Because this reconnaissance happens largely outside your perimeter — using public databases, passive DNS, and WHOIS registries — it is difficult to detect directly. However, when adversaries use internal tools, run network scanners from a compromised host, or attempt DNS zone transfers, they leave traces your SIEM can catch. Detecting this technique early is your best chance to disrupt an attack before the adversary achieves initial access.

Attacker Perspective

Attackers treat network reconnaissance as the essential foundation for every phase that follows — without it, they are operating blind.

• Passive public enumeration: Adversaries query WHOIS registries, BGP routing databases (e.g., ARIN, RIPE), and tools like amass enum -d target.com or dnsdumpster to enumerate IP ranges and subdomains without touching the target network at all.
• DNS zone transfer abuse: Attackers attempt dig axfr @ns1.target.com target.com or nslookup -type=AXFR target.com ns1.target.com against misconfigured authoritative DNS servers, potentially dumping the entire internal DNS namespace in a single query.
• Internal network scanning post-compromise: Once inside, adversaries run tools like Advanced IP Scanner, Crassus.exe, or nmap -sn 10.0.0.0/8 from a beachhead host to discover live hosts, subnets, and services invisiblefrom the outside.
• Certificate transparency and passive DNS: Attackers use services like crt.sh, Shodan, or Censys to identify all TLS certificates issued for a domain, revealing internal hostnames, staging environments, and VPN gateways that were never meant to be public.

This technique is especially attractive because most of the highest-value information is freely available from public sources, meaning skilled adversaries can build a detailed network map before ever sending a single packet to their target.

Detection Strategy

Required Telemetry

• Windows Process Creation (Sysmon Event ID 1 or Windows Security Event ID 4688): Enable Sysmon via a config that captures full command-line arguments. For native Windows logging, enable command-line auditing via GPO: Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events, or registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This generates Event ID 4688 with full command-line data.
• Windows DNS Server Logs (Event ID 6004): Enable DNS server debug/analytic logging on all Windows DNS servers via the DNS Server management console or PowerShell: Set-DnsServerDiagnostics -All $true. Event ID 6004 is generated when a zone transfer request is received for a non-existent or non-authoritative zone. These events appear in the Microsoft-Windows-DNS-Server/Audit channel.
• Proxy / Web Gateway Logs: Ensure your proxy logs capture the full URI including query string fields (c-uri, c-uri-query, cs-host, c-ip, cs-username). Required for detecting update check beaconing from scanning tools like Advanced IP Scanner.
• Network Flow / Firewall Logs (NetFlow, Zeek conn.log, Palo Alto Traffic logs): Capture source IP, destination IP, destination port, bytes, and packet count. Critical for detecting horizontal scanning patterns from internal hosts. Zeek's conn.log is preferred for richness of fields.
• DNS Query Logs: Enable DNS client-side query logging via Sysmon Event ID 22 (DNSEvent) or Windows DNS debug logging. On Linux, configure auditd or deploy Zeek's dns.log on network taps to capture all DNS queries including failed AXFR attempts. Sysmon Event ID 22 requires a Sysmon config entry for DnsQuery.
• Windows File System Events (Sysmon Event ID 11): Monitor for creation of output files commonly written by scanning tools (e.g., CSV exports from Advanced IP Scanner, XML reports from nmap). Enable via Sysmon config targeting common output directories like %USERPROFILE%\Desktop and %TEMP%.

Key Indicators

• Crassus execution — Process Creation logs: Look for Image field ending with \Crassus.exe, or OriginalFileName = Crassus.exe, or Description containing Crassus. This tool has no legitimate enterprise use case.
• Advanced IP/Port Scanner update check — Proxy logs: c-uri contains /checkupdate.php AND c-uri-query contains all of lng=, ver=, beta=, type=, rmode=, product=. Destination host will be www.advanced-ip-scanner.com or www.advanced-port-scanner.com. This beaconing confirms the tool is installed and running.
• DNS zone transfer attempts — DNS Server logs: Windows DNS Event ID 6004 indicates an inbound AXFR request for a zone the server does not own or is not authoritative for. Also watch Zeek dns.log for qtype_name = AXFR or qtype = 252, especially from external source IPs.
• Internal network scanning — NetFlow / Firewall logs: A single source IP making connections to more than 20 unique destination IPs within a 5-minute window on ports 22, 80, 443, 445, 3389, or ICMP. This is a strong indicator of host-based scanning post-compromise.
• nmap or common scanner command lines — Process Creation logs (Event ID 4688 / Sysmon 1): CommandLine containing nmap, masscan, arp-scan, netdiscover, or angry ip. Also look for PowerShell patterns like Test-NetConnection or 1..254 | ForEach combined with port probing.
• WHOIS / BGP query tool execution — Process Creation logs: Command lines containing whois (with trailing space indicating a target argument), or execution of bgpview, host , or dig axfr. On Windows endpoints, these may indicate attacker tooling.
• Scanning tool output files — File Creation logs (Sysmon Event ID 11): Files created with names matching patterns like *scan*.csv, *ip_scan*, *nmap*.xml, or *network_report* in user-writable directories.

Detection Logic

Rule 1: Internal Host Performing Broad Network Scan
IF src_ip IN internal_ranges AND dst_ip IN internal_ranges AND DISTINCT(dst_ip) > 20 WITHIN 5 minutes AND dst_port IN [22, 23, 80, 443, 445, 3389, 8080] THEN alert HIGH

This catches post-compromise internal scanning regardless of what tool is used. Expected volume: low in most environments; elevated in environments running legitimate IT scanning tools like Nessus or SCCM — tune with exclusions for known scanner IPs before deploying broadly.

Rule 2: Known Network Reconnaissance Tool Executed
IF (EventID = 1 OR EventID = 4688) AND (Image ENDSWITH '\Crassus.exe' OR Image ENDSWITH '\nmap.exe' OR Image ENDSWITH '\masscan.exe' OR CommandLine CONTAINS 'axfr' OR CommandLine CONTAINS 'arp-scan') THEN alert HIGH

Directly matches execution of known scanning and reconnaissance binaries. This is a high-precision rule — false positive rate is very low for Crassus, moderate for nmap in environments where IT uses it legitimately. Alert volume should be near-zero unless you are actively in an incident or have unsanctioned tools deployed.

Rule 3: DNS Zone Transfer Attempt Detected
IF (EventID = 6004) OR (dns.log: qtype = 252 AND NOT src_ip IN [authorized_secondary_dns_servers]) THEN alert MEDIUM

Catches both failed zone transfer attempts logged by Windows DNS and successful AXFR queries observed on the wire via Zeek. The Windows event fires on unauthorized attempts; Zeek catches attempts against any DNS server on the network. Alert volume should be very low — zone transfers to non-authorized servers are almost always anomalous.

Rule 4: Advanced IP Scanner / Port Scanner Proxy Beaconing
IF proxy_log: c-uri CONTAINS '/checkupdate.php' AND c-uri-query CONTAINS 'lng=' AND c-uri-query CONTAINS 'ver=' AND c-uri-query CONTAINS 'product=' AND (cs-host CONTAINS 'advanced-ip-scanner.com' OR cs-host CONTAINS 'advanced-port-scanner.com') THEN alert MEDIUM

This fires when Advanced IP Scanner or Advanced Port Scanner runs on any host that routes through the proxy. The update check is automatic and nearly guaranteed to trigger within minutes of the tool launching. Alert volume depends entirely on whether the tool is sanctioned — if not, treat every hit as worthy of investigation.

Tuning Guidance

• Legitimate IT scanning tools (Nessus, Qualys, SCCM, Lansweeper): These will trigger the broad network scan rule constantly. Identify the dedicated scanner host IPs and exclude them: AND NOT src_ip IN [nessus_scanner_ip, qualys_cloud_agent_subnet]. Document these exclusions in your SIEM and review them quarterly.
• Authorized secondary DNS servers performing zone transfers: Any legitimate secondary DNS server will generate AXFR traffic. Build and maintain a list of authorized secondaries and exclude: AND NOT src_ip IN [authorized_secondary_dns_servers]. Alert if a new IP attempts AXFR that is not on this list.
• nmap used by authorized penetration testers or IT staff: If your organization permits nmap usage, create an exclusion based on a specific user account or hostname used for authorized testing: AND NOT (user IN [pentest_accounts] OR ComputerName IN [pentest_hosts]). Require that authorized scans be pre-approved and logged in a ticketing system so analysts can cross-reference.
• Advanced IP Scanner sanctioned for IT helpdesk: If helpdesk staff legitimately use Advanced IP Scanner, exclude their specific workstation hostnames or IP ranges from the proxy rule rather than suppressing the entire rule: AND NOT src_ip IN [helpdesk_workstation_range].
• PowerShell network connectivity tests by monitoring tools: Legitimate RMM tools (e.g., ConnectWise, SolarWinds) may use Test-NetConnection at scale. Exclude by parent process: AND NOT ParentImage ENDSWITH '\solarwinds.businesslayerhost.exe' or by the specific service account used.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event exists in the source log. Navigate directly to the originating log source — Windows Security Event ID 4688, Sysmon Event ID 1, DNS Event ID 6004, or your proxy log — and confirm the event fields match what the detection rule fired on. Do not proceed on a correlation result alone without seeing the underlying raw event.
2. Identify the affected host and user account, and determine if the account is privileged. Extract the ComputerName, SubjectUserName, and LogonID fields from the process creation or DNS event. Query your identity provider (Active Directory, Azure AD) to determine if this account has admin rights, service account status, or access to sensitive systems.
3. Pull the full command-line and reconstruct the parent process chain. Using Sysmon Event ID 1 or 4688, retrieve the CommandLine, ParentImage, ParentCommandLine, and ParentProcessGuid fields. Chain upward through parent processes using the ProcessGuid / ParentProcessGuid relationship to determine how the scanning tool was launched — was it spawned by a browser, Office application, or remote shell?
4. Check for network connections made during and after the scanning activity. Query Zeek conn.log, Windows Firewall logs, or your EDR's network telemetry for all outbound connections from the host in the 30-minute window around the alert. Look for connections to large numbers of internal IPs (scanning), connections to known threat intel IOCs, or data exfiltration to external destinations (large outbound byte counts).
5. Identify any files written to disk by the scanning process. Query Sysmon Event ID 11 (FileCreate) for the process GUID of the scanner process. Look for output reports, exported CSV/XML files, or tool binaries dropped to disk. Note their full paths, creation timestamps, and hash values — submit hashes to VirusTotal or your threat intel platform.
6. Search for evidence of lateral movement originating from this host. Query Windows Security Event ID 4624 (successful logon) and 4648 (explicit credential logon) for logon events where the source workstation matches the affected host. Also check for SMB lateral movement in Zeek smb.log or Sysmon network Event ID 3 showing connections from this host to other internal systems on port 445 or 3389.
7. Make the escalation decision based on whether the activity is explained and isolated. If the scanning tool execution is explained by a legitimate ticket, the parent process chain is clean, and there are no follow-on connections or lateral movement indicators, document and close as a policy violation or false positive. If the tool was spawned by an unusual parent (Office, browser, service account), there are external connections, or lateral movement is confirmed, escalate immediately to a full incident response engagement and proceed with containment.

Response Playbook

Containment

• Isolate the affected host from the network immediately but leave it powered on. Use your EDR console (CrowdStrike, Defender for Endpoint, SentinelOne) to apply a network containment policy, or block the host's MAC address at the switch level. Do not power off the machine — volatile memory may contain attacker tools, credentials, or active C2 connections needed for forensics.
• Disable the affected user account in Active Directory. Run Disable-ADAccount -Identity [username] in PowerShell or use the ADUC console. If the account is a service account, coordinate with the application owner before disabling to minimize operational impact, but do not leave an account with a confirmed compromise active.
• Block any identified external IPs or domains at the firewall and DNS layer. If the investigation identified C2 infrastructure or data exfiltration destinations, push block rules to your perimeter firewall and add DNS sinkholes for any malicious domains. Document each block with a ticket reference and timestamp.
• Kill any active malicious processes on the host if remote access is still available. Use your EDR's remote kill capability or Stop-Process -Name [process] -Force via remote PowerShell. Capture a full process list and memory dump before killing the process if your EDR supports it.
• Revoke any active sessions and authentication tokens for the affected account. In Azure AD, use Revoke-AzureADUserAllRefreshToken -ObjectId [user_object_id]. For on-premises Kerberos sessions, reset the account password immediately, which invalidates existing TGTs.

Eradication

• Remove any identified scanning tools or dropped payloads from the host. Use EDR's remote file deletion capability or a forensic workstation to delete identified binaries and output files. Verify deletion with a hash-based search across your environment to confirm no copies exist on other hosts.
• Search for and remove any persistence mechanisms the attacker may have established. Check scheduled tasks (schtasks /query /fo LIST /v), startup registry keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new services (sc query type= all state= all), and WMI subscriptions. Compare against a known-good baseline if available.
• Reset credentials for all accounts that were active on the compromised host. Use Sysmon or Windows Security logs to identify every account that logged into the host during the suspected compromise window (Event IDs 4624, 4648, 4672). Reset passwords for all of them and force re-enrollment of MFA tokens where applicable.
• Audit lateral movement targets for secondary compromise. For every host the affected machine connected to during the investigation window, run a targeted hunt for the same scanning tool IOCs, persistence mechanisms, and new user accounts. Do not assume the attacker only touched the initially identified host.
• Rotate any API keys, service account passwords, or secrets that may have been exposed. If the compromised host had access to secrets management (Vault, AWS Secrets Manager, Azure Key Vault) or stored credentials in configuration files, treat all of those secrets as compromised and rotate them immediately.

Recovery

• Re-image the host rather than attempting in-place cleanup if confidence in full eradication is low. If the parent process chain showed the tool was delivered by an external payload or if you cannot account for the full attacker timeline, a clean OS image is the only reliable path to a known-good state. Restore from a pre-compromise backup or deploy a fresh image from your golden image library.
• Re-enable the affected user account only after confirming no persistence mechanisms remain and credentials have been reset. Require the user to complete a security awareness review before restoring access, and notify their manager of the incident per your IR communication policy.
• Monitor the previously affected host and user account intensively for 72 hours post-remediation. Create a temporary watchlist rule in your SIEM that alerts on any process execution, logon event, or network connection from this host or account, regardless of whether it matches existing detection logic. Treat any anomaly during this window as a potential re-compromise indicator.
• Document the full attack timeline from initial indicator to containment and publish the completed incident report. Include every IOC discovered (hashes, IPs, domains, file paths, user accounts), the detection gap analysis, and any detection rules that were updated as a result of this incident.
• Review and update your detection rules based on any new TTPs or tooling observed during this incident. If the attacker used a variant or tool not covered by existing Sigma rules, write a new rule, test it against historical log data, and push it to production. Feed new IOCs into your threat intelligence platform and share with your ISAC if appropriate.