Overview

Network Service Discovery (T1046) is a reconnaissance technique where adversaries scan local and remote systems to enumerate running services, open ports, and potentially vulnerable software. Attackers use this information to map the network, identify high-value targets, and select appropriate exploitation paths before moving laterally or escalating privileges.

Every security team needs detection for this technique because it is a near-universal step in both opportunistic and targeted intrusions — catching it early can stop an attacker before they pivot to more destructive actions. Scanning activity often appears in bursts and leaves clear fingerprints in network flow data, process execution logs, and endpoint telemetry, making it one of the most detectable pre-exploitation behaviors if the right logging is in place.

Attacker Perspective

After gaining an initial foothold, adversaries almost always perform network service discovery to understand what they can reach and what they can exploit next.

• Port scanning with Nmap: Attackers run commands such as nmap -sV -p 1-65535 192.168.1.0/24 to fingerprint services and versions across an entire subnet, feeding results directly into exploit selection.
• Living-off-the-land scanning with PowerShell: Adversaries use built-in capabilities such as Test-NetConnection -ComputerName 10.0.0.1 -Port 445 or crafted PowerShell loops to probe SMB, RDP, and WinRM ports without dropping external tools.
• Masscan for high-speed internet-facing scans: In IaaS and cloud-connected environments, attackers run masscan 10.0.0.0/8 -p 22,80,443,3389 --rate=10000 to discover externally reachable services across large address spaces in seconds.
• macOS Bonjour/mDNS enumeration: On macOS hosts, adversaries issue dns-sd -B _ssh._tcp . or dns-sd -B _smb._tcp . to passively discover other hosts advertising services on the local network segment without generating traditional port-scan noise.

This technique is attractive because it requires minimal privileges, leverages tools that are often already present on the system or whitelisted by defenders, and delivers high-value intelligence that directly enables every subsequent phase of the attack chain.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. Also enable command-line logging in process creation events via GPO: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This generates Event ID 4688 with the full command line populated in the CommandLine field.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Logs the full content of PowerShell scripts and commands, including obfuscated ones that are decoded at runtime.
• Windows — Network Connection Events (Sysmon Event ID 3): Deploy Sysmon with a configuration that captures NetworkConnect events. Key fields: SourceIp, DestinationIp, DestinationPort, Image (the process making the connection), User. Without Sysmon, use Windows Filtering Platform events (Event IDs 5156/5157) enabled under Advanced Audit Policy → Object Access → Audit Filtering Platform Connection = Success and Failure.
• Linux — Auditd Process Execution: Add the following rules to /etc/audit/audit.rules: -a always,exit -F arch=b64 -S execve -k process_exec. This captures all process executions with arguments. Forward logs via auditd → rsyslog or Filebeat to your SIEM. Key fields: comm (process name), exe (full path), cmdline, uid, ppid.
• Linux — Network Socket Activity via Auditd: Add: -a always,exit -F arch=b64 -S socket -S connect -k network_activity to capture socket creation and outbound connection attempts. Alternatively, use eBPF-based tools such as Falco with a rule watching connect syscalls from unexpected processes.
• macOS — Endpoint Security Framework / Unified Logs: Enable Endpoint Security Framework (ESF) via an EDR agent or use log stream --predicate 'process == "dns-sd" OR process == "mDNSResponder"' to capture Bonjour enumeration. Process execution can also be captured via ESF-based EDR telemetry (e.g., Jamf Protect, CrowdStrike, SentinelOne).
• Network Flow / NetFlow / VPC Flow Logs: Enable NetFlow v9 or IPFIX on perimeter and internal switches/routers, or enable VPC Flow Logs in AWS/Azure/GCP. Key fields: src_ip, dst_ip, dst_port, packets, bytes, flow_duration. A single source IP connecting to many destination IPs or ports in a short window is a primary scan indicator.
• Cloud — AWS CloudTrail / Azure Activity Logs / GCP Cloud Audit Logs: Enable all management and data plane logging. Look for API calls such as AWS DescribeInstances, DescribeSecurityGroups, ListBuckets that enumerate cloud-hosted services at scale from a single identity in a short time window.
• Container Environments — Container Runtime Logs: Enable audit logging on the container runtime (Docker daemon logs, Kubernetes audit logs via kube-apiserver --audit-log-path). Watch for scan tools spawned inside containers or kubectl exec sessions that launch network utilities.

Key Indicators

