T1499: Endpoint Denial of Service
MITRE ATT&CK T1499: Endpoint Denial of Service Technique details for Windows, Linux, macOS, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Endpoint Denial of Service is an availability attack against the systems and applications that deliver business services, such as web, email, DNS, databases, and web applications. The practical risk is not just “traffic volume”; ATT&CK distinguishes this from network saturation because the failure may occur at the operating system, service, application, container, or IaaS-hosted workload layer. That makes it material for business continuity, incident response triage, and service resilience planning.
Executive priority
Leaders should treat T1499 as an operational resilience issue: can the organization keep critical services available when endpoint resources, application features, or crash-prone software are targeted? Priority questions include which public-facing and business-critical services have tested DoS response plans, whether logs and performance telemetry are retained during outages, whether filtering rules can be changed quickly, and whether vulnerability management accounts for flaws that can cause persistent service crashes. Because ATT&CK includes Containers and IaaS platforms, cloud-hosted services should be included in continuity and incident decision-making rather than handled only as a network perimeter problem.
Technical view
For SOC, detection engineering, and IR teams, validate visibility across the layers described by ATT&CK: operating system resource exhaustion, service exhaustion, application exhaustion, and application or system exploitation. Official detection text is not provided for this technique, but ATT&CK relationship context identifies DET0208, Endpoint Resource Saturation and Crash Pattern Detection Across Platforms, as a detection strategy. Defensive validation should therefore correlate service availability symptoms with endpoint resource metrics, crash/restart events, application logs, and network/request patterns. Sub-technique context should guide triage: T1499.001 for OS-level exhaustion, T1499.002 for service-level exhaustion, T1499.003 for expensive application functions, and T1499.004 for crash-inducing exploitation.
Likely telemetry
- Endpoint and server CPU, memory, process, socket, file descriptor, and connection-state utilization metrics
- Operating system event logs, kernel/service errors, crash dumps, and restart events
- Web server, DNS server, database, email, and other service logs showing request rates, errors, and saturation symptoms
- Application logs showing repeated access to resource-intensive features or abnormal error patterns
- Container and IaaS workload metrics, health checks, autoscaling events, and instance/container restarts
Detection direction
- Build detections around convergence of availability degradation plus endpoint/resource saturation, not traffic volume alone.
- Tune alerts by service criticality and baseline behavior; high request volume can be legitimate during business peaks, while low-rate distributed activity may still exhaust constrained resources.
- Correlate crashes and repeated service restarts with inbound request patterns to identify possible T1499.004-style exploitation-driven denial of service.
- Separate network saturation from endpoint denial of service during triage; if links are not saturated but services fail, inspect OS, service, application, container, and IaaS workload limits.
- Validate that monitoring remains available during resource exhaustion; telemetry gaps during outages are a material blind spot.
Mitigation priorities
- Start with M1037 Filter Network Traffic: confirm that ingress rules, firewall policy, and endpoint/network filtering can restrict traffic to authorized sources where business requirements allow.
- Prioritize filtering and rate-control decisions for public-facing and critical services such as web, DNS, email, databases, and web applications.
- Harden service architecture by identifying single-system bottlenecks and resource limits across operating systems, server applications, application code paths, containers, and IaaS workloads.
- Include crash-related vulnerabilities in vulnerability management prioritization when they can deny availability of critical services.
- Test incident response runbooks for distinguishing endpoint DoS from network DoS, preserving evidence, escalating to service owners, and applying emergency filtering changes.
Additional notes and limits
This take is based on ATT&CK Enterprise technique T1499, its sub-techniques, external references, and stated relationships. The object has no official MITRE detection narrative, so detection guidance is framed as validation direction rather than guaranteed analytics. The relationship to DET0208 supports focusing on endpoint resource saturation and crash-pattern detection across platforms.
Local service architecture, traffic baselines, cloud configuration, container orchestration, and logging retention are required to determine actual exposure and detection coverage. The supplied ATT&CK data supports the listed platforms and relationships, but does not prove active exploitation, attribution against any organization, or the effectiveness of any specific control.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Endpoint 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.
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.
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.
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.