Overview

System Network Configuration Discovery (T1016) is a technique where adversaries enumerate network settings on a compromised host — collecting IP addresses, MAC addresses, routing tables, ARP caches, and interface configurations using built-in OS utilities. Attackers use this information to understand the local network topology, identify additional targets, determine subnet boundaries, and plan lateral movement or data exfiltration routes.

Because this technique relies almost entirely on legitimate, built-in system tools (living-off-the-land), it blends naturally into normal administrative activity and is easy to overlook. Every security team needs detection coverage here because T1016 is a near-universal step in post-exploitation — if you catch it early, you may be catching an adversary before they pivot deeper into your environment.

Attacker Perspective

After gaining initial access, attackers routinely run network discovery commands to answer a critical question: where am I, and what can I reach from here?

• Mapping network interfaces and IPs: Adversaries run ipconfig /all on Windows or ifconfig -a / ip addr show on Linux to identify all bound IP addresses, including secondary NICs that may connect to otherwise isolated network segments.
• Routing table enumeration: Commands like route print (Windows) or netstat -rn / ip route show (Linux/macOS) reveal static routes that can expose paths to sensitive VLANs, OT networks, or cloud subnets not directly visible from the internet.
• ARP cache harvesting: Running arp -a gives a snapshot of recently contacted hosts on the same subnet — a fast, passive way to discover live targets without generating new network traffic.
• ESXi hypervisor enumeration: On VMware ESXi hosts, adversaries use esxcli network nic list and esxcli network ip interface ipv4 get to map hypervisor interfaces before deploying ransomware or targeting VM datastores.

This technique is attractive because it uses tools that are already present on every operating system, requires no additional tooling to download, and generates minimal noise compared to active network scanning.

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: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This populates the CommandLine field in Event ID 4688, which is essential for detecting discovery commands.
• Windows — Sysmon (Event ID 1): Deploy Sysmon with a configuration that captures process creation. Sysmon Event ID 1 provides richer fields including ParentImage, ParentCommandLine, User, and Hashes. Use the SwiftOnSecurity or Florian Roth Sysmon config as a baseline.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures PowerShell-based enumeration such as Get-NetIPConfiguration, Get-NetRoute, and Get-NetAdapter.
• Linux — Auditd Process Execution: Add auditd rules to capture execution of discovery binaries:
  -a always,exit -F arch=b64 -S execve -F path=/sbin/ip -k network_discovery,
  -a always,exit -F arch=b64 -S execve -F path=/bin/netstat -k network_discovery,
  -a always,exit -F arch=b64 -S execve -F path=/sbin/ifconfig -k network_discovery,
  -a always,exit -F arch=b64 -S execve -F path=/sbin/arp -k network_discovery,
  -a always,exit -F arch=b64 -S execve -F path=/sbin/route -k network_discovery.
  Alternatively, use auditd with EXECVE syscall rules and forward logs to your SIEM via rsyslog or Filebeat.
• Linux — Sysdig / Falco (optional but recommended): Falco rules can alert on discovery command execution with process and user context. Enable the default Falco ruleset which includes rules for shell spawned by parent processes and reconnaissance commands.
• macOS — Endpoint Security Framework / Unified Log: Use an EDR agent (e.g., CrowdStrike, SentinelOne, Jamf Protect) that hooks into the Apple Endpoint Security Framework to capture process execution. Alternatively, enable OpenBSM auditing: add -a lo,ex to /etc/security/audit_control to capture execution events.
• ESXi — Shell Command Logging: Enable ESXi Shell and SSH logging. ESXi logs shell commands to /var/log/shell.log and /var/log/hostd.log. Forward these via syslog: configure esxcli system syslog config set --loghost=udp://your-siem:514 and esxcli system syslog reload.
• EDR Telemetry (all platforms): If you have an EDR deployed (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Carbon Black), process execution telemetry from the EDR is often higher fidelity than native OS logs and should be your primary detection source. Ensure process tree and command-line capture are enabled in the EDR policy.

Key Indicators

• Windows — ipconfig execution: Source: Sysmon Event ID 1 or Security Event ID 4688. Field: Image = C:\Windows\System32\ipconfig.exe, CommandLine contains /all. Suspicious when ParentImage is cmd.exe, powershell.exe, or wscript.exe and the parent was spawned by a non-administrative user or an unusual process.
• Windows — arp execution: Source: Sysmon Event ID 1. Field: Image = C:\Windows\System32\arp.exe, CommandLine = arp -a. Suspicious when parent process is cmd.exe or powershell.exe launched from a user session outside business hours or from an unusual working directory.
• Windows — route print execution: Source: Sysmon Event ID 1. Field: Image = C:\Windows\System32\route.exe, CommandLine contains print. Especially suspicious if chained within seconds of other discovery commands in the same process session.
• Windows — nbtstat execution: Source: Sysmon Event ID 1. Field: Image = C:\Windows\System32\nbtstat.exe, CommandLine contains -a, -A, -n, or -r.
• Windows — PowerShell network discovery: Source: Event ID 4104 (Script Block Logging). Field: ScriptBlockText contains Get-NetIPConfiguration, Get-NetRoute, Get-NetAdapter, Get-NetIPAddress, or [System.Net.NetworkInformation.NetworkInterface].
• Discovery command burst — multiple tools in short window: Source: Sysmon Event ID 1. Pattern: Three or more of the following processes spawned from the same parent PID within 60 seconds: ipconfig.exe, arp.exe, route.exe, nbtstat.exe, netstat.exe, whoami.exe, net.exe, hostname.exe. This burst pattern is a strong indicator of automated post-exploitation framework activity (Cobalt Strike, Metasploit, etc.).
• Linux — ip/ifconfig/arp/route executed by anomalous user: Source: Auditd EXECVE records with key=network_discovery. Fields: auid (audit UID) is not a known admin account, exe is one of /sbin/ip, /bin/netstat, /sbin/ifconfig, /sbin/arp, /sbin/route, and ppid resolves to a web server process (e.g., apache2, nginx, tomcat) — indicating web shell or RCE exploitation.
• ESXi — esxcli network enumeration: Source: ESXi /var/log/shell.log. Pattern: Log message contains esxcli network nic list or esxcli network ip interface ipv4 get or esxcli network ip route list. Any execution of these commands from an interactive shell session outside a change window should be treated as suspicious.
• Output redirection to file: Source: Sysmon Event ID 1 (Windows) or Auditd (Linux). Pattern: CommandLine contains ipconfig /all > C:\Users\Public\ or ip addr show > /tmp/ — attackers frequently redirect discovery output to a file for later exfiltration.

Detection Logic

Rule 1 (Broad — High Sensitivity): Single execution of a network discovery binary by any process
IF process.name IN ["ipconfig.exe", "arp.exe", "route.exe", "nbtstat.exe", "netstat.exe", "ifconfig", "ip"] AND event.type = "process_start" AND NOT user IN [known_admin_accounts] AND NOT parent_process.name IN ["svchost.exe", "services.exe", "msiexec.exe"] THEN alert(priority=LOW)

This rule casts a wide net and will generate significant volume in most environments. Use it for baselining and to identify which accounts and processes regularly run these tools — feed the results into your exclusion list. Do not use this as a high-priority alert in isolation; it is most useful when correlated with other signals.

Rule 2 (Medium — Discovery Command Burst): Multiple network discovery tools executed in rapid succession from the same parent
IF COUNT(process.name IN ["ipconfig.exe", "arp.exe", "route.exe", "nbtstat.exe", "netstat.exe", "whoami.exe", "hostname.exe", "net.exe"]) >= 3 WHERE parent_process.id = same_parent_pid AND event.time WITHIN 60 seconds AND NOT user IN [known_admin_accounts] THEN alert(priority=HIGH)

This rule targets automated post-exploitation toolkits (Cobalt Strike, Metasploit, Sliver) that run a standard enumeration checklist in sequence. The burst pattern significantly reduces false positives compared to single-command rules. Expected volume: low in most environments — treat every hit as worth investigating.

