How T1016 system network configuration discovery reveals your network layout
When a SOC analyst sees a host or device listing its own network settings, that single command may be the first visible sign that someone is mapping the environment. T1016 System network configuration discovery is the technique in which an adversary collects network configuration details such as interfaces, addresses, routes, DNS settings and neighbor information so it can decide where to move next. It sits under the Discovery tactic (TA0007), which MITRE describes as the point where the adversary is trying to figure out your environment. The technique covers 2 sub-techniques, and it typically appears early in intrusions on ESXi hosts, Linux and macOS systems, and network devices, often shortly after initial access. Because the same queries are run by administrators during normal work, the detection question is less about the command itself and more about who ran it, from where, and whether it fits the host's role.
For a defender, the practical consequence is that T1016 is a high-value early warning. An intruder who has just gained a foothold on a hypervisor or a Linux server needs to know which subnets are reachable, which management networks exist and how traffic leaves the segment. Each of those answers shapes lateral movement and command and control choices, so the discovery step tends to cluster with other Discovery activity. Plan your detections around the host roles that should never run these queries, such as a hypervisor management interface, a jump host or a database server, and treat unusual invocations there as high priority. Confirm the exact sub-technique IDs and their current definitions against the target release before you write mappings.
Map your detections to ATT&CK v20.0, the version this page targets, and record that version alongside each rule. MITRE publishes ATT&CK content as STIX 2.1 bundles in the attack-stix-data repository, and releases can rename, deprecate or revoke techniques, so a mapping that is not version-stamped can silently drift. Before relying on any detection for T1016, confirm the sub-techniques, data components and mitigations in the v20.0 bundle, and check the ATT&CK updates page for changes since the version your current rules were written against. Ask your detection engineering team to keep this version stamp in every rule's metadata so audits and tuning reviews can trace each alert to its source.
Which telemetry shows T1016 activity and which open-source tool collects it
This table maps each platform where T1016 network configuration checks commonly occur to the primary telemetry source, the secondary signal and the open-source collector that can gather it. Read each row as a starting hypothesis: confirm that the named log source is enabled and forwarded on your own hosts before relying on it for alerting.
| Platform | Primary telemetry (Process Creation or Command Execution) | Secondary signal (File Access) | Open-source collector and what to confirm |
|---|---|---|---|
| Linux servers | Process execution records from Linux audit (auditd) or EDR-style process events, including command arguments where enabled | Reads of network configuration files by non-administrative processes | Wazuh agent forwards auditd and syslog. Confirm that execve auditing is on and that command arguments are captured. |
| macOS endpoints | Unified log and process execution events for network utilities invoked from user or script contexts | Access to network preference or configuration files outside normal admin tooling | Wazuh agent and Velociraptor artifacts. Confirm which process and file events your macOS build exposes to the agent. |
| ESXi hosts | ESXi shell command history and process activity forwarded through syslog | Access to host network configuration files under the host configuration tree | Wazuh or a syslog relay to a central collector. Confirm that ESXi shell and SSH access events are logged and retained. |
| Network devices (routers, switches, firewalls) | Device command accounting or AAA logs showing show and display commands run by an operator | Configuration backup or export events, where the device produces them | Syslog into Wazuh or Security Onion. Confirm which commands the device logs and whether it logs read-only commands at all. |
| Network traffic for configuration queries | Not a primary source for this technique | Zeek connection and protocol logs showing management protocol sessions to network devices | Zeek and Security Onion. Confirm sensor placement covers management segments and that protocol parsers are enabled. |
| Incident triage on suspect hosts | Process history and command artifacts collected on demand | Configuration file hashes and modification times collected on demand | Velociraptor hunts and artifacts. Confirm the artifact set and collection scope with your incident response plan before running hunts. |
| Sysmon-equivalent process logging on Windows-hosted tooling | Process creation events for network utilities launched from management or scripting hosts | Not the primary signal for this technique | Wazuh agent with Windows event collection. Confirm that process creation auditing and command line capture are enabled in your Windows baseline. |
Detection logic for T1016 that SOC teams can tune
T1016 System network configuration discovery is usually a short burst of routine-looking queries, so detection depends on context: who ran the command, from where, and how often. The cards below describe four detection ideas in words, with the tuning levers and false positive sources that SOC teams should baseline before alerting.
Configuration queries by non-administrative accounts
This rule watches process creation events for network configuration query utilities on Linux, macOS and ESXi hosts, then filters for accounts that do not normally run them. Start by building an allow list of administrative and service accounts from a two to four week baseline of your own logs. Tune the rule on the account, host group and time window, not on the utility name alone. Expected false positives include monitoring agents, configuration management runs and admin scripts that query interfaces during provisioning. Confirm each exception with its owner before adding it.
Same utilities from unusual parents
This rule flags network configuration utilities whose parent process is not a shell, terminal session or known management agent. Interactive administrators usually launch these tools from a login shell, while a web service, database process or scheduled job launching them is a stronger signal. Build the list of expected parents per host role, and treat a parent change on the same host as a pivot for review. Expect false positives from configuration management tools, container health checks and backup agents that call network utilities as children. Document each approved parent so the exception stays auditable.
Bursts of queries from one host
This rule counts configuration queries per host within a short sliding window and alerts when the count exceeds the host's normal range. Discovery often produces several queries in quick succession across interfaces, routes and DNS settings, so a burst can be more telling than any single event. Set the window and threshold from observed history for each host class, since a jump host and a database server have very different norms. Common false positives include health checks, inventory scans and reboot sequences, which tend to run on predictable schedules. Correlate bursts with change tickets before escalating.
Device command logs from unexpected sources
This rule covers network device command logs, such as those from switches and routers, when a configuration show command comes from a source address outside the approved management subnets or jump hosts. Confirm first that your devices forward command accounting or syslog in a consistent format, since field names vary by vendor. Maintain an inventory of management sources and alert on any address that is not on it. Expect false positives from new monitoring servers, temporary contractor access and automation platforms that poll devices. Require a ticket reference or named owner for every new source before it joins the approved list.
How to validate the T1016 detection in a lab before production
This sequence proves that the T1016 detection fires on controlled discovery activity, with the fields analysts need, within an acceptable delay and without unmanaged noise. It ends with a documented record that supports the change decision and any later retest.
Agree scope and rules with the change board
The detection owner, the platform team and the change board agree in writing which hosts, platforms and accounts are in scope for the lab run, which Linux, macOS, ESXi and network device classes are covered, and which activity is permitted. They also agree a stop condition, the people who may halt the run, and the window in which the test host may generate alerts. The step is done when the change board signs off the written scope and the on-call analyst knows the run is expected. Confirm the actual window and approvers with your own change process, since no fixed timing is set here.
Prepare an isolated test host and baseline
Build a test host that matches the production build for the platform under test, with the same logging agents, audit configuration and forwarding path. Capture a baseline of the events already present before any scenario runs, so that normal administrative activity can be separated from the test. The step is complete when the baseline shows the expected process creation and command execution telemetry arriving in the SIEM with the host name and time zone set correctly.
Run a benign discovery scenario
The red team or an engineer runs an agreed, benign set of network configuration checks that an administrator might perform during routine work, documented as a script or runbook with each step listed in advance. This scenario tests whether the rule reacts to ordinary use. Record the start and end times, the account used and the exact list of actions taken. The step is complete when the run log matches the runbook line by line.
Run a controlled discovery scenario
The test team then executes a controlled scenario that performs the same category of network configuration discovery that the detection targets, following the scripted list agreed in step one. The scenario is run under a named test account so that the alert can be traced without ambiguity. The step is complete when the run log is saved alongside the timestamps, so the next steps can compare what was done with what was detected.
Confirm the alert fields and time to alert
For each scenario, check that the expected detection rule fires and that the alert contains the fields the analyst needs: host, user, process or command details, parent process and event time. Compare the alert time with the event time in the source logs and record the delay. The step is complete when every expected action produced an alert or a documented reason why it did not, and the observed delay is written down for the detection owner to review. Confirm the delay target with your own service expectations, since this sequence does not assign one.
Record false positives and analyst decisions
Review every alert raised during the baseline and benign runs, and label each one as true positive, benign true positive, false positive or unclear. Have the on-call analyst record the decision they would take and the triage notes they would write. The step is complete when each alert in the window has a recorded label and decision, and the list of false positive causes is passed to the detection owner for tuning.
Record evidence for the detection record
Store one record per rule version containing the rule identifier, the ATT&CK version it targets, the data source and data components used, the test host, the alert times, the analyst decisions and the scenario runbook. Keep the change board approval with it. The step is complete when the record can be handed to an auditor or a peer reviewer without further explanation, and it names the ATT&CK version so future mapping changes can be traced.
Tune the rule and retest
The detection owner adjusts the rule to reduce the false positives found, without removing coverage of the controlled scenario. The scenarios are then rerun on the same test host, and the results are compared with the first run. The step is complete when the retest shows the expected alerts still fire, the noisy cases are reduced, and a new evidence record is saved under the updated rule version before the rule is promoted to production.
Preventive controls that limit what T1016 reveals
Configuration discovery succeeds when an adversary can read network settings freely and move on from what they find. The mitigations below reduce what those reads reveal, how far an adversary can go with the answers, and how quickly a change in behavior is noticed. Each one needs confirmation against your own platforms, because applicability differs across ESXi, Linux, macOS and network devices.
Harden operating system configuration
Operating System Configuration (M1028) covers settings that limit what a local user or process can read about the host, such as network interface details, routing tables and resolver configuration. On Linux, macOS and ESXi hosts, ask platform owners which commands and files that run as unprivileged users expose network detail, and which can be restricted without breaking monitoring or management tooling. Confirm the change set against your own baseline before rollout.
Enable and review audit logging
Audit (M1047) does not stop configuration discovery, but it makes it visible. Confirm that process creation and command execution are logged on hosts and that those logs reach a central store with retention your incident process needs. Check whether network device logs record administrative sessions and show configuration views, since those are the events your analysts will need to reconstruct a discovery sequence.
Limit account privileges
User Account Management (M1018) reduces who can run the commands that produce configuration data. Review which service and interactive accounts can reach network interface, routing and firewall views on hosts and devices. Shared administrative accounts make discovery activity hard to attribute, so ask platform owners to confirm that each administrator has a named account with its own audit trail.
Segment networks to limit what is learned
Network Segmentation (M1030) restricts where an adversary can go once it has read a host's network configuration. Map which subnets, VLANs and management networks a given workload can reach. Information about one segment is far less useful when the routes and firewall rules to other segments are tightly scoped. Ask network owners to confirm that management interfaces are reachable only from designated administrative networks.
Prevent and block suspicious network activity
Network Intrusion Prevention (M1031) can block traffic patterns associated with follow-on activity that discovery often precedes, such as sweeps of management ports from hosts that do not normally make those connections. Confirm which sensor and rule set your team operates, whether it runs in blocking or alerting mode, and which rules were tuned for your environment so that legitimate administration is not disrupted.
Remove unused network tools and features
Disable or Remove Feature or Program (M1042) reduces the number of utilities and services that reveal network configuration. Inventory network diagnostic utilities, unused management agents and legacy protocols on each host image and network device. Remove what is not needed, and document the exceptions that operations depends on so that the removal does not break troubleshooting during an incident.
Triage steps when a T1016 alert fires
Start by fixing the identity of the actor and the host before anyone judges the alert. Record the account name, the source host, the session or login identifier and the time window of the process events that triggered the rule. Then confirm which person or service owns that account and whether the host is in your asset inventory. A network configuration query from an unknown account on a hypervisor management interface or a network device warrants a faster escalation than the same command from a named administrator's workstation. Keep the triage notes tied to the raw event, not to the rule's summary text, so that a later reviewer can reproduce your reasoning.
Next, test whether the activity matches an approved task. Ask the platform or network team whether a change ticket, a scheduled inventory job, a configuration backup or a monitoring agent was running in that window. Check the parent process and the execution path against your list of known management tools, and compare the command pattern with the baseline for that account and host class. If the match is a sanctioned tool, record the ticket or job identifier and tune the rule, not the logging. If nothing explains the activity, correlate the alert with authentication events and process creation around it: a new remote session, an unusual logon source or a privilege change shortly before the query raises the priority considerably.
Scope the account before you contain anything. List every host, hypervisor, switch, router and firewall the same account touched in the prior hours, and note which of those produced similar process or command execution events. Preserve evidence first: export the relevant logs from Wazuh or your SIEM, capture volatile state on the affected host where your procedure allows it, and snapshot or hash suspect files before any clean-up. Then decide on containment, such as disabling the account, restricting the source address or isolating one host, and escalate to the incident commander and, for regulated systems, to the compliance owner. Finally, write the decision, the evidence reviewed and the tuning request into the detection engineering backlog, so that the next analyst can close the same case faster.
How to rehearse T1016 detection and response in a private cyber range
A private range for this environment usually places a small set of Linux and macOS endpoints inside an isolated segment, with a telemetry agent on each host forwarding process and command records to a Wazuh manager, and a Security Onion sensor watching the segment for Zeek and Suricata records. The range should mirror production images, shells and administrator workflows so that the baseline is realistic for the client rather than generic. Illustrative injects include a scheduled inventory job run by a platform tool account (benign) and an interactive session from an unfamiliar account that enumerates interface and routing configuration in a short burst (suspicious). Good detection means a Sigma-derived rule raises an alert within the agreed window, the alert carries the host, user, parent process and command line fields the analyst needs, and the benign job is suppressed by a documented allowlist rather than by disabling the rule. Good response means the analyst confirms the account and session, isolates the host through the agreed playbook, preserves volatile evidence with Velociraptor, and records the timeline. Confirm with your team which macOS telemetry fields your agent actually collects before you set expectations for the exercise.
Hypervisor hosts and network devices produce different evidence from endpoints, so the range topology should include a management network, a small ESXi lab host or appliance, and a network device or emulator that forwards syslog to the SIEM. Log forwarding must be validated before the exercise, because many of these platforms send fewer command records than a general-purpose Linux host and detection may depend on the shell audit or syslog configuration available in the client's build. Illustrative benign inject: a scheduled backup or monitoring poll from a management host that reads interface configuration through the vendor's standard API. Illustrative suspicious inject: an administrative session from an unexpected source address that requests the same configuration in a sequence unlike the normal runbook. Good detection means the event reaches the SIEM with the device name, source address, account and command or API context, and that the alert fires within the window agreed for the exercise. Good response means the analyst verifies the management source, checks whether the session was authorized in the change record, restricts management access through the network controls in place, and reviews configuration integrity. Ask the vendor or your own engineers which audit records the platform writes by default and which need extra configuration.
This tab covers the handoffs that decide whether T1016 detection works in practice: alert routing, triage, escalation and closure across all platforms in the range. The topology should include the SIEM, the case management tool used by the SOC, a notification channel, and a documented on-call roster so that the exercise tests the people and process as well as the rules. Illustrative scenario: the same discovery pattern appears on a Linux host and on a network device within a short period, and the analyst must correlate the two rather than treat them as unrelated events. Good detection means that each source produces an alert with consistent field names, that the rule set is tagged to the ATT&CK technique and the ATT&CK version it targets, and that an analyst can find the alert from the case record without manual searching. Good response means triage starts within the agreed window, the analyst classifies the alert as benign, suspicious or confirmed, escalates according to the written criteria, and documents each decision for later review. Track whether the team reaches the same classification on repeated runs of the scenario. Ask the client which triage window and escalation thresholds they have approved in writing, because the exercise should measure against those commitments rather than assumptions.
Questions SOC leads ask about detecting T1016
How does T1016 detection logic differ from T1049 and T1018?
T1016 is about the adversary learning how a host or device is network-configured: interface addresses, routing tables, DNS resolvers, ARP entries and similar settings. T1049 targets active connections and sockets, and T1018 targets other reachable systems on the network. In practice, T1016 detections lean on process creation and command execution records for configuration-reading tools, while T1049 leans more on connection-state telemetry and T1018 on network traffic and remote enumeration patterns. Write each rule against the question the adversary is answering, so a single broad rule does not blur the three techniques together. Confirm the exact data components each ATT&CK version lists for each technique before you map coverage.
How do we handle noisy monitoring tools that trigger T1016 alerts?
Start by inventorying the legitimate tools that read network configuration on your fleet, such as configuration management agents, health checks, backup agents and network device polling jobs. Then allowlist them by a combination of parent process, service account, host group and expected execution path, not by process name alone, because names are easy to reuse. Keep the allowlist in version control, give each entry an owner and a review date, and alert on any deviation from the recorded pattern. Track how often each rule fires per host group so you can see which exceptions are doing the heavy lifting.
Which ATT&CK version should our detection rules be pinned to?
Pin each rule to the ATT&CK version you tested against, and record that version in the rule metadata. MITRE publishes each release as a STIX 2.1 bundle in the attack-stix-data repository, and releases can rename, deprecate or revoke techniques and sub-techniques. The current pages reference Enterprise ATT&CK 20.0, but your rule library should state the version used for mapping so that a later upgrade triggers a deliberate review rather than a silent change. Review the update notes for each release before you adopt it, and re-run your validation tests after any mapping change.
How can we test T1016 rules without affecting production?
Test in a private cyber range or a staging segment that mirrors your production logging pipeline. Build a small, repeatable set of test cases that run standard configuration-reading commands on representative hosts, then confirm that the expected events reach your SIEM with the expected fields and that the rule fires once, with the right severity. Use a change window for any test that touches shared infrastructure, and keep a written record of what was run, when, and by whom. Testing should confirm that telemetry arrives and that alerts route correctly, not only that a rule matches a string.
What do we do when network devices do not produce usable T1016 telemetry?
First, confirm which logs your network devices actually emit: configuration change logs, command accounting, AAA logs, and syslog levels that include show-command activity, if the platform supports it. Many devices log configuration changes more reliably than read-only queries, so you may need to rely on authentication and session records plus network-side visibility. Forward device logs to a central collector, verify timestamps and hostnames, and document the gaps as residual risk. Check each vendor's documentation for supported logging options, and treat any capability you cannot verify as an open item to confirm rather than an assumption.
How should we map T1016 detections to sub-technique coverage?
Map each detection to the technique or sub-technique it actually addresses, and keep the mapping in a table that lists the rule ID, ATT&CK version, data components used, platforms covered and test evidence. Where a technique has sub-techniques, record whether your rule covers the parent only or specific children, and be explicit about gaps. Review coverage after each ATT&CK release, since data components and detection strategies can change. Use the table to answer audit and leadership questions with evidence instead of summary claims.
Can our own team run T1016 detection validation, or do we need outside help?
Many SOC teams can run validation in-house once they have a documented test plan, a staging range and a clear owner for rule changes. Outside help is most useful when you need a fixed-scope assessment of coverage across platforms, a rehearsal design for a private cyber range, or an independent review of mappings before an assessment. DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own environment, runs security testing and private cyber ranges, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen builds T1016 detections and range exercises
DeployOpen works on T1016 System network configuration discovery as a fixed-scope engagement inside the client's own environment. The work covers the telemetry, detection logic and cyber range rehearsal needed to see network configuration discovery on the platforms in scope, with each deliverable documented for the client's own teams.
How we scope
- Confirm which platforms are in scope for T1016, such as ESXi, Linux, macOS and network devices.
- Agree which telemetry sources exist today, including Process Creation and Command Execution logging.
- Record the ATT&CK version the detection mapping targets, so later releases can be compared cleanly.
How we build
- Map T1016 and its two sub-techniques to detection strategies and analytics in the client's chosen open-source stack.
- Write detection logic in words and rule form for the agreed SIEM, such as Wazuh or Security Onion, and test it against logged data.
- Check for gaps in data components, log retention and parsing before any rule is marked ready.
How we hand over
- Deliver written detection documentation covering data sources, assumptions, known false positives and tuning notes.
- Run a private cyber range exercise that rehearses the detection and the response steps with the client's analysts.
- Provide a validation record that shows which test activity triggered which alert and where gaps remain.
How we support
- Offer ongoing support and continuous testing for T1016 detections as a retainer, if the client wants it.
- Review detection mappings when ATT&CK releases rename, deprecate or revoke techniques that affect T1016.
- Confirm with the client which support scope, response windows and review cadence they need before the engagement starts.
