A two-stage DDoS attack with a bandwidth of over one terabit, targeting login, download, and admin sections, shows that modern attackers test systems during an attack as well as beforehand.
There were two waves of attacks, separated by a ten-hour break. In total, over 335 million requests were sent. These included targeted attempts to log into the login area, download files, and access the site’s WordPress admin area. While it may initially appear to be a classic volumetric DDoS attack, closer analysis reveals it to be a hybrid attack, using noise as a distraction and infiltration attempts as the actual goal.
First Wave: Over One Terabit, Yet Hardly Any Damage
The first spike was enormous. It used more than one terabit of bandwidth, involved around 25,000 requests per second and reached a peak of nearly 60 million concurrent sessions. Most of the source IP addresses could be traced back to major cloud and hosting providers. Therefore, this was not a diffuse IoT botnet, but rather concentrated server capacity. However, the Web Application Firewall blocked the vast majority of requests, with fewer than 58,000 reaching the origin server.
Technically, the attack was nothing special. It was a Layer 7 HTTP flood with synthetically rotating user agents. The crucial question, however, is a larger one: Why did 10,000 different IP addresses collectively generate nearly 60 million sessions? This is because the machines behind them were resource-intensive devices, such as servers, rather than home routers or cameras. Such cloud instances can establish hundreds of thousands of parallel connections. An IoT device cannot do that. Ultimately, it comes down to computing power.
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.
Not a pure DDoS – targeted attempts to access sensitive areas
The URL distribution of the requests makes it clear what distinguishes this attack from a typical denial-of-service attack. Rather than bombarding the root path indiscriminately, the attackers specifically targeted download pages and flooded login forms with requests, attempting to access the WordPress admin area. Content filters did not detect any SQL injection or XSS patterns. It seems that the attackers did not intend to exploit security vulnerabilities, but rather to gain access by overwhelming the system with requests: a brute-force attack disguised as a DDoS attack.
Targeted areas:
- Root domain (main target)
- Download/content pages
- Login form
- WordPress admin path
Technical signature of the attack:
- Layer 7 HTTP flood
- Synthetic user agents
- No SQLi or XSS attempts
- Brute-force patterns on the login area
One peculiarity that we observed was that, out of over 300,000 requests, only one managed to slip past the WAF. This is not a configuration error, but a statistical effect that occurs when thousands of seemingly legitimate cloud IP addresses each send a few requests. One of these slips through before the rate-limiting rule takes effect. This may sound like a minor issue; in practice, however, it means that attackers with sufficient distributed resources can systematically undermine mitigation systems, even without a direct bypass exploit.
Second wave: smaller, but with increased latency
Ten hours after the initial spike, a second attack occurred with a volume of around 500 Gbps. Although smaller than the first, it had an interesting effect. Despite being weaker, the second attack caused higher latency than the first. The reason for this is as follows: During the second spike, requests per second were concentrated on the system itself. CPU utilization rose more quickly and automatic scaling had less time to react.
This highlights an often-overlooked truth about DDoS mitigation. Bandwidth is not the only stress factor. The number of requests per second puts strain on the CPU, regardless of the amount of data transferred. Those who focus solely on bandwidth thresholds may miss the point at which a system actually crashes.
The second attack was half the size, but had a greater impact on latency. Why? Because it is the number of requests per second, rather than bandwidth, that determines the CPU load. Therefore, a smaller attack can cause more noticeable damage than a larger one if it hits the right bottlenecks.
Cloud Abuse: A Structural Problem
The origin of the traffic raises an uncomfortable question. Almost all of the larger IP blocks used in attacks are owned by well-known cloud and hosting providers. These IP addresses are whitelisted in many systems, not due to negligence, but because legitimate services regularly communicate via these addresses. Anyone who builds a traffic filter that blocks Microsoft IP addresses by default, for example, will also block a large proportion of normal traffic.
This is precisely the structural problem: cloud infrastructure is inexpensive and can be booked anonymously, and it is technically trustworthy. From a defender’s perspective, it is almost secondary whether these resources were purchased, rented, or compromised. The fact is that attacks of this scale, involving over a terabit and hundreds of millions of requests, now occur monthly. Such attacks were significantly rarer two years ago.
Behavior-based detection is more effective than IP reputation. Anyone who simply waits for known ‘bad actors’ is lagging behind reality. The key is to identify anomalous behavior at the application level early on. This applies regardless of which data center the traffic originates from.
Do you have questions about how to effectively protect yourself against cyberattacks? Our security experts are available to assist you around the clock.
You might also like:
