Key Takeaways
- There are three main DDoS attack categories: Volumetric (Layer 3), Protocol (Layer 4), and application layer (Layer 7) – each with different attack characteristics
- Each category requires a different mitigation approach, though the mitigation of layer 3/4 attacks is the same in majority of cases
- Application layer (L7) attacks are the hardest to detect and stop because they closely mimic legitimate user behavior
- Most organizations are only tested against a small subset of attack types – Red Button simulations cover a wide range of of multi-vector attack scenarios
The Three Categories of DDoS Attacks
DDoS attack types fall into three categories, depending on what vulnerability they are trying to exploit. Volumetric attacks saturate your network pipeline by flooding it with traffic until nothing else gets through. Protocol attacks target how connections are handled, tying up resources such as firewalls and routers. Application layer attacks target the application itself, using legitimate-looking requests to quietly overload proxies (Load balancers, FW, etc.), specific app services and APIs.
Volumetric Attacks (Layer 3)
How they work
Volumetric attacks (often referred to as Layer 3 DDoS attacks at the network level) are designed to saturate available network bandwidth by flooding the target with high volumes of traffic. Common vectors include UDP floods, DNS amplification, NTP amplification, and ICMP floods, all of which generate large amounts of traffic with relatively little effort from the attacker.
The objective is straightforward: saturate the network “pipe” so legitimate traffic cannot reach the application or infrastructure behind it.
These attacks are typically measured in Gbps (gigabits per second). At scale, they can exceed 1 Tbps, enough to overwhelm even well-provisioned infrastructure if mitigation is not correctly implemented upstream.
What Red Button sees in testing
In DDoS simulation testing, network-layer attacks are most often used as the opening move in multi-vector campaigns. They create immediate pressure on bandwidth and upstream infrastructure, forcing mitigation systems to react before more targeted vectors are introduced.
In the European Central Bank (ECB) case study test scenario, ISP-level infrastructure became saturated under a volumetric attack despite correctly configured ACLs. The result was service disruption, not because controls were missing, but because the scale of the traffic exceeded what the upstream protections could absorb.
The key takeaway is simple: even well-configured upstream defenses can be overwhelmed if they are not designed and tested against the scale of modern volumetric attacks.
Protocol Attacks (Layer 4)
How they work
Protocol attacks (often referred to as Layer 4 DDoS attacks) don’t rely on sheer traffic volume; they exploit how network and transport protocols handle connections. Instead of flooding bandwidth (as in UDP floods), they target the logic that keeps connections open and managed.
Common vectors include SYN floods, ACK floods, TCP connection exhaustion, and TLS reconnection attacks. Each of these abuses normal protocol behavior to create an imbalance between incoming requests and the system’s ability to track and respond to them.
The goal is to exhaust connection state tables in firewalls, routers, or load balancers, eventually preventing legitimate users from establishing or maintaining connections.
What Red Button sees in testing
In testing, protocol-layer attacks consistently expose gaps that aren’t obvious from configuration alone.
During a simulation for a European government agency case study, an Azure DDoS Protection Plan – designed to handle Layer 3/4 attacks – failed to detect or mitigate a TLS reconnection attack, resulting in no mitigation. The attack didn’t rely on volume, but on repeatedly forcing the system to renegotiate connections until resources were exhausted.
SYN and ACK floods are also among the most common vectors seen in first-time simulations. Most environments can handle them in isolation at the network layer. The failure point appears when these same vectors are combined with application-layer traffic, where coordination between layers breaks down, and mitigation becomes inconsistent.
Application Layer Attacks (Layer 7)
How they work
Application layer attacks (often referred to as Layer 7 DDoS attacks) target the application itself rather than the network or connection layer. Instead of overwhelming bandwidth or exhausting connection tables, they focus on how the application processes requests, using vectors like HTTP/HTTPS floods, slowloris attacks, Large File Download/Upload, and API exhaustion.
What makes these attacks difficult to detect is that the traffic often looks legitimate. Requests follow normal protocols, use valid sessions, and don’t trigger obvious bandwidth spikes, which means traditional filtering tools have little to latch onto.
The goal is to exhaust proxies or server-side resources – CPU, memory, connection pools, or thread capacity – or to overload backend systems such as APIs and databases until performance degrades or the service becomes unavailable.
What Red Button sees in testing
Application-layer DDoS attacks are the most consistent failure point in simulation testing. Across Red Button engagements, 68% of identified faults were rated severe or critical, with most tied to Layer 7 vectors that bypassed expected protections, or have no protection at all.
In the European Central Bank (ECB) test scenario, 2 out of 7 application-layer attack vectors targeting the VOP payment service went undetected. A HTTPS POST flood exceeded rate-limit thresholds without triggering Cloudflare rules, allowing the attack to degrade the service without mitigation.
The European government agency simulation revealed a similar gap: Azure WAF rate-limiting rules failed to activate during application-layer attacks, resulting in zero mitigation on API-targeted vectors despite protections being in place.
In a different environment for a gaming company case study, 6 out of 7 hit-and-run Layer 7 attacks were successfully mitigated, but one vector bypassed Cloudflare entirely. Within two minutes, it triggered an SSL failure and caused a full service outage, highlighting how a single missed vector at this layer can have immediate impact.
Multi-Vector Attacks: The Real Threat
DDoS attacks rarely stay within a single category. Modern campaigns combine volumetric, protocol, and application layer vectors to overwhelm defenses that are designed to handle each layer in isolation. A high-volume UDP flood might saturate bandwidth, while SYN floods target connection handling, and Layer 7 requests quietly exhaust application resources, all at the same time.
The problem is that these layers don’t always work together as expected. A misconfiguration, blind spot, or delay at any point creates an entry path, even when all the “right” tools are in place.
This is where most real-world failures happen. Not because protection is missing, but because it hasn’t been tested across combinations of attack types. Red Button simulations cover 100+ DDoS attack vectors, including multi-vector scenarios, to expose how these gaps appear under coordinated pressure.
Quick Reference: DDoS Attack Types
| Category |
OSI Layer |
Example Vectors |
Target |
Detected By |
| Volumetric |
L3 |
UDP flood, DNS amplification, NTP amplification |
Bandwidth |
CDNs, scrubbing center, ISP |
| Protocol |
L4 |
SYN flood, ACK flood, TLS reconnection |
Connection state tables |
Firewall, load balancer |
| Application Layer |
L7 |
HTTP flood, POST flood, slowloris |
Server/app resources |
WAF, rate limiting |
Knowing the DDoS Attack Types Is Not Enough, You Need to Test Against Them
Across Red Button DDoS attack simulations, the average DDoS Resilience Score (DRS) on the first test sits at ~3.0, well below the recommended 4.5–5.0 baseline. Not because protection is missing, but because it hasn’t been tested against the full range of attack types and combinations.
Most organizations validate a handful of scenarios – often basic volumetric or SYN flood tests – and assume the rest of the stack will hold. It usually doesn’t. The gaps only show up when different attack types are executed together, under real pressure. At the same time, attackers aren’t thinking in categories – modern campaigns increasingly combine vectors across layers and adapt in real time. What matters isn’t whether you can stop one attack type; it’s whether your defenses hold when everything is happening at once.
Find out which attack types your stack can and cannot handle. Request a DDoS simulation test →
FAQs
What are the main types of DDoS attacks?
DDoS attacks fall into three categories: volumetric (Layer 3), protocol (Layer 4), and application layer (Layer 7), each targeting a different part of the stack.
Which DDoS attack type is the hardest to detect?
Application layer (L7) attacks are the hardest to detect because they mimic legitimate user behavior and don’t create obvious traffic spikes.
Do all DDoS attacks require the same mitigation approach?
No. While Layer 3 and 4 attacks are often mitigated similarly, Layer 7 attacks require more advanced, application-aware protections.
What is a multi-vector DDoS attack?
A multi-vector attack combines multiple attack types across layers, overwhelming defenses that are designed to handle each layer separately.
Why is testing against different DDoS attack types important?
Most organizations only test a limited set of scenarios, leaving gaps that only appear during real-world or multi-vector attacks.
