The 3am Call: Anatomy of a Multi-Vector DDoS Attack

00:03 — The Alert

The PagerDuty notification hits my phone. It's 3:07am Frankfurt time. The message is terse: HTTP flood detected. 2.4 Gbps inbound. Scrubbing active.

This is routine. We see HTTP floods almost daily. Our scrubbing infrastructure—a distributed network of nodes across Europe—handles this kind of volume in its sleep. I check the dashboard from my phone. Traffic is elevated but stable. The customer's site is still responding. False alarm, probably.

I'm about to silence the alert when the second notification arrives.

00:05 — The Escalation

DNS amplification detected. 14.2 Gbps inbound. Multiple reflection sources.

Now I'm awake. DNS amplification is a different beast. Attackers send tiny queries to misconfigured DNS servers, spoofing the victim's IP address. The servers respond with massive payloads—amplifying the attack by 50x or more. It's one of the most efficient volumetric attacks in existence.

14 Gbps is serious. Our scrubbing nodes can handle it, but this is no longer routine. I open my laptop and SSH into the command center. The ops team is already online. The traffic pattern is suspicious: the HTTP flood and DNS amplification started seconds apart. Coincidence? Unlikely.

00:07 — The Third Vector

The third alert doesn't come from PagerDuty. It comes from our internal monitoring: Direct hit on scrubbing node FRA-03. TCP SYN flood. 8.9 Gbps.

This changes everything. The attacker isn't just targeting the customer—they're targeting us. Our scrubbing infrastructure is under direct assault.

Here's what most people don't understand about DDoS defense: the scrubbing nodes themselves are a target. If an attacker can overwhelm or bypass the scrubbers, the victim's traffic has nowhere to go. It's like attacking the fire department while the building burns.

The pattern is now clear: this is a multi-vector attack. HTTP flood to saturate application resources. DNS amplification to consume bandwidth. TCP SYN flood to disable the scrubbing infrastructure. Whoever is behind this knows what they're doing.

00:09 — The Response

Our playbook for multi-vector attacks is simple: isolate, absorb, redirect.

Step 1: Isolate. We spin up additional scrubbing capacity in Amsterdam and Munich. Traffic is automatically redistributed using BGP anycast—if one node is under pressure, the routing protocol shifts load to the nearest healthy node. This is why we don't rely on a single scrubbing location. Redundancy isn't optional; it's the foundation.

Step 2: Absorb. The DNS amplification is handled by our reflection mitigation layer. We maintain a real-time blacklist of open resolvers (DNS servers that can be abused for amplification attacks). As soon as we detect reflection traffic, we drop it at the edge—before it even reaches the scrubbing nodes. The 14 Gbps drops to 2 Gbps within 30 seconds.

Step 3: Redirect. The TCP SYN flood targeting our scrubbing node is trickier. SYN floods exploit the TCP handshake by sending thousands of connection requests without completing them. The server's connection table fills up, and legitimate traffic gets dropped.

Our mitigation: SYN cookies. Instead of allocating resources for every half-open connection, we encode the connection state into the SYN-ACK response itself. If the client completes the handshake, we reconstruct the state. If not, no resources are wasted. It's stateless defense for a stateful protocol.

00:12 — The Lull

By 3:19am, the traffic has stabilized. The HTTP flood is still active, but it's now well within normal mitigation capacity. The DNS amplification has been neutered. The SYN flood is being absorbed by SYN cookies. The customer's site is online and responsive.

This is the part that never makes the headlines: the attack is still happening. But from the customer's perspective, everything is normal. They're serving traffic, processing orders, and their users have no idea that millions of malicious packets are being filtered out in real-time.

We don't "stop" DDoS attacks. We absorb them.

00:45 — The Post-Mortem (While Still Under Fire)

The attack continues for another two hours. This is typical. Most DDoS attacks aren't surgical strikes—they're endurance tests. The attacker is hoping we'll run out of capacity, make a mistake, or just get tired.

We don't. By 5:30am, the traffic tapers off. The attacker gives up—or moves on to another target.

We run the post-mortem immediately, while the data is fresh:

• Attack duration: 2 hours 23 minutes
• Peak bandwidth: 23.8 Gbps (DNS amplification)
• Vectors: HTTP flood, DNS amplification, TCP SYN flood
• Customer downtime: 0 seconds
• Scrubbing nodes impacted: 1 (FRA-03, recovered in 4 minutes)

The attacker was sophisticated. They knew our infrastructure well enough to target scrubbing nodes directly. They coordinated three simultaneous vectors. They sustained the attack for over two hours.

But they failed. And here's why.

Why We Win (Most of the Time)

1. Architecture beats heroics. This wasn't won by a genius engineer making a brilliant decision at 3am. It was won by infrastructure designed for exactly this scenario: redundant scrubbing nodes, BGP anycast, stateless mitigation, real-time reflection blacklists. The system didn't need us to save it. It saved itself.

2. Defense scales differently than offense. The attacker needed to rent 20+ Gbps of botnet capacity, coordinate three attack vectors, and maintain pressure for hours. We needed to add two scrubbing nodes and activate SYN cookies. Asymmetry favors the defender—if the defender is prepared.

3. Visibility is the first line of defense. We detected the attack within seconds. Most companies don't even know they're under attack until customers start complaining. By then, the damage is done. You can't defend what you can't see.

4. The network is the firewall. Traditional firewalls inspect packets at the perimeter. By the time a 20 Gbps flood reaches your firewall, it's already too late—your pipe is saturated. The only way to defend against volumetric attacks is to filter traffic upstream, in the network itself. That's why BGP and anycast aren't just nice-to-have—they're existential.

The Uncomfortable Truth

Here's what I don't talk about in sales meetings: we can't stop every attack. If an attacker has 200 Gbps of capacity and targets a weak link in the chain—an unprotected DNS server, an exposed origin IP, a misconfigured edge—they can still win.

DDoS defense isn't about being invincible. It's about being expensive to attack. If taking down your infrastructure costs the attacker $10,000 in botnet rental fees and three hours of coordination, most attackers will move on to an easier target. Defense is about raising the cost of attack until it's no longer worth it.

That's the real game. Not "unbreakable protection," but "uneconomical to break."

The Morning After

At 8am, I'm back on a call with the customer. They have no idea how close they came to a total outage. From their perspective, it was just another night. Their site stayed up. Their revenue kept flowing.

That's the goal. Invisible defense. The best security is the kind you never notice—until it's not there.

The attack logs are already being analyzed by our threat intelligence team. The botnet IPs are being added to our global blocklist. The scrubbing node in Frankfurt is being hardened. And somewhere, an attacker is probably writing their own post-mortem, trying to figure out why their 20+ Gbps assault failed to take down a mid-sized e-commerce site.

Welcome to the internet in 2026. The attacks are faster, smarter, and more coordinated than ever. But so are we.

Sleep is optional. Infrastructure is not.

---