• Known scanner process names: In process creation logs (Windows Event ID 4688, Sysmon Event ID 1, Linux auditd), check process.name or Image for values including nmap, masscan, zmap, rustscan, netcat (as nc or ncat), angry ip scanner, unicornscan, nbtscan, arp-scan.
• Suspicious command-line patterns on Windows: In Event ID 4688 CommandLine field or Sysmon CommandLine, look for: Test-NetConnection, portqry, telnet * * (with an IP and port), nmap, arp -a combined with subsequent lateral movement indicators, or PowerShell one-liners like 1..1024 | ForEach-Object { ... } Test-NetConnection.
• Suspicious command-line patterns on Linux/macOS: In auditd or ESF logs, watch cmdline for nmap -sV, nmap -sS, masscan, nc -zv (zero-I/O mode — classic port probe), netstat -an followed quickly by outbound connections, dns-sd -B _ssh._tcp, dns-sd -B _smb._tcp.
• High fan-out network connections: In NetFlow or Sysmon Event ID 3 data, a single src_ip making connections to more than 20 unique dst_ip addresses or more than 15 unique dst_port values within a 60-second window is a strong scan indicator. Check DestinationPort patterns — sequential port numbers or a list matching common vulnerability scanner port lists (22, 23, 25, 80, 443, 445, 1433, 3306, 3389, 5985, 8080, 8443).
• Unexpected parent process relationships: In Sysmon Event ID 1 or auditd, flag when nmap, masscan, or nc have a parent process of cmd.exe, powershell.exe, bash, or python that was itself spawned by a web server process (w3wp.exe, apache2, nginx, tomcat) — this suggests post-exploitation scanning from a compromised service.
• Scanner tool written to disk: In Sysmon Event ID 11 (FileCreate) or auditd open syscall logs, flag creation of files named nmap.exe, masscan.exe, rustscan, or files with known scanner tool hashes in world-writable directories (C:\Windows\Temp\, /tmp/, /dev/shm/).
• Cloud API enumeration burst: In CloudTrail logs, check eventName for DescribeInstances, DescribeNetworkInterfaces, DescribeSecurityGroups, GetBucketAcl called more than 50 times within 5 minutes from a single userIdentity.arn or sourceIPAddress — especially from an IP not matching the user’s normal access pattern.
• mDNS/Bonjour enumeration on macOS: In Unified Logs or EDR telemetry, watch for process.name = dns-sd with arguments containing -B flag and service type strings like _ssh._tcp, _smb._tcp, _vnc._tcp, or _rdp._tcp.

Detection Logic

Rule 1 — Known Scanner Process Execution: Broad detection of any recognized scanning tool launched on an endpoint.
IF process.name IN ["nmap", "nmap.exe", "masscan", "masscan.exe", "rustscan", "zmap", "unicornscan", "nbtscan", "arp-scan"] AND event.type = "process_start" AND NOT parent_process.name IN ["chef-client", "puppet", "ansible-runner", "qualys-scan-agent"] THEN alert(severity=HIGH)

This catches direct invocation of well-known external scanners. Expected volume: low in most enterprise environments; any alert warrants investigation. Primary false positive source is authorized vulnerability scanning agents — tune by excluding those parent processes or their specific service account usernames.

Rule 2 — PowerShell or Bash Port Probe Loop: Detects living-off-the-land scanning via built-in scripting engines.
IF process.name IN ["powershell.exe", "pwsh.exe", "bash", "sh", "python3", "python"] AND (process.command_line CONTAINS "Test-NetConnection" OR process.command_line CONTAINS "nc -z" OR process.command_line CONTAINS "ncat -z" OR process.command_line CONTAINS "/dev/tcp/") AND NOT user.name IN [approved_scanner_service_accounts] THEN alert(severity=HIGH)

Catches adversaries using native scripting languages to probe ports, avoiding dropped scanner binaries. Volume is medium — some IT automation scripts legitimately use Test-NetConnection, so tune aggressively using the service account and parent process exclusions described in tuning guidance.

Rule 3 — High Fan-out Network Connection Burst (Flow-based): Detects scan behavior via volume anomaly in network telemetry.
IF COUNT(DISTINCT dst_ip) > 20 OR COUNT(DISTINCT dst_port) > 15 WITHIN 60 seconds WHERE src_ip = same_host AND NOT src_ip IN [authorized_scanner_ips] AND NOT dst_ip IN [monitoring_targets] THEN alert(severity=MEDIUM)

Works against both internal and egress scanning. This is the most reliable detection for scanners that rename their binaries or use uncommon tools. Expected volume is medium — vulnerability scanners, asset management tools, and monitoring probes will trigger this. Maintain a strict allowlist of scanner source IPs and exclude them.

