DDoS Attacks

What it is

A denial of service attack tries to make a service unavailable to legitimate users. A distributed denial of service attack does the same thing using many sources at once, often hundreds of thousands of compromised devices, to overwhelm defences that would absorb a single attacker easily.

DDoS sits in a strange position in the threat landscape. It rarely steals data. It does not usually cost a target its long-term security posture. What it does is take you off the internet for hours or days, with all the revenue, reputation, and operational impact that implies. For some sectors (e-commerce during peak season, gaming, financial services, news outlets during major events) that is enough to be an existential issue.

The three categories

Practitioners group DDoS attacks into three broad categories. Most large incidents combine elements of several.

Volumetric (network-layer)

The classic shape. The attacker generates more traffic than the target's connectivity can carry. Pipes fill, packets drop, the service becomes unreachable.

Volumetric attacks are measured in bits per second (Gbps or Tbps) and packets per second (Mpps or Gpps). Common techniques:

• UDP amplification. Send a small request to a public service that replies with a much larger response, with the source IP spoofed to be the victim. DNS, NTP, memcached, and CLDAP have all been used. Memcached amplification reached factors above 50,000 to 1 in 2018.
• Direct flood from botnets. Compromised IoT devices, routers, and servers each send modest traffic. Multiplied across hundreds of thousands of devices, it adds up.
• Reflection across millions of sources. Even tiny per-source bandwidth becomes overwhelming when sources number in the millions.

Volumetric attacks are loud and visible. Modern scrubbing centres handle most of them with anycast and traffic engineering.

Protocol and state-exhaustion

These attacks target finite resources in network equipment or the operating system rather than raw bandwidth. Examples:

• SYN floods. Open TCP connections never completed. Each one occupies a slot in the kernel's connection table until it times out.
• TCP RST or ACK floods. Force the target to process and discard a flood of out-of-state packets.
• HTTP/2 Rapid Reset (CVE-2023-44487). A protocol-level flaw that let a single client open and reset HTTP/2 streams faster than servers could clean up. Google saw the 398 million requests per second attack using this technique in August 2023.
• TLS handshake exhaustion. Each handshake costs CPU. A flood of partial handshakes can saturate a server long before bandwidth is the bottleneck.

These attacks measure their effect in connections per second, requests per second, or CPU saturation rather than raw bandwidth. They are often more damaging per gigabit than volumetric floods.

Application-layer (L7)

The hardest to defend against. The traffic looks legitimate at the network level. It is well-formed HTTP requests hitting real endpoints. The damage comes from what those endpoints have to do.

• HTTP flood. Many requests to expensive endpoints. Search, login, checkout. Each request triggers database queries, API calls, or backend processing.
• Slowloris and slow read. Hold connections open by trickling data. Servers run out of worker threads.
• Cache-busting requests. Vary parameters so each request misses cache and hits the origin.
• Targeted business logic. Hammer the most expensive workflows the application offers.

A volumetric attack can be filtered upstream. An application-layer attack often requires understanding the application to distinguish bots from users. This is where bot management, JavaScript challenges, and behavioural analysis come in.

Why it matters

The headline scale of DDoS keeps climbing. A few markers from the past few years:

• 2018. Memcached amplification produces a 1.7 Tbps attack against an arbor customer.
• 2020. AWS reports defending a 2.3 Tbps CLDAP reflection attack.
• 2023. Google, Cloudflare, and AWS jointly disclose HTTP/2 Rapid Reset. Google measures 398 million requests per second at peak.
• 2024. Cloudflare reports blocking 5.6 Tbps in a single attack, with multiple Tbps-class attacks per quarter becoming routine.

What changed is the supply of compromised devices. The Mirai botnet of 2016 set the template. Its descendants run on hundreds of thousands of poorly secured IoT devices, home routers, and surveillance cameras. The cost of launching a multi-Gbps attack has fallen to consumer pricing on stresser services, sometimes called booter services, that openly market themselves online despite occasional takedowns.

Even organisations that are not the intended target get hit. Shared hosting providers, regional ISPs, and cloud regions all suffer collateral damage when a large attack lands on a tenant. Resilience is not just about being attractive to attackers.

How attackers exploit it

The DDoS attacker workflow has matured into something close to a service industry.

