AN1933: Analytic 1933
Monitor for a loss of network communications, which may indicate a device has been shutdown or restarted. 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. Device restarts and shutdowns may be observable in device application logs. Monitor for unexpected device restarts or shutdowns. Devices may produce alarms about restarts or shutdowns. Monitor for unexpected device restarts or shutdowns. Monitor ICS automation protocols for functions that restart or shutdown a device. Commands to restart or shutdown devices may also be observable in traditional IT management protocols.
Analyst context for executives and security teams
This analytic matters because unexpected device shutdowns, restarts, or loss of communications in an ICS environment can be an early business-continuity warning, even when it does not prove malicious activity by itself. For executives and security leaders, the decision value is whether operations, SOC, and incident response teams can quickly distinguish normal maintenance or process behavior from a potentially disruptive event affecting industrial devices.
Executive priority
Prioritize this as an operational resilience and incident triage control: confirm that restart, shutdown, alarm, and communications-loss evidence is available to both operations and security teams. The key leadership question is whether the organization can produce timely evidence during an outage or suspicious ICS event, not whether this analytic alone can attribute or confirm an attack.
Technical view
SOC, OT monitoring, and IR teams should validate visibility into loss of network communications, device application logs, device alarms, ICS automation protocol activity, and traditional IT management protocol activity where restart or shutdown commands may appear. Because ATT&CK notes this analytic may only provide additional evidence, teams should correlate restart/shutdown indicators with maintenance windows, operator activity, network events, and other detections rather than treating communications loss as a standalone confirmation.
Likely telemetry
- Network communications availability or heartbeat monitoring for ICS devices
- Device application logs showing restart or shutdown events
- Device-generated alarms related to restarts or shutdowns
- ICS automation protocol traffic that may include restart or shutdown functions
- Traditional IT management protocol logs or traffic where restart or shutdown commands may be observable
Detection direction
- Validate that unexpected loss of communications generates an alert or investigation cue, especially for critical ICS devices.
- Tune detections against known maintenance windows, planned restarts, device firmware updates, and normal operational procedures to reduce false positives.
- Correlate communications loss with device logs and alarms to determine whether the device restarted, shut down, or simply became unreachable due to a network issue.
- Review whether ICS automation protocol monitoring is able to identify restart or shutdown functions relevant to the local environment.
- Check whether IT management protocol telemetry is available where those protocols can affect ICS devices.
Mitigation priorities
- Establish an agreed operational baseline for expected device restarts, shutdowns, and communications interruptions.
- Ensure device logs, alarms, and network availability events are collected and retained for incident response and compliance evidence.
- Coordinate SOC and operations workflows so unexpected restarts or shutdowns are triaged with process context and maintenance records.
- Limit and govern authorized mechanisms that can restart or shut down ICS devices, using local access-control and change-management practices.
- Test incident response procedures for scenarios where communications loss is the first observable sign of a device disruption.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS domain. Its value is evidentiary and correlation-focused: it identifies observable signs that may complement other detections, not a direct confirmation of technique execution. No ATT&CK tactics, platforms, aliases, labels, or relationship context were supplied.
Official detection logic was not provided, and no relationships to techniques, assets, software, or groups were supplied. Local device types, protocols, logging capabilities, maintenance practices, and network architecture are required to turn this into precise detection content or coverage claims.
Analytic 1933
Monitor for a loss of network communications, which may indicate a device has been shutdown or restarted. 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. Device restarts and shutdowns may be observable in device application logs. Monitor for unexpected device restarts or shutdowns. Devices may produce alarms about restarts or shutdowns. Monitor for unexpected device restarts or shutdowns. Monitor ICS automation protocols for functions that restart or shutdown a device. Commands to restart or shutdown devices may also be observable in traditional IT management protocols.
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 | b839e964d547… |
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 AN1933Open 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.