A Real Failure Before the Fix
In early 2025, a mid-sized financial services firm running a cloud-hosted trading platform suffered a sustained application-layer DDoS attack that brought their platform down for four hours during peak trading hours. They had a scrubbing center contract. They had rate limiting in place. They had a WAF. All of it failed to protect them because the attack bypassed volumetric thresholds entirely, arriving as a flood of syntactically valid HTTP/2 POST requests to their authentication endpoint, each one appearing, to every inspection layer, as legitimate user traffic.
The attack didn't saturate their upstream bandwidth. It saturated their backend application servers by exhausting database connection pools. The scrubbing center passed the traffic. The WAF passed the traffic. The rate limiter passed the traffic because the requests came from thousands of distinct IP addresses across more than 40 countries, most of them compromised residential endpoints — not datacenter ranges flagged by reputation lists.
This scenario repeats across industries. The organizations that survive it aren't the ones with the largest mitigation budgets. They're the ones that built layered, operationally realistic defenses instead of assuming a single vendor relationship would cover every attack class.
Understanding What You're Actually Defending Against
DDoS attacks in 2026 fall into three broad categories, and conflating them leads to misconfigured defenses.
Volumetric attacks aim to exhaust bandwidth or transit capacity. These are the terabit-scale floods that make headlines. Tools like Mirai-variant botnets and amplification techniques using DNS, NTP, and SSDP protocols still generate the majority of volumetric incidents. The Iranian hackers who targeted major South Korean electronics firms used volumetric DDoS as a distraction technique during intrusion campaigns, a pattern that's grown significantly more common since 2023.
Protocol attacks exploit weaknesses in Layer 3 and Layer 4 protocols to exhaust stateful infrastructure like firewalls and load balancers. SYN floods, ACK floods, and fragmented packet attacks fall here. A stateful firewall that can handle 10 million connections per second can still be knocked offline by a well-crafted protocol attack that exceeds its state table capacity.
Application-layer attacks are the most operationally complex to handle. They're low-volume, high-impact, and designed to look like real users. HTTP floods targeting login endpoints, slow-read attacks that hold connections open, and HTTPS-based attacks that require full TLS decryption to inspect are all part of this category. The scenario described at the start of this article was an application-layer attack, and it's the class that most organizations are least equipped to handle.
Why Scrubbing Centers Have Defined Limits
Cloud-based DDoS scrubbing centers absorb traffic by routing it through mitigation infrastructure before it reaches your network. For volumetric and most protocol attacks, they work well. The traffic never reaches your routers or firewalls at scale.
The limitations emerge at the application layer. Scrubbing centers typically operate on network-level signals: source IP reputation, traffic volume, packet rate, protocol anomalies. They're designed for speed, which means deep inspection of application payloads, session behavior, and user interaction patterns is either unavailable or comes with significant latency tradeoffs.
More critically, scrubbing centers respond after the attack reaches a detection threshold. During the detection-to-mitigation window, which typically runs between 30 seconds and several minutes depending on the provider and configuration, your infrastructure absorbs the attack unmitigated. For high-volume attacks, that window is survivable. For application-layer attacks targeting a single critical endpoint, it can be fatal to service availability before mitigation engages.
Organizations should evaluate scrubbing center providers on the following operational criteria rather than headline throughput numbers:
- Time-to-mitigate for application-layer attack classes, not just volumetric
- Always-on versus on-demand routing modes and the latency impact of each
- Anycast versus unicast scrubbing infrastructure and geographic coverage relative to your user base
- The provider's BGP integration model and how quickly routes can propagate during an attack
- Support for custom mitigation rules and how quickly those rules can be deployed during an active incident
Building Defense Layers Before the Attack Arrives
Effective DDoS mitigation is not a product you buy. It's an architecture you build and test. Here is how practitioners structure it in operational environments.
Upstream Capacity and Transit Diversity
Your ISP or upstream transit provider is your first line of defense for volumetric attacks. Organizations that rely on a single transit provider with a single upstream ASN have a structural vulnerability that no downstream mitigation tool can fully compensate for. Announce your prefixes from multiple transit providers. Ensure BGP configuration supports rapid traffic diversion if one upstream path is flooded or becomes unavailable.
Many organizations running on cloud infrastructure assume the cloud provider handles this. AWS Shield Advanced, Azure DDoS Protection, and Google Cloud Armor all provide volumetric protection at the cloud network edge. They do handle substantial volumetric attacks. They don't replace an operationally tested incident response procedure for application-layer attacks against your specific application logic.
Anycast Distribution for Service Delivery
Deploying services behind anycast CDN infrastructure spreads volumetric traffic across a geographically distributed set of PoPs. An attack that might overwhelm a single data center origin is absorbed across dozens of network edges, each contributing scrubbing capacity. This architecture also provides latency benefits for legitimate users, which makes it straightforward to justify operationally.
The tradeoff is that anycast infrastructure introduces complexity in monitoring and logging. Source IP visibility changes when traffic is proxied, which affects threat intelligence workflows, IP reputation scoring, and incident correlation. Teams that implement anycast CDN need to also update their SIEM ingestion pipelines to account for proxy IP headers and ensure X-Forwarded-For or equivalent fields are correctly parsed and stored.
Rate Limiting With Behavioral Context
Simple rate limiting by source IP is inadequate against distributed attacks that source traffic from thousands of residential endpoints. Rate limiting should incorporate behavioral signals alongside raw request rate.
Practical approaches include:
- Rate limiting by endpoint fingerprint rather than just source IP, combining User-Agent, TLS JA3 fingerprint, HTTP header order, and request timing patterns
- Applying stricter rate limits to unauthenticated endpoints than authenticated ones, since authentication endpoints are high-value targets for credential-stuffing-combined DDoS attacks
- Implementing progressive response policies where clients hitting threshold boundaries receive challenge responses (CAPTCHA, JavaScript challenges) rather than immediate hard blocks
- Tracking session-level metrics across requests to detect slow-loris and slow-read attacks that fall below per-second rate limits
Rate limiting should be configured at the edge, as close to the network perimeter as possible, not at the application server. Rate limiting implemented in application code runs after the connection has already been accepted and the server has already consumed resources to process the request.
BGP Blackholing and RTBH as Operational Tools
Remote Triggered Blackhole (RTBH) routing allows you to signal your upstream providers to drop traffic destined for a specific IP or prefix before it enters your network. For volumetric attacks targeting a single IP address, RTBH can protect the rest of your infrastructure while the targeted IP is temporarily unreachable. This is a deliberately blunt instrument. The targeted resource becomes unavailable for legitimate users as well as attackers. The operational value is that it protects the broader infrastructure from collateral damage when a single endpoint is under heavy attack.
Many operators pair RTBH with a scrubbing center in a selective routing model: traffic to attacked prefixes is diverted to the scrubbing center rather than blackholed outright, with RTBH as a fallback if scrubbing capacity is insufficient.
Application-Layer Mitigation That Works
For application-layer attacks, mitigation requires understanding the difference between attack traffic and legitimate traffic at the behavioral level. The following controls are implemented in production environments handling significant attack traffic.
Challenge-response mechanisms: Inserting a JavaScript execution challenge or CAPTCHA before granting access to protected endpoints forces attackers to maintain a browser-capable, JavaScript-enabled client. Most automated attack tools fail this requirement. The latency impact on legitimate users is typically 200 to 500 milliseconds on first visit, which is acceptable for most applications. APIs serving machine-to-machine traffic require alternative approaches since they cannot execute JavaScript challenges.
TLS fingerprinting: JA3 and JA3S fingerprints characterize the TLS client and server negotiation pattern. Many DDoS tools and bot frameworks produce distinctive TLS fingerprints that differ from browser-generated ones. Maintaining a blocklist of known attack tool fingerprints and a pattern for legitimate client fingerprints adds a detection layer that operates before any HTTP inspection. This is particularly useful for HTTPS floods because it identifies the attack client before the HTTP request is even parsed.
Connection-level controls at the load balancer: Configure maximum connection durations, minimum transfer rates for incoming data, and maximum header sizes at the load balancer rather than the application. These settings terminate slow-loris and slow-POST attacks before they reach application logic.
Circuit breakers for backend protection: Implement circuit breaker patterns in your application tier so that when a downstream service (database, cache, internal API) approaches capacity limits, the application tier begins rejecting requests with fast error responses rather than queuing them. A queuing request holds a connection open and consumes memory. A fast rejection releases the connection and returns a response, which limits the attack's ability to exhaust connection pools.
Detection Before Mitigation: The Intelligence Layer
The 0ktapus campaign that compromised 130 firms demonstrated an important operational reality: sophisticated threat actors use DDoS attacks as cover for lateral movement and credential harvesting, not as standalone operations. During the noise of a volumetric DDoS event, network defenders are overwhelmed, alert queues fill, and the actual intrusion activity happening on adjacent systems goes unnoticed until the DDoS subsides.
Building detection capability means instrumentation that continues to function under attack conditions. This requires:
- Out-of-band logging infrastructure that sends log data to a separate network path not subject to the attack traffic flood
- Pre-defined detection rules for attack commencement that trigger automated response playbooks rather than requiring analyst review before action
- Separation of DDoS response workflows from intrusion detection workflows so that both can operate simultaneously during a compound attack
ASN-level traffic analysis provides early warning for many DDoS campaigns. A sudden increase in traffic sourcing from a specific set of ASNs, particularly those associated with cloud VPS providers or residential ISPs in specific geographic regions, often precedes a full-scale attack by minutes. Automated ASN-level monitoring that alerts on deviation from baseline traffic distribution gives operators time to pre-position mitigation before the attack reaches full volume.
Testing Mitigation Before You Need It
DDoS mitigation that has never been tested is untested mitigation. Operational teams should conduct controlled DDoS simulations against non-production environments on a regular schedule. Vendors including NETSCOUT, IXIA, and specialized red teams offer DDoS testing services that simulate realistic attack profiles against your infrastructure.
Testing should specifically cover:
- Failover behavior when the primary scrubbing center route fails or is unreachable
- Application-layer mitigation response time and false positive rate
- BGP re-routing speed and correctness when attack traffic exceeds upstream thresholds
- Communication and escalation procedures during an active incident
- Recovery time from a sustained attack to normal operational status
Simulated attacks against production infrastructure require careful coordination with your upstream providers, CDN vendors, and cloud platforms. Most providers require advance notice and explicit authorization. The legal and contractual review should happen well before the test date, not during incident planning.
Incident Response for Active DDoS Events
When an attack is in progress, having a documented and rehearsed response procedure is the difference between a four-hour outage and a twenty-minute service interruption. The following structure reflects what operational security teams actually execute during live incidents.
- Declare the incident and activate the response team. Assign an incident commander who has authority to make decisions without escalation loops. DDoS attacks evolve in minutes; decision-making chains that require multiple approval steps are operationally incompatible with effective response.
- Characterize the attack type before applying mitigation. Applying volumetric mitigation to an application-layer attack wastes time. Within the first five minutes, determine whether the attack is volumetric, protocol-based, or application-layer by reviewing traffic volume, packet rates, connection counts, and application error rates simultaneously.
- Engage upstream providers and scrubbing center if not already active. If you're on an on-demand scrubbing model rather than always-on, initiate traffic diversion immediately. Document the time and the contact made.
- Apply targeted mitigations while scrubbing engages. For application-layer attacks, deploy challenge-response on affected endpoints, tighten rate limits, and activate any pre-built firewall rule sets for known attack signatures.
- Monitor for secondary activity. Assign at least one analyst to monitor for intrusion activity on adjacent systems while the primary response team handles the DDoS. The supply-chain attacks and watering hole campaigns documented in recent threat intelligence consistently show attackers exploiting DDoS as a distraction.
- Document and retain traffic data during the attack. PCAP samples, NetFlow data, and application logs from the attack window are valuable for post-incident analysis, threat intelligence contribution, and potential law enforcement referral.
The Long-Tail Operational Considerations
Several operational details separate organizations that handle DDoS incidents well from those that don't, and they're rarely discussed in vendor marketing materials.
IP space management and prefix announcement granularity. Announcing a /24 prefix instead of a larger aggregate gives you the ability to apply RTBH or selective scrubbing to a specific IP range without affecting unrelated addresses. Organizations that announce only their full aggregate block lose this operational flexibility during an attack.
Vendor relationship maintenance outside of incidents. Your scrubbing center's emergency response quality during a live attack depends significantly on whether your account team and their NOC know your network and your traffic baselines. Quarterly check-ins, traffic baseline reviews, and escalation contact updates matter. The organizations that get poor vendor response during incidents are frequently the ones that haven't engaged their vendor since contract signing.
Cost controls for always-on scrubbing. Always-on scrubbing with a major provider introduces consistent latency and per-gigabit pricing that can be prohibitive for high-bandwidth applications. Some organizations implement always-on scrubbing only for their most critical prefixes and on-demand scrubbing for less critical infrastructure. This hybrid model requires more operational discipline but significantly reduces cost while maintaining coverage where it matters most.
Regulatory and notification obligations. Extended DDoS-induced outages in regulated industries frequently trigger incident notification requirements. Financial services firms, healthcare organizations, and critical infrastructure operators should have pre-drafted notification templates and regulatory contact procedures ready before an incident occurs, not written during one.
Where Teams Should Focus Attention Now
Given the current threat landscape, including DDoS being weaponized alongside supply-chain compromises, nation-state intrusion campaigns, and increasingly sophisticated residential botnet infrastructure, the highest-value investments for most operational teams are not larger scrubbing capacity contracts. They are behavioral detection capability at the application layer, tested incident response procedures, and instrumentation that survives attack conditions.
The organizations compromised during the 0ktapus campaign, the Korean electronics firm targeted by Iranian actors, and the gaming platform hit by ScarCruft all faced a common problem: their defenses were configured for threats that came alone, not for threats that arrived in combination. A DDoS event that also conceals an active intrusion requires a security team that can respond to both simultaneously, with instrumentation and procedures that support parallel response tracks.
Building that capability is slower and less satisfying than signing a scrubbing center contract. It's also what actually works when the attack is already in progress and the scrubbing center didn't catch it.
