DET0173: Detection Strategy for Endpoint DoS via Service Exhaustion Flood
DET0173 is a MITRE detection strategy intended to cover service-exhaustion denial-of-service behavior against endpoints and services, mapped to ATT&CK tech...
Analyst context for executives and security teams
DET0173 is a MITRE detection strategy intended to cover service-exhaustion denial-of-service behavior against endpoints and services, mapped to ATT&CK technique T1499.002 Service Exhaustion Flood. The business significance is availability: if DNS, web, or other exposed services are overwhelmed, the organization may face customer disruption, operational downtime, incident escalation pressure, and evidence demands from auditors or regulators. Because the detection strategy itself has no official detection text or platform scope, leaders should treat it as a prompt to validate local DoS monitoring and response readiness rather than as a ready-made analytic.
Executive priority
Prioritize this as an operational resilience and incident-readiness question: which business-critical services would materially affect revenue, safety, or customer trust if exhausted, and can the SOC prove it would see the early signs? Budget and control decisions should focus on availability monitoring, capacity visibility, response runbooks, and evidence that critical Windows, Linux, macOS, and IaaS-hosted services are covered where relevant to T1499.002.
Technical view
For SOC, detection engineering, and IR teams, use the relationship to T1499.002 to validate monitoring around abnormal service request volume, connection pressure, resource exhaustion, and service degradation affecting DNS, web, or other network services. The detection strategy object provides no official analytic logic, so teams should derive local thresholds from normal service baselines, known high-traffic periods, and business-critical asset lists. IR teams should confirm they can distinguish malicious or suspicious floods from flash crowds, failed deployments, misconfigured clients, and upstream provider issues.
Likely telemetry
- Network flow and connection telemetry for exposed or critical services
- Web server, DNS server, and other service access logs where applicable
- Endpoint and server resource metrics such as CPU, memory, process/thread counts, socket usage, and service health
- Cloud or IaaS load balancer, firewall, and infrastructure monitoring for services hosted there
- Availability and synthetic monitoring for business-critical applications
Detection direction
- Validate that detection coverage is tied to the services that matter most to business continuity, not only generic perimeter alerts.
- Baseline normal request rates, connection states, error rates, and resource consumption so flood conditions can be separated from expected demand spikes.
- Tune for service-specific context: DNS and web services may require different indicators, thresholds, and false-positive handling than other network services.
- Correlate availability degradation with network volume and host resource exhaustion to reduce false positives from routine performance incidents.
- Check blind spots in IaaS-hosted services, unmanaged endpoints, services behind third-party infrastructure, and logs that are sampled, delayed, or not retained long enough for IR reconstruction.
Mitigation priorities
- Identify and rank services whose exhaustion would create material business disruption.
- Confirm monitoring and alert routing for those services across endpoint, network, and IaaS environments where applicable.
- Maintain incident runbooks that define escalation, traffic analysis, service owner coordination, and business communications for availability events.
- Ensure logging and metrics retention are sufficient to support post-incident analysis and compliance evidence.
- Review capacity, rate-limiting, traffic management, and service resilience controls with infrastructure and application owners, without relying on any single control as guaranteed protection.
Analyst notes and limits
This take is based on the MITRE detection strategy object DET0173 and its relationship to ATT&CK technique T1499.002 Service Exhaustion Flood. The strategy object itself does not include an official description, detection guidance, tactics, or platforms; the practical context comes from the related technique, which is in the impact tactic and lists Windows, IaaS, Linux, and macOS as platforms.
The supplied ATT&CK fields do not provide analytic logic, data source definitions, mitigation mappings, examples, attribution, or evidence of active exploitation. Any assessment of coverage, severity, exposure, or control effectiveness requires local asset criticality, architecture, telemetry, and incident response evidence.
Detection Strategy for Endpoint DoS via Service Exhaustion Flood
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.002 | Service Exhaustion Flood Sub-technique | This object detects Service 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 | 92469ce8fb29… |
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 DET0173Open 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.