DET0784: Detection of Block Command Message
DET0784 is an ICS-focused detection strategy for identifying when command messages may be blocked from reaching control system devices. The business issue...
Analyst context for executives and security teams
DET0784 is an ICS-focused detection strategy for identifying when command messages may be blocked from reaching control system devices. The business issue is operational resilience: if legitimate control commands do not arrive, operators or automated systems may be unable to correct a disruption or unsafe condition. Because MITRE provides no detailed detection logic, platforms, or telemetry requirements for this object, organizations should treat it as a prompt to validate whether their OT monitoring can prove that critical commands were sent, received, and acted upon.
Executive priority
Prioritize this where blocked or missing control commands could affect safety, production continuity, regulatory evidence, or incident response decisions. Leaders should ask whether OT teams can distinguish a failed device, network loss, operator error, and possible command-message blocking using collected evidence. The key investment question is not simply whether an alert exists, but whether the organization has enough OT network and control-system visibility to reconstruct command delivery during an incident.
Technical view
SOC, OT security, and incident response teams should validate visibility around command-message flow for the related ICS technique T1691.001, Command Message. Since the ATT&CK object does not specify platforms, tactics, detection text, or analytics, detection engineering should start from local architecture: identify critical command paths, expected sources and destinations, normal command timing, and where acknowledgements or device state changes should be observable. Investigations should compare command issuance evidence against network delivery, device receipt, and resulting process or controller state where those data sources are available.
Likely telemetry
- OT network traffic showing command messages between control system components
- Control system, HMI, engineering workstation, controller, or historian logs that record command issuance or state changes
- Network device or security sensor logs showing drops, errors, resets, filtering, or loss along critical OT paths
- Time-synchronized process telemetry indicating whether expected physical or controller state changes occurred after commands
- Incident response packet captures or flow records from monitored OT network segments
Detection direction
- Map critical command paths and confirm monitoring points can observe both command transmission and expected receipt or acknowledgement where available.
- Look for mismatches between issued commands and downstream evidence, such as no delivery, no acknowledgement, or no expected state transition, while accounting for normal device faults, maintenance, communication loss, and operator workflow.
- Tune detections around known maintenance windows, network segmentation behavior, protocol gateways, and intermittent OT communication issues to reduce false positives.
- Use the relationship to T1691.001 as context: the analytic value is in identifying blocked command delivery that could prevent corrective or safety-related response functions.
- Document blind spots explicitly, especially unmonitored OT segments, encrypted or proprietary traffic, missing controller logs, weak time synchronization, and lack of baseline command behavior.
Mitigation priorities
- Inventory critical command-message paths and identify which systems must be monitored to prove command delivery and execution.
- Improve OT logging, network visibility, and time synchronization before relying on detection outcomes.
- Establish incident playbooks for suspected command-delivery failure that include operations, engineering, SOC, and incident response roles.
- Validate segmentation, access control, and change-management evidence around devices or paths that can affect command delivery.
- Test detection assumptions in safe, authorized OT lab or maintenance scenarios rather than production-disruptive exercises.
Analyst notes and limits
This ATT&CK object is a detection strategy in the ICS domain and is explicitly related to T1691.001, Command Message. MITRE did not provide an official description, detection text, platforms, tactics, or aliases for DET0784 in the supplied fields. The Glexia take therefore focuses on defensive validation and incident decision value derived from the relationship context only.
Coverage cannot be inferred from this object alone. Local OT architecture, protocols, monitoring locations, device logging, time synchronization, and operational baselines determine whether this behavior can be detected or investigated. No active exploitation, attribution, affected platforms, or guaranteed detection coverage is supported by the supplied data.
Detection of Block Command Message
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T1691.001 | Command Message Sub-technique | This object detects Command Message. |
All related ATT&CK context
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 | 579286b482e6… |
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 DET0784Open 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.