A customer hired us to prove their DDoS protection could take a punch. Their cloud provider's protection bundle was switched on, the box was checked, and honestly, I walked in expecting a quiet day. You do not knock over an asset sitting behind a mature scrubbing service. Then we looked closer, and the quiet day turned into one of the more useful findings we have handed a client in a while. Here is what happened, with the client details left out on purpose.
The brief: a test we expected to lose
The ask was simple. Run a controlled DDoS simulation against one core, revenue-generating application hosted on a major cloud provider. The provider's DDoS protection bundle was enabled on the account. Everyone in the room, us included, assumed the exercise would mostly confirm that the money spent on protection was doing its job.
I said as much to the customer before we started. I would rather set an honest expectation and be pleasantly surprised than oversell a test. My working theory was that we would generate traffic, the scrubbing layer would soak it up, and we would write a report that said, in plain terms, "good news, it holds."
That is not what happened.
Surprise one: protected everywhere except the asset we were testing
We map the environment before we fire anything. Always. Hitting blind is how you cause real damage, so reconnaissance comes first. And while we mapped it, something looked off.
The DDoS protection was enabled. On almost everything. Every asset in the account carried the protection profile, with a single exception.
The core application we had been hired to test.
When the protection was rolled out, the one asset that mattered most had been left out of scope. It was not disabled on purpose. It was not a documented exception with a reason next to it. It was simply missed. The server that would hurt the most to lose was the one server standing in the open.
So the test we expected to "lose," meaning the protection would win, was suddenly wide open. We generated traffic inside our agreed guardrails and watched the asset degrade the way an unprotected asset does. The bundle the customer paid for never touched it, because as far as the configuration was concerned, that asset was not part of the deal.
The server that would hurt the most to lose was the one server standing in the open.
Surprise two: the protected assets were bypassable anyway
This is where an isolated mistake turned into a pattern worth writing up.
We turned to the assets that did have protection. The ones that, on paper, were fine. They were not.
The protection was bound to the front door: traffic that came in through the provider's scrubbing and CDN layer. But the origin behind that door was reachable directly. Old DNS records, certificate transparency logs, and a couple of subdomains pointing straight at the origin gave away the real address. Once you have the origin, you walk around the scrubbing layer and knock on the back, which has no protection at all. No exotic tooling. No zero-day. Just well-known evasion that any competent attacker tries in the first hour.
A few other assets had thresholds and rules set so loosely that traffic which should have tripped mitigation sailed straight through. Protection that never triggers is decoration.
Why this happens, and why nobody catches it
None of this came from a careless team. The customer had good engineers and a real security budget. This is just what happens when protection is treated as a purchase instead of a control you verify.
Cloud DDoS bundles are easy to enable and easy to assume. You switch them on, the console shows a reassuring green state, and the invoice says "protected." Nobody circles back to ask the two questions that actually matter: is it covering the asset I care about, and can it be walked around. A dashboard does not answer those. Generating real attack traffic and watching what the environment does answers those.
And configurations drift. New assets ship. Someone migrates a service and forgets to reapply the profile. DNS quietly accumulates history that leaks your origin. A year later, the picture on the console and the picture an attacker sees have drifted apart, and nobody sent a memo.
The lesson: enabled is not the same as working
The customer left with three concrete fixes: bring the core asset into the protection scope, lock the origin so it is only reachable through the scrubbing layer, and tighten the mitigation thresholds so they actually fire. Small changes. The kind you make on a calm Tuesday instead of during an outage with the CEO refreshing the status page.
The bigger takeaway is the one I keep coming back to. "DDoS protection: enabled" is a statement about billing. It is not a statement about resilience. The only way to know your protection works is to test it under realistic load, on purpose, before an attacker runs that test for you and sends you the results as downtime.
That gap between what the console reports and what actually holds is exactly what our CaosBlitz DDoS simulation exists to find. Controlled, scoped, live-fire testing across layers 3 to 7, with evidence your engineers and your board can both act on.
Assume nothing. Test the thing you cannot afford to lose.
See how controlled CaosBlitz DDoS simulation works, or book a quick scoping call and we will pressure-test your assumptions before an attacker does.