Rule 3 (High Precision — Suspicious Parent): Network discovery spawned by an unusual or high-risk parent process
IF process.name IN ["ipconfig.exe", "arp.exe", "route.exe", "ifconfig", "ip", "netstat"] AND parent_process.name IN ["cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "java.exe", "python.exe", "python3", "ruby", "perl", "php", "bash", "sh"] AND grandparent_process.name IN ["w3wp.exe", "httpd", "apache2", "nginx", "tomcat9", "node"] THEN alert(priority=CRITICAL)

This rule specifically targets network discovery initiated through a web shell or server-side RCE exploitation chain. A web server spawning a shell that then runs network enumeration tools is a near-certain indicator of active compromise. Expected volume: very low — should be treated as a confirmed incident pending investigation.

Rule 4 (High Precision — ESXi Targeting): ESXi esxcli network enumeration commands in shell logs
IF log_source = "esxi_shell_log" AND message MATCHES "esxcli network (nic list|ip interface|ip route)" AND NOT session.user IN [approved_esxi_admins] AND NOT event.time WITHIN [approved_change_window] THEN alert(priority=CRITICAL)

ESXi hypervisors are high-value targets for ransomware groups. Any esxcli network enumeration outside an approved maintenance window or by an unapproved account should trigger an immediate response. Expected volume: near zero in a well-managed environment.

Tuning Guidance

• IT and system administrators running manual checks: Sysadmins legitimately run ipconfig, route print, and arp -a regularly during troubleshooting. Build a baseline of which admin accounts run these commands on which hosts, then add exclusions: user IN [sysadmin_group] AND host IN [admin_workstations]. Do not exclude admin accounts on servers they do not normally manage.
• Configuration management and monitoring agents: Tools like SCCM, Ansible, Puppet, Chef, SolarWinds, and Nagios may execute network commands as part of inventory collection or health checks. Identify the service account or process name used, and exclude: parent_process.name IN ["ccmexec.exe", "ansible", "puppet", "solarwinds.businesslayerhost.exe"] paired with the specific expected command lines.
• Security scanning tools: Vulnerability scanners (Tenable Nessus, Qualys, Rapid7) running authenticated scans may trigger these rules from a dedicated scanner account. Exclude: source_host IN [scanner_ip_list] OR user IN [scanner_service_accounts]. Scope this exclusion tightly to the scanner’s scheduled window if possible.
• Network device baseline communication: On Linux servers, monitoring daemons like collectd or custom scripts may poll ip route show or netstat for metrics. Review the parent process and script path, then exclude: parent_process.name = "collectd" AND process.name = "ip" with the specific expected argument pattern.
• Developer and build environments: CI/CD pipelines and developer workstations may execute network checks during build or test processes. If your Rule 1 generates significant noise from developer machines, scope the rule to server and production asset groups only using a host classification tag or asset list.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Pull the original event from your SIEM using the event ID, hostname, and timestamp from the alert. Confirm the CommandLine, User, ParentImage, and ProcessId fields are populated and consistent — a missing or empty CommandLine field on a Windows host may indicate audit policy is not fully configured, not that the event is invalid.
2. Identify the affected host and user — flag if privileged. Determine whether the user account is a standard user, local admin, or domain admin using your identity provider (Active Directory, Azure AD, Okta). Check whether the host is a workstation, server, domain controller, or jump host — discovery activity on a domain controller or file server is significantly higher risk than on a standard workstation.
3. Pull the full command-line and parent process chain. In your EDR console (CrowdStrike Process Tree, MDE Device Timeline, SentinelOne Storyline), trace the full ancestor chain: what spawned the discovery tool, what spawned that parent, and what spawned the grandparent. Look specifically for a chain that leads back to an Office document, script engine (wscript.exe, mshta.exe), web server process, or a remotely executed service — any of these indicates exploitation rather than admin activity.
4. Check for network connections and files written to disk around the same time. Query your EDR or Sysmon Event ID 3 (network connection) and Event ID 11 (file creation) for the same host within a ±5 minute window of the discovery event. Look for outbound connections to external IPs on uncommon ports, and for output files written to world-writable directories like C:\Users\Public\, C:\Windows\Temp\, or /tmp/ — these suggest the attacker captured and staged output for exfiltration.
5. Review the full timeline of activity on this host for the preceding 24–48 hours. In your EDR, pull all process execution, file creation, registry modification, and network connection events for the host. Look for the initial access vector: was there a phishing email opened in Outlook prior to this? A new scheduled task or service created? A logon from an unusual IP (query Windows Security Event ID 4624 for logon type and source IP)? This context determines whether you are looking at the beginning or middle of a compromise.
6. Look for lateral movement originating from this host. Query your SIEM for Windows Security Event ID 4624 (logon type 3 — network logon) or 4648 (explicit credential use) where source_workstation or source_ip matches the affected host, occurring after the discovery activity. Also check for SMB connections in network logs (destination port 445) and RDP connections (destination port 3389) from this host to internal targets — network discovery almost always precedes lateral movement.
7. Escalation decision — what separates a confirmed incident from benign activity. Escalate to a confirmed incident if any of the following are true: (1) the parent process chain includes an exploitation indicator (web server, script engine, Office app); (2) a discovery command burst of three or more tools fired within 60 seconds; (3) output was redirected to a file in a staging directory; (4) lateral movement events were identified in the following hour; (5) the activity occurred on a privileged host (DC, ESXi, jump server) outside business hours. If none of these apply and the user is a known admin on a managed host, document findings and close as a likely false positive, but update your baseline exclusions.

Response Playbook

Containment

• Isolate the host from the network immediately, but leave it powered on. Use your EDR’s network isolation feature (CrowdStrike: “Contain Host,” MDE: “Isolate Device,” SentinelOne: “Network Quarantine”) to cut off all network communication except the EDR management channel. Do not shut down the host — volatile memory (RAM) may contain attacker tools, injected shellcode, or decrypted credentials that are lost on power-off.
• Disable the affected user account. In Active Directory, set the account to disabled immediately: Disable-ADAccount -Identity <username>. In Azure AD / Entra ID, use the portal or Set-AzureADUser -ObjectId <UPN> -AccountEnabled $false. If the account is a service account, coordinate with the application owner before disabling — identify an alternative or temporary credential first.
• Terminate any active sessions for the affected account. Force sign-out of all active sessions in Azure AD (Entra ID portal → User → Revoke Sessions). For on-premises sessions, use query session /server:<hostname> to identify active RDP sessions and terminate with logoff <sessionid> /server:<hostname>. Invalidate any Kerberos tickets by resetting the account password twice.
• Block any identified C2 IPs or domains at the perimeter. If network connections to external IPs were identified in step 4 of the investigation, push block rules to your perimeter firewall and DNS filtering solution (e.g., Cisco Umbrella, Zscaler, Palo Alto EDL) immediately. Document the IOCs for sharing with threat intelligence platforms.
• Kill any identified malicious processes on the host. If isolation is not immediately possible, use your EDR’s remote process kill capability to terminate the malicious process. On Windows, you can also use taskkill /F /PID <pid> via a remote management tool, but EDR is preferred to preserve the kill chain audit trail.

Eradication

• Search for and remove persistence mechanisms on the affected host. Review Windows Security Event ID 4698 (scheduled task created), Sysmon Event ID 12/13 (registry modification), and Event ID 7045 (new service installed) from the past 7 days. Check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, scheduled tasks in C:\Windows\System32\Tasks\, and startup folders. Remove any entries not attributable to known-good software.
• Identify and delete any attacker-dropped tools or payloads. Check directories commonly used for staging: C:\Users\Public\, C:\Windows\Temp\, C:\ProgramData\, and user profile AppData\Local\Temp\ on Windows; /tmp/, /var/tmp/, and /dev/shm/ on Linux. Hash any suspicious files and query them against VirusTotal before deleting — preserve copies in an isolated malware repository for analysis.
• Reset credentials for all accounts that executed activity on the affected host. Reset the password for the compromised user account and any other accounts that logged into the host during the suspected compromise window (check Event ID 4624 logon history). If a service account was involved, rotate its password in both Active Directory and any connected application configuration files or vaults.
• Check for backdoors on any lateral movement targets. For any hosts identified in investigation step 6 as lateral movement targets, run a targeted threat hunt: look for the same discovery command burst pattern, new scheduled tasks, new local admin accounts (Event ID 4720 + 4732), and Sysmon Event ID 3 connections back to the original compromised host. Isolate and re-examine any hosts showing indicators.
• Rotate any secrets that may have been exposed on the compromised host. If the host stored API keys, service account passwords, certificate private keys, or cloud credentials (e.g., AWS IAM keys in environment variables or ~/.aws/credentials), rotate all of them immediately regardless of whether direct access was confirmed. Assume anything accessible on the host was read.

Recovery

• Verify the host is clean before reconnecting to the network — re-image if confidence is low. Run a full EDR scan and review the scan results for any remaining detections. If you cannot confirm with high confidence that all attacker presence has been removed (especially if you found a rootkit, kernel-level implant, or evidence of LSASS dumping), re-image the host from a known-good baseline rather than attempting manual cleanup. A compromised host that is returned to production without full confidence is a persistent risk.
• Re-enable the affected user account only after confirming no persistence remains. Before re-enabling, confirm that all identified persistence mechanisms have been removed, the account password has been reset, and MFA has been verified or re-enrolled. Brief the user on the incident — if social engineering was involved in initial access, the user needs to be aware.
• Monitor the previously affected host and user account for 72 hours post-remediation. Create a temporary high-sensitivity watchlist rule in your SIEM scoped to the affected host and user: alert on any execution of discovery tools, new outbound connections to external IPs, new scheduled tasks, or logons outside business hours. This catches re-compromise or any persistence you may have missed during eradication.
• Document the full incident timeline and conduct a lessons-learned review. Write up a concise incident report covering the initial detection, investigation findings, attacker TTPs (map to ATT&CK), containment and eradication actions, and total dwell time. Share relevant IOCs (file hashes, C2 IPs, domains, user agent strings) with your threat intelligence team and industry ISACs as appropriate.
• Update your detection rules and exclusion lists based on the findings. If the attacker used a novel command-line pattern or parent process chain not covered by your existing rules, add it. If the alert was a false positive, add a scoped exclusion using the specific process, user, and host attributes — avoid overly broad exclusions that could blind future detections of the same technique.