Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1499: Endpoint Denial of Service

Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users. Endpoint DoS can be performed by exhausting the system resources those services are hosted on or exploiting the system to cause a persistent crash condition. Example services include websites, email services, DNS, and web-based applications. Adversaries have been observed conducting DoS attacks for political purposes[1] and to support other malicious activities, including distraction[2], hacktivism, and extortion.[3]

An Endpoint DoS denies the availability of a service without saturating the network used to provide access to the service. Adversaries can target various layers of the application stack that is hosted on the system used to provide the service. These layers include the Operating Systems (OS), server applications such as web servers, DNS servers, databases, and the (typically web-based) applications that sit on top of them. Attacking each layer requires different techniques that take advantage of bottlenecks that are unique to the respective components. A DoS attack may be generated by a single system or multiple systems spread across the internet, which is commonly referred to as a distributed DoS (DDoS).

To perform DoS attacks against endpoint resources, several aspects apply to multiple methods, including IP address spoofing and botnets.

Adversaries may use the original IP address of an attacking system, or spoof the source IP address to make the attack traffic more difficult to trace back to the attacking system or to enable reflection. This can increase the difficulty defenders have in defending against the attack by reducing or eliminating the effectiveness of filtering by the source address on network defense devices.

Botnets are commonly used to conduct DDoS attacks against networks and services. Large botnets can generate a significant amount of traffic from systems spread across the global internet. Adversaries may have the resources to build out and control their own botnet infrastructure or may rent time on an existing botnet to conduct an attack. In some of the worst cases for DDoS, so many systems are used to generate requests that each one only needs to send out a small amount of traffic to produce enough volume to exhaust the target's resources. In such circumstances, distinguishing DDoS traffic from legitimate clients becomes exceedingly difficult. Botnets have been used in some of the most high-profile DDoS attacks, such as the 2012 series of incidents that targeted major US banks.[4]

In cases where traffic manipulation is used, there may be points in the global network (such as high traffic gateway routers) where packets can be altered and cause legitimate clients to execute code that directs network packets toward a target in high volume. This type of capability was previously used for the purposes of web censorship where client HTTP traffic was modified to include a reference to JavaScript that generated the DDoS code to overwhelm target web servers.[5]

For attacks attempting to saturate the providing network, see Network Denial of Service.

EnterpriseT1499TechniqueObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.
Analyst 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.

Official MITRE ATT&CK definition

Endpoint Denial of Service

Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users. Endpoint DoS can be performed by exhausting the system resources those services are hosted on or exploiting the system to cause a persistent crash condition. Example services include websites, email services, DNS, and web-based applications. Adversaries have been observed conducting DoS attacks for political purposes[1] and to support other malicious activities, including distraction[2], hacktivism, and extortion.[3]

An Endpoint DoS denies the availability of a service without saturating the network used to provide access to the service. Adversaries can target various layers of the application stack that is hosted on the system used to provide the service. These layers include the Operating Systems (OS), server applications such as web servers, DNS servers, databases, and the (typically web-based) applications that sit on top of them. Attacking each layer requires different techniques that take advantage of bottlenecks that are unique to the respective components. A DoS attack may be generated by a single system or multiple systems spread across the internet, which is commonly referred to as a distributed DoS (DDoS).

To perform DoS attacks against endpoint resources, several aspects apply to multiple methods, including IP address spoofing and botnets.

Adversaries may use the original IP address of an attacking system, or spoof the source IP address to make the attack traffic more difficult to trace back to the attacking system or to enable reflection. This can increase the difficulty defenders have in defending against the attack by reducing or eliminating the effectiveness of filtering by the source address on network defense devices.

