T1018
Remote System Discovery
What it is
Attackers list the other hosts on a network so they can choose where to go next. It is a technique under the Discovery tactic. It usually comes soon after first access and before lateral movement, so finding it early can show an intrusion while it is still on its first host.
How adversaries use it
The attacker runs built-in commands that list nearby or domain computers, such as net view, nltest or arp, pings a range of addresses, or queries the directory for computer names. Some use a scanning tool instead. The results tell them which servers, file shares and administrator workstations are worth reaching next.
Detect it in Elastic
Data source: Windows process creation events; network connection records
Key fields
event.code: 1 (Sysmon) or 4688 (Windows Security) when a process starts process.name: the discovery tool, such as net.exe, nltest.exe, arp.exe or ping.exe process.command_line: what was asked for user.name: the account that ran it source.ip, destination.ip, destination.port: in network records, one host reaching many others host.name, @timestamp
Example event
{
"host": {
"name": "ws-214.corp.example"
},
"user": {
"name": "m.castell"
},
"event": {
"code": "1"
},
"process": {
"name": "net.exe",
"parent": {
"name": "wscript.exe"
},
"command_line": "net view /all"
},
"@timestamp": "2026-05-14T09:33:05.118Z"
}Prebuilt Elastic rule: Remote System Discovery Commands
Hunt guidance
Values must match the case your data records: Windows logs some tools in capitals, such as PING.EXE. Start with discovery tools: process.name: ("net.exe" or "nltest.exe" or "ARP.EXE" or "PING.EXE"). Then group by account and host, and look for several of them within a few minutes. In network records, look for one host contacting many others on the same port in a short window. Discovery from an ordinary workstation, by an account that doesn't administer the network, deserves a closer look.
Ruling out legitimate activity
IT staff, inventory tools and monitoring systems list hosts routinely, often on a schedule. Check whether the account and host are part of IT, whether the timing matches a known job, and what the same account did next. Discovery followed by new remote logons is the pattern that matters.
Telemetry needed
The log events that help detect this technique, from the Telemetry reference: which log source to collect, which event in it, and how to enable each one.
- ESXi and vCenter logs (the log as a whole)
- Linux audit framework (auditd)
- SYSCALL:execve SYSCALL record for execve
- syslog / journald (auth, secure, messages, cron) (the log as a whole)
- osquery (macOS)
- macOS unified log (the log as a whole)
- Network device logs (syslog, CLI/AAA, config, SNMP) (the log as a whole)
- Sysmon
References
Practice it
No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.