AN1919: Analytic 1919
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). 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 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.
Analyst context for executives and security teams
AN1919 is an ICS detection analytic focused on finding discovery activity: new protocol connections to existing assets, hosts scanning many devices, unusual ICS discovery functions, enterprise-protocol enumeration, access to host-mapping files, and rapid execution of tools such as ping.exe or tracert.exe. Its business value is in validating whether the organization can see early reconnaissance that may precede lateral movement in industrial environments, where unnoticed asset discovery can create operational and cyber-physical risk.
Executive priority
Treat this as a coverage question for operational resilience: can the SOC distinguish normal engineering, maintenance, and broadcast/multicast ICS behavior from abnormal discovery across plant or enterprise-connected networks? Leaders should ask whether ICS network monitoring, endpoint process telemetry, and asset baselines are sufficient to prove visibility during an incident or audit, especially where enterprise protocols such as ICMP, DCOM, or WinRM can be used to enumerate connected resources.
Technical view
Defenders should validate monitoring for new ICS protocol connections to known assets, one host connecting to many devices, anomalous discovery-related ICS functions, and non-ICS enumeration of network resources. Correlate process creation with network activity where possible, particularly newly executed discovery utilities such as ping.exe and tracert.exe running in quick succession or connecting to multiple systems. Because the ATT&CK object does not specify platforms or tactics, tuning must be based on local ICS protocol use, asset roles, engineering workflows, and known broadcast or multicast behavior.
Likely telemetry
- ICS network protocol connection metadata
- Enterprise network flow or connection logs for ICMP, DCOM, WinRM, and similar protocols
- Process creation telemetry for discovery utilities such as ping.exe and tracert.exe
- Endpoint file access telemetry for files such as /etc/hosts
- Asset inventory and historical communication baselines for ICS and enterprise-connected hosts
Detection direction
- Baseline normal ICS communications by asset role so new protocol connections to existing assets can be evaluated in context.
- Look for fan-out behavior: a single host connecting to many devices or sending discovery-related functions to many outstations.
- Correlate process creation with network activity to identify newly executed processes that begin scanning or connecting to multiple systems.
- Account for expected ICS broadcast and multicast functionality to reduce false positives.
- Include non-ICS enterprise enumeration paths, not only ICS-native protocols, because the analytic explicitly includes ICMP, DCOM, WinRM, host-file access, and remote-system discovery utilities.
Mitigation priorities
- Prioritize accurate ICS asset inventory and communication baselines before relying on anomaly detection.
- Limit and document which hosts are expected to perform engineering, maintenance, or discovery functions across ICS assets.
- Segment and control enterprise-to-ICS pathways so broad enumeration over enterprise protocols is constrained and reviewable.
- Ensure SOC and incident response playbooks include triage steps for distinguishing legitimate maintenance scans from unexpected discovery activity.
- Use compliance and resilience reviews to confirm retention of process, network, and file-access evidence needed to investigate discovery events.
Analyst notes and limits
The supplied object is a detection analytic, not a technique description, and no relationships, tactics, platforms, or formal detection field were provided. The official description is still operationally useful because it identifies the evidence patterns to validate: ICS protocol connections, discovery functions, enterprise enumeration protocols, host-list file access, process execution, and process-to-network correlation. The Elastic reference is cited by MITRE for process/network correlation context but should not be treated as vendor-required coverage.
No active exploitation, adversary attribution, affected platform list, tactic mapping, or guaranteed detection coverage is provided in the supplied ATT&CK fields. Local asset roles, maintenance practices, protocol use, and telemetry availability are required to determine whether this analytic is actionable and how noisy it will be.
Analytic 1919
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). 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 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.
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 | 9766e2f832dc… |
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 AN1919Open 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.