AN2046: Analytic 2046
Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.
Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections.
Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.
Monitor for a loss of network communications, which may indicate this technique is being used.
Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist alarms may still be visible even if messages are blocked.
Analyst context for executives and security teams
AN2046 is an ICS-focused detection analytic for recognizing possible blocked communications by watching for service/process termination, missing operational data, application/protocol setting changes, loss of network communications, and asset alarms. Its business value is in early confirmation that control-system visibility or command/telemetry paths may be impaired, even though the analytic is indirect and does not by itself prove the underlying technique occurred.
Executive priority
Treat this as an operational resilience and incident decision-support analytic for ICS environments. Leaders should ask whether SOC and operations teams can quickly prove when critical automation communications are unavailable, distinguish planned maintenance from suspicious disruption, and correlate cyber telemetry with asset alarms. This supports continuity decisions, IR escalation, compliance evidence for monitoring, and cyber-physical risk management where blocked communications could affect operational awareness.
Technical view
Because no ATT&CK platform, tactic, or relationship context is supplied, validation should focus on the official analytic description: monitor ICS automation protocol/application services and processes for termination; monitor for lack of operational process data; review application logs for protocol-related setting changes and events; detect loss of network communications; and correlate asset alarms with network evidence. SOC and IR teams should treat this as corroborating evidence, not a standalone detection of technique execution.
Likely telemetry
- Process and service status events for ICS automation protocol components and application software
- Operational process data availability or data-quality indicators
- ICS application logs, especially settings changes and network-protocol related events
- Network communication/session availability between relevant ICS assets
- Asset alarms indicating loss of communications or missing data
Detection direction
- Validate that monitoring can identify termination of relevant ICS services or processes and distinguish expected restarts from abnormal stoppage.
- Alert on sustained lack of operational process data, but tune for maintenance, polling gaps, sensor outages, and known engineering activity.
- Correlate application log changes with network communication loss rather than treating configuration events in isolation.
- Use asset alarms as supporting evidence, especially when paired with network telemetry showing blocked or lost traffic.
- Account for the MITRE-noted blind spot that alternative communication paths may keep some alarms visible even when messages are blocked.
Mitigation priorities
- Prioritize reliable collection of ICS service/process status, application logs, network communication state, and asset alarms before attempting advanced correlation.
- Define baselines for normal operational data flow, expected service restarts, and maintenance periods.
- Create joint SOC/OT runbooks for investigating loss of communications, including escalation criteria and operational safety contacts.
- Preserve evidence needed for incident response and audit: timestamps, affected assets, missing data intervals, configuration changes, alarms, and network observations.
- Review resilience options and alternate communications with operations teams, while ensuring monitoring accounts for those paths.
Analyst notes and limits
The supplied object is a detection analytic, not a technique. It is especially useful for SOC/OT collaboration because it frames communications loss as a correlation problem across host/process, application, network, operational-data, and alarm sources. The most important local validation is whether the organization knows which ICS services, applications, assets, and communication paths are critical enough to monitor.
No official detection field, platforms, tactics, aliases, labels, or relationship context were supplied. The analytic explicitly provides indirect evidence and may not directly detect technique execution. Local asset inventory, network architecture, maintenance practices, and OT alarm behavior are required to make this actionable.
Analytic 2046
Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.
Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections.
Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.
Monitor for a loss of network communications, which may indicate this technique is being used.
Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist alarms may still be visible even if messages are blocked.
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 | d740237ddd20… |
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 AN2046Open 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.