T1018: Remote System Discovery
MITRE ATT&CK T1018: Remote System Discovery Technique details for ESXi, Linux, macOS, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Remote System Discovery is the point in an intrusion where an adversary tries to understand what other systems are reachable from the current foothold. For leaders, this matters because it often precedes lateral movement: the attacker is mapping where to go next, including servers, ESXi hosts, network devices, or other high-value systems. It is usually low-noise and can look like normal administration, so coverage depends on whether the organization can distinguish routine inventory/troubleshooting from unusual enumeration.
Executive priority
Treat this as an operational-resilience and incident-scope question: if one endpoint or account is compromised, can the organization see attempts to identify neighboring systems before the intrusion spreads? Priority should go to environments where lateral movement would threaten business continuity, regulated data, critical infrastructure, manufacturing, payment systems, or managed service provider access. Audit and risk owners should ask whether endpoint, network, ESXi, and network-device command evidence is retained well enough to reconstruct discovery activity during an incident.
Technical view
ATT&CK lists this as an enterprise discovery technique across Windows, Linux, macOS, ESXi, and network devices. Teams should validate visibility for commands and behaviors such as Ping, Windows net view via Net, ESXi esxcli network diag ping, review of local hosts files, ARP cache inspection, and network-device CLI commands such as show cdp neighbors and show arp. MITRE does not provide official detection text for this object, but the relationship to DET0574 indicates a detection-strategy context for remote system enumeration behavior. SOC teams should focus on baselining administrative enumeration and identifying unusual source hosts, accounts, timing, breadth, or execution context.
Likely telemetry
- Endpoint process creation and command-line logs for discovery utilities on Windows, Linux, macOS, and ESXi
- Authentication and session context tying commands to users, service accounts, remote access sessions, or management tools
- File access telemetry for local hosts files such as C:\Windows\System32\Drivers\etc\hosts and /etc/hosts
- ARP cache inspection evidence where available from host or network telemetry
- Network flow or packet metadata showing ping/ICMP sweeps or broad host reachability checks
Detection direction
- Validate whether command-line logging is enabled and retained on all stated platforms, not only Windows endpoints.
- Tune detections around unusual enumeration breadth, frequency, destination diversity, and execution by non-administrative or unexpected accounts.
- Correlate discovery commands with preceding remote access, credential use, or subsequent lateral movement attempts rather than alerting on every ping or administrative inventory action.
- Include network infrastructure and ESXi management planes; these are common blind spots when endpoint detection is the only data source.
- Separate approved administrative scripts, vulnerability scanning, asset inventory, and troubleshooting from ad hoc enumeration by source host, account, time window, and change-ticket context.
Mitigation priorities
- First, ensure least-privilege administration and controlled access to management interfaces so compromised users cannot freely enumerate sensitive networks.
- Next, segment networks and restrict management-plane reachability for ESXi hosts and network devices to approved administrative paths.
- Harden and monitor network-device and virtualization administration, including command logging and centralized retention.
- Maintain accurate asset inventory and approved scanner baselines so defenders can distinguish expected discovery from suspicious enumeration.
- Prepare incident-response playbooks to treat remote system discovery as a scoping trigger: identify what was enumerated, what credentials were used, and whether follow-on lateral movement occurred.
Additional notes and limits
The supplied relationships show this technique is used across many campaigns and groups, including espionage, ransomware, supply-chain, financially motivated, and cyber-physical/critical-infrastructure contexts. That breadth does not prove current exposure or attribution for any organization; it shows the behavior is a common enabling step across intrusion types. The Ukraine electric power campaign relationships make this relevant to cyber-physical risk discussions where network discovery could help an intruder understand operational environments.
MITRE provides no official detection section for this technique in the supplied object. The take is therefore based on the official description, platforms, tactics, external references, and relationship context only. Local baselines, logging configuration, network architecture, administrative practices, and retention periods are required to determine actual detection coverage or risk.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Remote System Discovery
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.