Shortly before 9 p.m., a company came under fire, with two to three million requests per minute being directed at a single domain. The defences held firm, blocking more than 99.9 per cent of the traffic. Nevertheless, around 1,000 requests per minute got through. This was not because the protection failed. The attacker had exploited an assumption on which the protection rules were based.
Total attack volume over its full duration: two to three million requests per minute
A Gap That Wasn’t a Vulnerability
Modern WAF architectures often use rate-limiting rules at the URL level. The underlying logic is sound: if an IP address requests the same URL too frequently, it is blocked. This approach is effective against the vast majority of volumetric attacks, since attackers typically do exactly that — repeatedly hitting the same endpoint, login page, or API route.
This attacker, however, did not. Instead, they generated a new, randomly created URL for every single request, following the pattern /en/ followed by six random lowercase letters. /en/nwbiod/. /en/onoqzi. /en/nlvacu. And so on. Every request, a new URL. Every URL, a new entry. No URL was requested often enough to cross the rate-limit threshold. The protective rules were never triggered because every request appeared to be a legitimate first-time visit to an unknown page.
The highlighted area isolates the traffic that bypassed the WAF architecture due to the random URL pattern.
This wasn’t a zero-day vulnerability. Rather, it was an assumption baked into the rules that was precisely exploited.
Why the CDN Cache Didn’t Absorb the Load
A pertinent question: could an upstream CDN not have intercepted the requests? Normally, yes, but only for static content. Images, scripts and CSS files are cached by the CDN and usually don’t need to reach the origin server.
However, randomly generated URLs don’t exist in the cache by definition. The CDN doesn’t recognise “/en/nwbiod”. Therefore, it forwards the request to the origin server and asks there every single time. This mechanism, known as a CDN cache miss, transformed the random URLs from an evasion tactic into an amplifier: the attacker forced every request to go all the way through to the origin server because no caching layer could intervene. The CDN’s protective effect was effectively switched off for these requests.
Automation as an Attack Tool: What’s Behind URL Rotation
The technique itself — rotating the URL with every request — is not new. In theory, it was conceivable decades ago. What has changed is how quickly and easily it can be implemented today. A simple script generates a URL template using six random lowercase letters. No manual upkeep is needed and no humans are involved. The requests generate themselves.
This is exactly where the real trend lies. It’s not that new attack techniques are emerging; rather, known techniques are becoming scalable and accessible through automation. What once required skill and effort can now be set up in minutes with the right script and readily available cloud infrastructure. In this case, the attacker used a telecommunications provider’s infrastructure and other legitimate network resources as a relay. This resulted in roughly 300 different IP addresses generating two million requests per minute.
Learn more about an easy-to-implement and highly effective WAAP solution.
Everything from a single source, and available as a fully managed service upon request.
What Does This Attack Mean for WAF Architectures and Operators?
URL rate-limiting is effective against the vast majority of volumetric attacks. However, it assumes that attackers will repeatedly target the same endpoint. Anyone using URL randomisation breaks this assumption. Supplementary rules based on URL path structure or regular expressions can address this issue. The important question is not whether the existing rules are strict enough, but whether they reflect the correct threat model.
At the same time, this case shows that upstream protection layers do not provide comprehensive protection. No IT security solution can guarantee one hundred percent protection against every conceivable attack type. Therefore, the origin infrastructure needs to be built to remain stable under load: the software must be up to date, the stack must be hardened and sufficient resources must be available. Anyone relying solely on upstream protection has no plan B when an attacker finds an unknown vulnerability.
Finally, automated systems recognise known patterns. New techniques are recognised by people when escalation processes work and there is enough time to read the logs properly. Sometimes, the vulnerability isn’t where you’re looking for it. Not in the platform. Not in the process. It’s in an assumption that seemed so self-evident that nobody ever questioned it. Six random letters were enough to expose it.
Are you familiar with the assumptions on which your WAF configuration is based, and do you know which of these an attacker could exploit? We analyse your protection architecture and demonstrate where gaps can arise between your rule set and real-world attack methods. Book your free consultation now.
You might also like:
