DET0356: Endpoint DoS via OS Exhaustion Flood Detection Strategy
DET0356 is a MITRE detection strategy for recognizing endpoint denial-of-service behavior where an attacker attempts to exhaust operating-system limits or...
Analyst context for executives and security teams
DET0356 is a MITRE detection strategy for recognizing endpoint denial-of-service behavior where an attacker attempts to exhaust operating-system limits or resources. The business issue is availability: even without data theft or malware execution, this behavior can disrupt workstations or servers that support operations, incident response, or customer-facing services. Because the ATT&CK entry provides no official detection text, teams should treat this as a coverage-validation prompt rather than a ready-made analytic.
Executive priority
Prioritize this where endpoint availability is tied to business continuity, regulated service uptime, or cyber-physical operations. Leaders should ask whether critical Linux, macOS, and Windows endpoints have enough telemetry to prove or disprove OS-level exhaustion during an outage, and whether SOC and IR teams can distinguish hostile flooding from misconfiguration, legitimate load, or software failure.
Technical view
This strategy detects the related ATT&CK technique T1499.001, OS Exhaustion Flood, under the Impact tactic. The detection strategy itself has no specified platforms, but the related technique lists Linux, macOS, and Windows. SOC and detection engineering teams should validate visibility into abnormal endpoint resource pressure, connection or session exhaustion indicators, repeated service failures, and correlated network activity that aligns with an availability event. Because MITRE provides no official detection logic for this object, any analytic should be locally engineered and tested against baseline endpoint behavior.
Likely telemetry
- Endpoint performance metrics such as CPU, memory, process count, handle/file descriptor usage, socket usage, and service health
- Operating system and service logs showing resource exhaustion, crashes, restarts, or refused connections
- EDR or endpoint monitoring events for process/service instability and abnormal resource consumption
- Host network telemetry showing unusual inbound connection volume, connection state buildup, or repeated failed sessions
- Network security telemetry from firewalls, IDS/IPS, or flow records that can be correlated to affected endpoints
Detection direction
- Build detections around deviations from normal endpoint resource and connection baselines rather than single static thresholds.
- Correlate endpoint exhaustion symptoms with network activity to reduce false positives from local software bugs, patching, backups, or legitimate peak load.
- Validate coverage separately for Linux, macOS, and Windows assets if those platforms are in scope, because OS resource limits and logs differ.
- Tune for critical assets first, especially systems where endpoint unavailability creates operational or compliance impact.
- Document blind spots where endpoint metrics, OS logs, or network flow records are not retained long enough to support outage investigation.
Mitigation priorities
- Identify business-critical endpoints and ensure monitoring, alert routing, and response playbooks cover availability-impacting events.
- Harden and capacity-plan OS and service resource limits where appropriate, based on local system roles and vendor guidance.
- Use network controls and segmentation to limit unnecessary exposure of endpoint services that could be targeted for flooding.
- Ensure incident response procedures include rapid triage of DoS-like endpoint failures, including correlation of endpoint health and network telemetry.
- Maintain audit-ready evidence showing which critical endpoints have availability monitoring and what telemetry supports investigation.
Analyst notes and limits
The most important value of this ATT&CK object is prompting a coverage conversation: can the organization detect and investigate endpoint-level DoS caused by OS exhaustion conditions? The relationship to T1499.001 supplies the operational context, but the strategy record itself does not include formal detection logic, tactics, or platforms.
Official description and official detection content were not provided for DET0356. Platforms are not specified on the detection strategy object; Linux, macOS, and Windows are derived only from the related T1499.001 technique. Local baselines, asset criticality, and retained telemetry are required before any detection quality or coverage claim can be made.
Endpoint DoS via OS Exhaustion Flood Detection Strategy
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 |
|---|---|---|---|
| Enterprise | T1499.001 | OS Exhaustion Flood Sub-technique | This object detects OS Exhaustion Flood. |
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 | 1c05a6670a9a… |
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 DET0356Open 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.