Rule 4 — Scanner Tool Dropped and Executed from Temp Directory: High-precision detection of attacker staging a scanner.
IF file.path MATCHES "(C:\\Windows\\Temp|C:\\Users\\.*\\AppData\\Local\\Temp|/tmp/|/dev/shm/).*" AND file.name IN ["nmap.exe", "masscan.exe", "rustscan", "nc.exe", "ncat.exe"] AND WITHIN 300 seconds process.executable = file.path AND process.name = file.name THEN alert(severity=CRITICAL)

This is a high-confidence, low-noise rule: legitimate scanners are not dropped into temp directories and immediately executed. Any hit should be treated as a confirmed threat. Expected volume: very low, close to zero in a well-managed environment — escalate immediately.

Tuning Guidance

• Authorized vulnerability scanners (Tenable Nessus, Qualys, Rapid7 InsightVM, OpenVAS): These generate massive volumes of scan traffic that will trigger rules 1 and 3. Exclude by creating an allowlist of scanner appliance IP addresses in your SIEM lookup table and excluding them from flow-based rules. Also exclude the specific service account or host name the scanner agent runs under in process-based rules: e.g., user.name IN ["nessus_svc", "qualys_agent"] or src_ip IN [scanner_ip_allowlist].
• IT monitoring and SNMP polling tools (SolarWinds, PRTG, Nagios, Zabbix): Network monitoring platforms continuously probe hosts and services. Their poller IPs should be in your flow-based exclusion list. Check that these tools are running from expected hosts and service accounts — if the same tool name appears from an unexpected host, that is a red flag and should not be excluded.
• Software deployment and configuration management tools (Ansible, Puppet, Chef, SCCM): These tools routinely use Test-NetConnection, SSH probes, and port checks during playbook execution. Exclude by parent_process.name IN ["ansible-runner", "puppet", "chef-client"] or by the service account they run under.
• Developer workstations running Docker or Kubernetes locally: Developers frequently use nmap or nc for debugging containerized applications. Consider scoping endpoint detection rules to server-class systems and excluding known developer workstation hostnames or OUs, while still alerting on these behaviors in server, cloud, and production environments.
• macOS Bonjour/mDNSResponder normal operation: mDNSResponder runs continuously on macOS hosts and generates high volumes of service advertisement traffic. Only alert when dns-sd is invoked interactively by a user (i.e., parent is a shell like bash or zsh) rather than as a background daemon. Filter by checking that process.parent.name NOT IN ["launchd", "mDNSResponder"].

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Navigate directly to the raw log source (Sysmon Event ID 1 in Windows Event Viewer or your SIEM, auditd logs in /var/log/audit/audit.log, or NetFlow records) and confirm the original event exists with the expected fields populated — rule out a SIEM parsing error or miscorrelated event before proceeding.
2. Identify the affected host and user: Extract the host.name, user.name, and user.domain fields from the alert event; cross-reference the user account in Active Directory or your IdP to determine if the account is a standard user, service account, or privileged/admin account — privileged account involvement immediately raises severity.
3. Pull the full command-line and parent process chain: In Sysmon (Event IDs 1 and 4688) or EDR telemetry, retrieve the complete CommandLine, ParentImage, ParentCommandLine, and ParentProcessId fields; if the parent is a web server, document management system, or scheduled task, treat this as a likely post-exploitation scenario and escalate immediately.
4. Check for network connections and files written to disk: Query Sysmon Event ID 3 (NetworkConnect) and Event ID 11 (FileCreate) for the same ProcessGuid and host within a ±10 minute window around the alert timestamp; look for outbound connections to many unique IPs or ports, and check if scanner tools or output files (e.g., scan_results.txt, output.xml) were written to disk in temp or unusual directories.
5. Assess the scope of scanning activity: Query NetFlow or VPC Flow Logs for all traffic sourced from the affected host’s IP in the 30 minutes surrounding the alert; determine how many unique destination IPs and ports were contacted, whether the scanning reached outside the local subnet, and whether any of those destination IPs subsequently made new inbound connections back to internal hosts (which would suggest a port was open and exploited).
6. Look for lateral movement from this host: In Windows Security Event logs, search for Event IDs 4624 (successful logon) and 4648 (explicit credential use) sourced from the affected host after the scan window; on Linux, check /var/log/auth.log or journalctl -u sshd for SSH sessions initiated from the host — a scan immediately followed by a logon to a scanned host strongly indicates active lateral movement.
7. Escalation decision: If the scanning process was spawned by a non-user-interactive parent (web server, service, scheduled task), if scanner tools were dropped into temp directories, if scan results were exfiltrated or used to authenticate to other hosts, or if the account is privileged — declare a confirmed incident and escalate to Tier 2 or IR. If the scanning came from a known admin user with a plausible business reason, a documented change ticket, or an authorized scanner appliance IP that slipped past the exclusion list, document as a false positive and update your tuning rules.

