AN1872: Analytic 1872
Monitor for files (such as /etc/hosts) being accessed that may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for Lateral Movement from the current system. Monitor for newly executed processes that can be used to discover remote systems, such as ping.exe and tracert.exe , especially when executed in quick succession.[1] Consider monitoring for new processes engaging in scanning activity or connecting to multiple systems by correlating process creation network data. Monitor for anomalies related to discovery related ICS functions, including devices that have not previously used these functions or for functions being sent to many outstations. Note that some ICS protocols use broadcast or multicast functionality, which may produce false positives. Also monitor for hosts enumerating network connected resources using non-ICS enterprise protocols. Monitor for new ICS protocol connections to existing assets or for device scanning (i.e., a host connecting to many devices) over ICS and enterprise protocols (e.g., ICMP, DCOM, WinRM). For added context on adversary enterprise procedures and background see Remote System Discovery.
Analyst context for executives and security teams
AN1872 is an ICS-focused detection analytic for spotting systems that are trying to discover other networked assets, using evidence such as host file access, discovery tools like ping or tracert, scanning behavior, and new ICS or enterprise protocol connections. Its business value is that early network discovery can precede lateral movement, including movement between enterprise and industrial environments, so organizations need to know whether they can see this behavior before an incident becomes an operational resilience problem.
Executive priority
Treat this as a coverage-validation item for environments where industrial systems, outstations, or enterprise-to-ICS connectivity matter. Leaders should ask whether the SOC can distinguish normal engineering, monitoring, broadcast, or multicast activity from unusual discovery across many assets. The priority is not a single tool name; it is confirming that asset visibility, network telemetry, and process evidence are good enough to support incident decisions, audit evidence, and containment planning in mixed IT/OT environments.
Technical view
SOC and detection teams should validate monitoring for files that can reveal hostnames or IP mappings, newly executed discovery processes such as ping.exe and tracert.exe, quick succession execution of discovery utilities, processes connecting to multiple systems, new ICS protocol connections to known assets, and hosts enumerating network-connected resources using non-ICS enterprise protocols such as ICMP, DCOM, or WinRM. In ICS environments, tune detections around devices that have not previously used discovery-related ICS functions or functions being sent to many outstations, while accounting for legitimate broadcast and multicast protocol behavior.
Likely telemetry
- Process creation telemetry for discovery utilities and newly executed processes
- File access telemetry for files that may list hosts or logical network identifiers, such as /etc/hosts
- Network connection telemetry showing one host connecting to many devices
- ICS protocol connection telemetry, including new connections to existing assets
- Enterprise protocol telemetry relevant to discovery, including ICMP, DCOM, and WinRM where collected
Detection direction
- Validate whether detections correlate process creation with network activity rather than relying only on process names.
- Look for quick succession execution of remote system discovery utilities and processes that connect to multiple systems.
- Baseline normal ICS protocol behavior so new ICS protocol connections, unusual discovery functions, or functions sent to many outstations can be reviewed in context.
- Tune for ICS broadcast or multicast behavior to reduce false positives, as the official description notes this may be normal for some protocols.
- Include non-ICS enterprise protocol enumeration in OT-adjacent monitoring, especially ICMP, DCOM, and WinRM, where those protocols are present and logged.
Mitigation priorities
- First, confirm asset inventory and communication baselines for ICS assets, outstations, and enterprise-connected hosts.
- Ensure SOC collection covers process creation, relevant file access, and network connection evidence across systems that can reach industrial assets.
- Segment and restrict unnecessary enterprise-to-ICS discovery paths where local architecture and operational requirements allow.
- Define incident response playbooks for investigating a host that begins scanning many devices or initiating new ICS protocol connections.
- Document detection logic, tuning assumptions, and known broadcast or multicast exceptions as compliance and audit-supporting evidence.
Analyst notes and limits
This object is a detection analytic in the ICS ATT&CK domain. The supplied ATT&CK fields do not specify platforms, tactics, relationships, or a separate official detection field, so the take is based on the official description and cited external reference. The key defensive theme is discovery telemetry and correlation across host, network, and ICS protocol evidence.
No relationship context, platforms, tactics, mitigations, or procedure examples were supplied. Local network architecture, ICS protocol use, asset baselines, and logging availability are required to determine whether the analytic is applicable and how noisy it will be. This summary does not assert active exploitation, attribution, or existing detection coverage.
Analytic 1872
Monitor for files (such as /etc/hosts) being accessed that may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for Lateral Movement from the current system. Monitor for newly executed processes that can be used to discover remote systems, such as ping.exe and tracert.exe , especially when executed in quick succession.[1] Consider monitoring for new processes engaging in scanning activity or connecting to multiple systems by correlating process creation network data. Monitor for anomalies related to discovery related ICS functions, including devices that have not previously used these functions or for functions being sent to many outstations. Note that some ICS protocols use broadcast or multicast functionality, which may produce false positives. Also monitor for hosts enumerating network connected resources using non-ICS enterprise protocols. Monitor for new ICS protocol connections to existing assets or for device scanning (i.e., a host connecting to many devices) over ICS and enterprise protocols (e.g., ICMP, DCOM, WinRM). For added context on adversary enterprise procedures and background see Remote System Discovery.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 8a0c7de1e0d3… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Elastic - Koadiac Detection with EQL
Stepanic, D.. (2020, January 13). Embracing offensive tooling: Building detections against Koadic using EQL. Retrieved November 17, 2024.
Open source URL -
[2]
mitre-attack AN1872Open source URL
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.