1. Acquire firepower. Either build a botnet (compromise devices, install bot software, manage them via C2) or rent capacity from a stresser service. Stresser pricing in 2026 starts at single digits per hour for low-end attacks.
2. Pick a target. For ransom DDoS, identify a target with revenue sensitivity to downtime. For hacktivism, pick a target tied to a current cause. For competition, target a rival service.
3. Probe defences. Send small bursts. Watch how defences respond. Identify which protections are upstream and which are at the origin.
4. Launch. Combine techniques. Volumetric to saturate bandwidth, application-layer to bypass scrubbing, protocol-level to exhaust state.
5. Adjust. When defenders block one vector, switch to another. Modern attacks rotate techniques every few minutes.
6. Demand or disappear. Ransom DDoS notes typically arrive before or during the attack with demands in cryptocurrency. Some campaigns have published hit lists publicly to pressure targets.

Groups like Fancy Lazarus (an extortion group impersonating a more famous APT) ran extensive ransom DDoS campaigns against financial services in 2020 to 2021. Killnet, NoName057, and various other politically aligned groups have run DDoS as part of broader influence operations.

How to detect it

DDoS detection is straightforward in shape: you measure traffic, you compare it to baseline, you alert on deviations.

• Traffic anomaly detection. Inbound packets per second, bits per second, requests per second. Sudden spikes get flagged.
• Origin saturation indicators. CPU, memory, connection counts. When the application starts struggling before the network does, the attack is application-layer.
• Geographic and ASN distribution shifts. Most legitimate traffic comes from a predictable distribution of countries and providers. Sudden traffic from regions you do not normally serve, or from unusual ASNs, is a signal.
• Request pattern fingerprinting. Unusual user agents, missing referers, lack of cookies, high request rates per source. None of these alone proves a DDoS, but in combination they distinguish attack traffic from a viral marketing moment.
• Upstream telemetry. CDN and DDoS protection providers see attacks before they reach the origin. Their dashboards and alerting are usually the earliest signal.

For ransom DDoS specifically, the email demand often arrives before the attack. Treat any DDoS extortion email as credible until proven otherwise.

How to remediate

If you are being attacked right now, the response sequence is roughly:

1. Engage your DDoS protection provider. If you use Cloudflare, Akamai, AWS Shield, or similar, this is when you escalate. Most providers have an attack-time hotline. Know the number before you need it.
2. Tighten upstream filtering. Geo-blocking traffic from regions you do not serve, rate limiting at the edge, JavaScript challenges, CAPTCHA where appropriate.
3. Pull origin out of DNS. If the attacker has the origin IP and is bypassing your CDN, change the IP and update DNS. The old IP can be parked or blackholed.
4. Scale capacity if helpful. For application-layer attacks, more origin capacity sometimes lets you ride out the storm. Often it just costs more without ending the attack.
5. Communicate. Status pages, customer notifications, executive updates. The information vacuum during an outage is its own problem.
6. Do not pay ransoms. Paying funds the next attack and rarely stops the current one. Public guidance from law enforcement and regulators is consistent on this.
7. Capture evidence for after. Logs, packet captures, timing information. Useful for post-incident analysis and for any law enforcement involvement.

After the attack ends, the remediation work begins:

• Review what worked and what did not.
• Adjust filtering rules and thresholds.
• Identify any origin assets that were exposed and should not have been.
• Test the playbook so the next response is faster.

Best practices

• Use a DDoS protection provider before you need one. Cloudflare, Akamai, Imperva, AWS Shield Advanced, Google Cloud Armor. Cost is modest relative to the cost of being offline.
• Anycast everything public-facing. Distribute traffic geographically so volumetric attacks dilute across many points of presence.
• Hide your origin. The CDN should be the only path to your application servers. Origin IPs should not be discoverable through DNS history, certificate transparency, or direct probing.
• Rate limit aggressively at the edge. Per IP, per session, per endpoint. Application-layer attacks often produce volumes a single legitimate user never would.
• Have a runbook. Who calls who, what numbers, what authority to apply geo-blocks, how status communication happens. Decide this in calm conditions.
• Test the runbook. Tabletop exercises and, where possible, controlled DDoS testing services.
• Monitor your attack surface for unintentional exposure. Origin IPs leaking through misconfiguration, dev servers reachable directly, status pages that bypass the CDN. Any of these can become the single point an attacker focuses on.
• Plan for collateral damage. Even if you are not targeted, your hosting provider, CDN, or DNS provider might be. Multi-CDN and multi-DNS strategies reduce single points of failure.

A note on prevention

You cannot prevent being targeted by DDoS. The decision is made by the attacker. What you can do is make the cost of attacking you exceed the value of doing so, and the cost of riding out an attack lower than the cost of caving to one.

For most organisations in 2026, that means a competent DDoS protection provider, a clean origin posture, an honest map of what is exposed externally, and a runbook everyone has rehearsed. The attacks will keep getting bigger. The defences have kept up. The gap closes when teams treat DDoS as part of resilience rather than a problem someone else handles.