Response Playbook

Containment

• Isolate the affected host — but keep it powered on: Use your EDR console (CrowdStrike Network Containment, SentinelOne Network Quarantine, Microsoft Defender for Endpoint Isolate Device) to cut the host off from the network while preserving the running process state and memory for forensic capture. Do not shut down or reimage before imaging volatile memory.
• Disable the affected user account immediately: In Active Directory, run Disable-ADAccount -Identity [username] or disable via the Azure AD / Entra ID portal. For cloud IAM, detach all policies from the IAM user or role using aws iam detach-user-policy / Azure RBAC role removal. This prevents the attacker from reusing the account even if they have the credentials.
• Block identified scanner source IPs and any contacted C2 infrastructure at the perimeter: Submit the affected host’s IP and any external destination IPs identified in the scan traffic to your firewall and proxy team for immediate block. If using a cloud WAF or security group, update the egress rules to deny outbound from the compromised instance CIDR.
• Kill the malicious scanning process: If the host is not yet isolated, use your EDR to terminate the process by PID. On Windows, Stop-Process -Id [PID] -Force; on Linux, kill -9 [PID]. Document the PID, process name, and hash before terminating.
• Revoke active sessions and tokens: Force sign-out of all active sessions for the affected user in your IdP (Azure AD: Revoke Sign-in Sessions; Okta: Clear User Sessions). For cloud environments, rotate or revoke any IAM access keys or OAuth tokens associated with the identity using aws iam delete-access-key or the equivalent cloud console action.

Eradication

• Remove scanner tools and dropped payloads: Search the affected host for all files created in the window surrounding the alert — use Sysmon Event ID 11 logs or EDR file timeline. Delete any identified scanner binaries, output files, or scripts. Hash each file before deletion and submit hashes to your threat intelligence platform.
• Hunt for persistence mechanisms added after the scan: Check for new scheduled tasks (schtasks /query on Windows, crontab -l and /etc/cron.* on Linux), new or modified services (Get-Service | Where-Object {$_.StartType -eq "Automatic"}), and suspicious registry run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) added in the timeframe of the incident. Remove any entries not present in your configuration baseline.
• Reset credentials for all accounts involved: Force password resets for the affected user and any accounts whose credentials may have been visible in memory on the compromised host (use a memory forensics tool like Volatility if the host was imaged). For service accounts, rotate passwords in your password vault and update all consuming services.
• Check lateral movement targets for backdoors: For each destination host that received a connection from the compromised host after the scan, run the same persistence checks (scheduled tasks, new services, crontabs, new local admin accounts) and review authentication logs for any accounts added or privilege changes made.
• Rotate any secrets or API keys exposed on the host: Review environment variables, configuration files, and application secrets accessible to the compromised process. Rotate any database credentials, API tokens, cloud access keys, or certificates that could have been read from disk or memory during the attacker’s access window.

Recovery

• Verify the host is clean before reconnecting: Run a full AV/EDR scan and compare the current system state against a known-good configuration baseline or golden image snapshot. If confidence in cleanliness is below 100%, reimage the host from a validated baseline rather than attempting cleanup — the risk of a missed backdoor outweighs the operational cost of reimaging.
• Re-enable the user account only after confirming no persistence remains: Before restoring access, confirm with the user’s manager that the account compromise is understood, reset all credentials, and verify MFA enrollment is current. Re-enable via AD or IdP only after eradication is confirmed by the IR lead.
• Monitor the affected host and user for 72 hours post-remediation: Create a temporary high-sensitivity detection rule in your SIEM scoped to the affected host’s IP and the user’s identity for 72 hours. Set alerts for any process execution, new outbound connections, or authentication events involving those entities and route them directly to the responding analyst.
• Document the full attack timeline and conduct a lessons-learned review: Record every event timestamp, tool used, accounts affected, hosts contacted, and actions taken in your ticketing system (ServiceNow, Jira, etc.). Schedule a post-incident review within five business days to identify gaps in detection coverage or response playbook that this incident exposed.
• Update detection rules with new IOCs discovered during the investigation: Add any newly identified scanner binary hashes, C2 IPs, unique command-line patterns, or file paths to your SIEM detection rules, EDR custom IOC lists, and threat intelligence platform. If a gap in an existing rule allowed this to go undetected initially, update the rule logic and document the change in your detection engineering backlog.