DET0723: Detection of Denial of Service
MITRE ATT&CK DET0723: Detection of Denial of Service Detection Strategy details, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
DET0723 is a MITRE detection strategy for ICS Denial of Service behavior related to T0814. Its practical importance is operational resilience: a device that becomes unresponsive may stop sending or receiving requests and may not perform expected functions until recovery actions such as rebooting occur.
Executive priority
Leaders should treat this as a continuity and incident-readiness question, not only a SOC alerting issue. Ask whether critical ICS devices have monitored availability, defined recovery expectations, and evidence that abnormal request volume or unexpected requests would be noticed quickly enough to support operational decisions.
Technical view
MITRE provides no official detection logic, platforms, or tactics for DET0723, but the relationship to T0814 gives validation direction. SOC and IR teams should verify whether monitoring can identify loss of expected device functionality, sudden unresponsiveness, high request volume over short periods, and requests a target device may not know how to handle. Any analytic should be tested against normal operational behavior to avoid confusing maintenance, engineering activity, or expected process changes with DoS conditions.
Likely telemetry
- Device availability and responsiveness status for relevant ICS assets
- Network traffic volume and request-rate evidence to and from monitored devices
- Logs or events showing failed, malformed, unexpected, or unhandled requests where available
- Operational alarms or process evidence indicating a device is not performing expected functions
- Recovery evidence such as reboot, restart, or restoration timing when a device becomes unresponsive
Detection direction
- Confirm which ICS devices are in scope and whether their expected functionality and communications patterns are baselined.
- Validate alerting for abrupt loss of responsiveness and unusually high request volumes in a short time period.
- Where logs support it, look for unexpected or unhandled request patterns associated with device instability.
- Tune detections with operations context so planned maintenance, configuration work, and normal engineering activity do not create excessive false positives.
- Document blind spots where devices lack logs, network visibility, or reliable health monitoring.
Mitigation priorities
- Prioritize availability monitoring and response procedures for devices whose loss of function would affect operations.
- Confirm recovery playbooks for temporarily unresponsive devices, including when reboot or restoration actions are appropriate.
- Assess whether network and device controls can reduce exposure to excessive request volume or unexpected request handling failures.
- Use findings to support resilience planning, incident response exercises, and compliance evidence around monitoring and recovery readiness.
Additional notes and limits
This take is based on DET0723 and its stated relationship to ICS technique T0814, Denial of Service. Because ATT&CK supplies no detection text, platform list, or tactic mapping for this detection strategy, local architecture and operations knowledge are required to turn it into specific analytics.
No active exploitation, attribution, affected platform, or guaranteed detection coverage is stated in the supplied ATT&CK fields. Recommendations are therefore framed as validation and readiness direction rather than confirmed MITRE detection logic.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detection of Denial of Service
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 | T0814 | Denial of Service | This object detects Denial of Service. |
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 | fed4406e50b1… |
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-attackDET0723Open 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.