Blog DDoS Attacks

DDoS Attack Types Explained: Volumetric, Protocol, and Application Layer Attacks

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 →