AN2052: Analytic 2052
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
This analytic matters because discovery activity in ICS environments can be an early warning that a host is mapping control assets, outstations, or reachable services before further action. For security leaders, the practical question is whether the organization can see new or unusual ICS protocol use, broad connection attempts, and enterprise-protocol scanning that crosses into operational environments.
Executive priority
Prioritize this as an operational resilience and cyber-physical visibility issue. The value is not a single alert; it is proving that SOC and IR teams can identify unfamiliar devices using ICS discovery functions, hosts contacting many devices, and new protocol paths to existing assets. This supports incident decision-making, segmentation validation, and evidence for governance around OT monitoring readiness.
Technical view
The supplied ATT&CK analytic focuses on anomalies related to ICS discovery functions: devices that have not previously used those functions, functions sent to many outstations, new ICS protocol connections to existing assets, and device scanning over ICS or enterprise protocols such as ICMP, DCOM, and WinRM. SOC and detection teams should validate baselines for normal asset-to-asset communications, expected engineering or management hosts, and normal discovery behavior. Because no ATT&CK platforms, tactics, or relationships are supplied, implementation should be driven by local ICS network architecture and protocol visibility rather than assumed endpoint coverage.
Likely telemetry
- ICS protocol metadata showing function use, source, destination, and outstation targeting where available
- Network connection records for new source-to-asset communication paths
- Flow or packet metadata showing one host connecting to many devices
- ICMP traffic patterns across ICS or adjacent enterprise networks
- DCOM and WinRM connection activity where those protocols are present
Detection direction
- Validate whether monitoring can distinguish first-seen ICS protocol connections to existing assets from established operational communication.
- Tune for hosts sending discovery-related functions to many outstations or contacting many devices in a short period, while accounting for authorized engineering, inventory, maintenance, and monitoring tools.
- Correlate ICS protocol anomalies with enterprise-protocol scanning indicators such as ICMP, DCOM, or WinRM activity crossing into or within ICS environments.
- Use asset inventory and known management-host lists to reduce false positives; unknown or newly active sources should be reviewed more aggressively.
- Identify blind spots where east-west OT traffic, serial-to-IP gateways, remote access paths, or Windows management protocols are not logged or are not retained long enough for incident review.
Mitigation priorities
- Establish and maintain an accurate inventory of ICS assets, outstations, expected management hosts, and normal communication paths.
- Segment and restrict unnecessary enterprise-protocol access such as ICMP, DCOM, and WinRM into sensitive ICS zones where operationally feasible.
- Define approved discovery, engineering, monitoring, and maintenance activities so detections can separate authorized activity from unusual reconnaissance behavior.
- Ensure OT network monitoring captures protocol metadata and connection patterns needed to investigate broad scanning or first-seen connections.
- Create IR playbooks for validating whether unusual discovery traffic is authorized, misconfigured, or potentially malicious, including escalation paths for operations stakeholders.
Analyst notes and limits
ATT&CK provides this as a detection analytic for the ICS domain, centered on discovery-related anomalies and new protocol connections. There are no supplied relationships, tactics, platforms, or formal detection logic, so local baselining and architecture knowledge are essential to make it operational.
The source object does not provide a detection field, tactic mapping, platform list, mitigations, or relationship context. This take therefore avoids claims about attribution, exploitation, impact, or guaranteed coverage and relies only on the official description and external reference.
Analytic 2052
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 | 5fcf6204116e… |
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 AN2052Open 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.