System Network Configuration Discovery (T1016) is a discovery technique. Adversaries look for details about the network configuration and settings of the systems they reach, such as IP and MAC addresses. MITRE lists ESXi, Linux, macOS, network devices and Windows.
How attackers use it
Several administration utilities provide the answers, and MITRE names Arp, ipconfig and ifconfig, nbtstat and route among them. On network devices, adversaries may use the device CLI, for example show ip route and show ip interface, to learn about interfaces and static or dynamic routes. On ESXi they may use esxcli. MITRE gives esxcli network nic list, which returns MAC addresses, and esxcli network ip interface ipv4 get, which returns the local IPv4 address.
MITRE says adversaries may use this information during automated discovery to shape follow-on behavior, including working out what access they have inside the network and what to do next.
How to detect it
MITRE's analytic is behavioral, by platform:
- Windows: built-in tools such as ipconfig, route and netsh, or PowerShell and WMI queries, enumerating IP, MAC, interface status or routing configuration.
- Linux: ifconfig, ip a, or access to /proc/net.
- macOS: ifconfig, networksetup or system_profiler.
- ESXi: esxcli network commands over SSH or through hostd.
- Network devices: interface and routing discovery commands such as show ip interface, show arp and show route over Telnet, SSH or console.
A single ipconfig is noise. The signal is a cluster: several discovery commands, from a parent that does not usually run them, within a short time. Use process creation events with command lines and the parent process name. On ESXi and network devices, make sure shell and command history reach a central log.
How to reduce the risk
MITRE lists no mitigations, because the technique relies on legitimate commands. Your controls sit around it: limit interactive access to servers and ESXi hosts, record commands, and use endpoint tools that flag unusual parent and child processes.
Why discovery commands are worth logging
Discovery is the moment an intruder has to ask questions. Before they can move, they need to know where they are. That makes it a good spot for detection, since they must run something, and since the questions come in a pattern.
Tuning the detection
On Windows, collect process creation events with command lines. On Linux, use audit rules for the network tools, or an endpoint agent that records process starts. On network devices and ESXi, forward command history.
Then write one rule: several commands from the network discovery family within a short window, from a parent process that is not an administrative shell or a known management tool. Keep the threshold low at first and tune it from real alerts.
Network devices and ESXi
These platforms are easy to overlook. Network device commands such as show ip route and show arp are standard for administrators, so the key is who and from where. Allow logons from your management network and alert on anything else. On ESXi, esxcli use over SSH on a host that normally has SSH disabled is an event worth a ticket by itself.
Using the results
A discovery alert on its own is a lead. Follow it by asking what the same account or host did before and after. Look back for the logon that started the session, and forward for connections to other internal hosts. Discovery tends to sit in the middle of a chain, and the chain is the finding.
Check your own environment
- Are ESXi shell and SSH access disabled by default and logged when enabled?
- Do network devices send command accounting to a central log?
- Does your process creation logging include command lines?
Quick check
Which signal is stronger than one ipconfig?
A burst of several discovery commands launched by an unusual parent process in a short window.