Botnets are commonly used to conduct DDoS attacks against networks and services. Large botnets can generate a significant amount of traffic from systems spread across the global internet. Adversaries may have the resources to build out and control their own botnet infrastructure or may rent time on an existing botnet to conduct an attack. In some of the worst cases for DDoS, so many systems are used to generate requests that each one only needs to send out a small amount of traffic to produce enough volume to exhaust the target's resources. In such circumstances, distinguishing DDoS traffic from legitimate clients becomes exceedingly difficult. Botnets have been used in some of the most high-profile DDoS attacks, such as the 2012 series of incidents that targeted major US banks.[4]

In cases where traffic manipulation is used, there may be points in the global network (such as high traffic gateway routers) where packets can be altered and cause legitimate clients to execute code that directs network packets toward a target in high volume. This type of capability was previously used for the purposes of web censorship where client HTTP traffic was modified to include a reference to JavaScript that generated the DDoS code to overwhelm target web servers.[5]

For attacks attempting to saturate the providing network, see Network Denial of Service.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

4 rows
Domain ID Name Relationship / procedure
Enterprise T1499.003 Application Exhaustion Flood Sub-technique Application Exhaustion Flood subtechnique of this object.
Enterprise T1499.002 Service Exhaustion Flood Sub-technique Service Exhaustion Flood subtechnique of this object.
Enterprise T1499.004 Application or System Exploitation Sub-technique Application or System Exploitation subtechnique of this object.
Enterprise T1499.001 OS Exhaustion Flood Sub-technique OS Exhaustion Flood subtechnique of this object.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0034: Sandworm Team

Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]

In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[7]

Malware Enterprise

S0412: ZxShell

ZxShell is a remote administration tool and backdoor that can be downloaded from the Internet, particularly from Chinese hacker websites. It has been used since at least 2004.[1][2]

Windows
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1499.003: Application Exhaustion Flood Enterprise mitigates · Mitigation M1037: Filter Network Traffic Enterprise uses · Malware S0052: OnionDuke Enterprise subtechnique of · Technique T1499.002: Service Exhaustion Flood Enterprise subtechnique of · Technique T1499.004: Application or System Exploitation Enterprise uses · Group G0034: Sandworm Team Enterprise subtechnique of · Technique T1499.001: OS Exhaustion Flood Enterprise detects · Detection Strategy DET0208: Endpoint Resource Saturation and Crash Pattern Detection Across Platforms Enterprise uses · Malware S0412: ZxShell Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1037: Filter Network Traffic

Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:

Ingress Traffic Filtering:

- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.

Egress Traffic Filtering:

- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.

Protocol-Based Filtering:

- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.

Network Segmentation:

- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.

Application Layer Filtering:

- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.

Change history

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 .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
b32e8c84bcce5f2f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle b32e8c84bcce…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    FireEye OpPoisonedHandover February 2016

    Ned Moran, Mike Scott, Mike Oppenheim of FireEye. (2014, November 3). Operation Poisoned Handover: Unveiling Ties Between APT Activity in Hong Kong’s Pro-Democracy Movement. Retrieved November 17, 2024.

    Open source URL
  2. [2]
    FSISAC FraudNetDoS September 2012

    FS-ISAC. (2012, September 17). Fraud Alert – Cyber Criminals Targeting Financial Institution Employee Credentials to Conduct Wire Transfer Fraud. Retrieved September 23, 2024.

    Open source URL
  3. [3]
    Symantec DDoS October 2014

    Wueest, C.. (2014, October 21). The continued rise of DDoS attacks. Retrieved April 24, 2019.

    Open source URL
  4. [4]
    USNYAG IranianBotnet March 2016

    Preet Bharara, US Attorney. (2016, March 24). Retrieved April 23, 2019.

    Open source URL
  5. [5]
    ArsTechnica Great Firewall of China

    Goodin, D.. (2015, March 31). Massive denial-of-service attack on GitHub tied to Chinese government. Retrieved April 19, 2019.

    Open source URL
  6. [6]
    Cisco DoSdetectNetflow

    Cisco. (n.d.). Detecting and Analyzing Network Threats With NetFlow. Retrieved April 25, 2019.

    Open source URL
  7. [7]
    mitre-attack T1499
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use