Remote System Discovery (T1018) is a discovery technique. Adversaries try to get a list of other systems on the network, by IP address, hostname or another logical identifier, that they could use for lateral movement. MITRE lists ESXi, Linux, macOS, network devices and Windows.
It is one of the first things an intruder does after landing on a host. It answers one question: where can I go from here?
How attackers use it
MITRE says functionality may exist inside remote access tools, but operating system utilities do the job as well. It names Ping, net view using Net, and, on ESXi, esxcli network diag ping.
Adversaries may also use passive means. They can read local host files, for example the Windows hosts file or /etc/hosts, or look at local ARP cache entries, which reveal systems without sending a single new packet. They may also target discovery of network infrastructure, and use network device CLI commands such as show cdp neighbors and show arp for detail on systems on the network.
The passive route matters for detection. No scan traffic means no network alert.
How to detect it
MITRE's detection strategy is a set of command patterns by platform:
- Windows: net.exe, ping.exe, tracert.exe and similar enumeration utilities run in short succession, often chained with lateral movement tools or system enumeration commands.
- Linux: bash scripts or interactive shells issuing sequential ping, arp or traceroute commands to map hosts.
- macOS: built-in or AppleScript-based enumeration through arp, netstat and ping, plus reading /etc/hosts.
- ESXi: shell or SSH access that runs esxcli network diag ping or views routing tables.
- Network devices: discovery commands such as show cdp neighbors and show arp on Cisco or Juniper gear.
The word that matters in MITRE's text is succession. Administrators run one ping. Intruders run twenty in a minute, from a host that does not normally do so.
What to log and how to use it:
- Process creation events with command lines, plus the parent process.
- Command history and accounting from ESXi and network devices, sent to a central log.
- Network flow data. Many failed connections from one host to many addresses is the network signature of an active sweep. A host that touches many internal addresses on the same port in a short time is the classic case.
- Honeypot or decoy hosts. Nothing legitimate should touch an unused address that you monitor, so a hit is a clean signal.
How to reduce the risk
MITRE lists no mitigations for this technique, because it uses normal features. The goal is to make discovery less useful and more visible:
- Segment the network, so a compromised host can reach only what its job needs. A flat network gives the intruder a full map.
- Limit interactive logons on servers, ESXi and network devices.
- Send logs off the host, so the history survives.
- Keep an accurate asset inventory, so that a new or unknown system stands out.
A decoy that pays for itself
Because discovery is a normal-looking activity, one of the cleanest detections is a decoy. Reserve an address or host name that no real system or person uses, and register it where discovery tools look, for example in DNS or a hosts file on a few machines. Then alert on any connection to it.
Nothing legitimate should touch the decoy. A ping, a scan or a login attempt is a hit with close to zero false positives. It also helps against the passive route MITRE describes, because an adversary who reads the hosts file and then connects to the listed names will find the decoy.
Tuning the command rule
Use a short window and a count. Build a list of discovery commands for each platform: net view and ping on Windows, arp and ping loops on Linux, esxcli ping on ESXi, show arp on network devices. Count how many distinct commands run from one host or session within five minutes. Set the threshold from your baseline, then send the parent process, user and command lines in the alert.
Your own administrators and tools will sometimes trigger it. Add named jump hosts and the accounts used by scanners you run on purpose, and review the allowlist often.
Working from the network side
The network sees what the host does not log. A host that sends one connection attempt each to hundreds of internal addresses is sweeping. A host that queries the directory for computer accounts is doing discovery in another way. If your tools collect flow data, add a rule on the number of distinct internal destinations per host per hour, and compare against the same host's history.
Making discovery less useful
Discovery returns what exists and what is reachable. You can shape both.
- Segmentation limits what is reachable, so the map is small.
- Host firewalls on workstations stop them from answering probes from peers.
- Removing stale entries from hosts files and DNS reduces the free information.
- Good asset records mean that when something new appears in the logs, you know whether it should.
Check your own environment
- Do you know what systems exist? An inventory you trust is the base of every other control.
- From a typical workstation, how many internal systems can it reach? Test from a lab machine, with permission.
- Are network device commands logged centrally?
- Do ESXi hosts log shell access and forward it?
The demo below shows how asset discovery builds the inventory that makes unknown systems visible.
Click through it at your own pace, or open it full screen.
Quick check
How can an adversary find hosts without scanning?
MITRE says they can read local hosts files and ARP cache entries, which reveal systems passively. That produces no scan traffic for a network tool to catch.
What makes a discovery command suspicious?
Context. Single commands are normal. Many in short succession, from an unusual host or parent process, or chained with lateral movement tools, is the pattern MITRE flags.
