AN2051: Analytic 2051
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. 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
AN2051 is an ICS-focused detection analytic for spotting unusual discovery activity: new ICS protocol connections, devices using discovery-related functions for the first time, one host reaching many devices, or discovery over enterprise protocols such as ICMP, DCOM, and WinRM. For security leaders, the value is early warning: discovery is often where an intruder maps operations before choosing what to disrupt, manipulate, or move toward next.
Executive priority
Prioritize this analytic where operational continuity depends on stable ICS communications and known engineering/operations workflows. Leaders should ask whether the organization can distinguish normal asset-management, engineering, and maintenance discovery from unusual scanning or new protocol use. This matters for incident triage, audit evidence around monitoring of critical environments, and cyber-physical risk reduction because discovery against many outstations or existing assets can indicate preparation for broader operational access.
Technical view
SOC, OT security, and IR teams should validate whether they can baseline ICS protocol relationships and enterprise-protocol discovery paths into ICS-connected assets. The analytic points to anomalies such as devices that have not previously used discovery-related ICS functions, functions sent to many outstations, new ICS protocol connections to existing assets, and one host connecting to many devices. Because ATT&CK provides no platform list, tactic mapping, or formal detection logic for this analytic, implementation should be environment-specific and based on known asset roles, expected polling/engineering behavior, and approved maintenance patterns. The description also references Remote System Discovery for enterprise procedure context, so teams should correlate OT network observations with enterprise-side discovery signals where those paths connect.
Likely telemetry
- ICS network traffic metadata, including source, destination, protocol, function or command where available
- Connection baselines between engineering workstations, HMIs, servers, controllers, outstations, and other ICS assets
- Enterprise network telemetry for ICMP, DCOM, and WinRM connections involving ICS-connected networks or assets
- Asset inventory and role data to determine whether a device is expected to perform discovery or communicate with many outstations
- Historical protocol-use records to identify first-seen ICS protocol connections or first-time use of discovery-related functions
Detection direction
- Build or validate baselines for which assets normally initiate ICS discovery-related functions and which outstations they normally contact.
- Alert on first-seen ICS protocol connections to existing assets, especially when initiated by systems without an expected OT role.
- Look for fan-out behavior: one host connecting to many devices or sending discovery-related functions to many outstations.
- Correlate ICS discovery anomalies with enterprise discovery over ICMP, DCOM, or WinRM when those protocols touch ICS-connected assets or networks.
- Tune against expected engineering, inventory, commissioning, vendor support, and maintenance activities to reduce false positives.
Mitigation priorities
- Establish and maintain an accurate ICS asset inventory with expected communication roles and approved discovery/management paths.
- Segment and control enterprise-to-ICS pathways so ICMP, DCOM, WinRM, and ICS protocol access are limited to authorized systems and operational need.
- Define approved maintenance and scanning windows so anomalous discovery can be separated from legitimate operational activity.
- Ensure OT monitoring coverage captures relevant ICS and enterprise protocol connections at points where discovery behavior would be visible.
- Prepare IR playbooks for unusual ICS discovery that include validation with operations teams before containment actions that could affect availability.
Analyst notes and limits
This object is a detection analytic in the ICS ATT&CK domain, not a technique. It is most useful as a coverage-validation prompt: can the organization see new ICS protocol relationships, discovery function anomalies, and host-to-many-device behavior? The supplied object has no relationships, no platforms, no tactics, and no separate official detection text, so local architecture and asset-role context are required to turn it into deployable logic.
The take is based only on the supplied official description and external reference for AN2051. No active exploitation, threat actor use, affected platforms, specific ICS protocols, or guaranteed detections are asserted. Relationship context was not supplied, and the official detection field is empty.
Analytic 2051
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. 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 | 2d3baee7dbc8… |
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]
mitre-attack AN2051Open 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.