A few weeks ago we mitigated a 100Gbps Network DDoS attack that turned out to be one of the largest in the Internet’s history. Mitigating such events is no trivial task. However, from a professional standpoint, these volumetric DDoS threats are far from being the most dangerous or complex. Even when “super-sized” to abnormal proportions, network attacks are basic threats that can be defeated by ample network capacity. This is not the case for targeted and technologically sophisticated Application Layer DDoS attacks, whose mitigation requires security brains – not just network brawn.
Documented below is a chronicle of one such attack – a funded multi-vector DDoS, which was one of the most complex threats we ever had to face. What you`ll find here is a tug of war, a persistent and adaptive DDoS event that went on for weeks and never really ceased – even as I write these words. As far as DDoS goes, this was literally everything but the kitchen sink.
Prominent Target
Funded attacks are made against lucrative targets. For obvious reasons we will not reveal our client’s full identify, but we can say that this is a popular trading site belonging to a prominent player in a highly competitive online industry.
Chronologically, the attack occurred shortly after the departure of an ex-partner. This leads us to suspect that there is a connection between both events. This suspicion is corroborated by the intimate knowledge of the “weak points” in the target’s infrastructure, as displayed by the attackers during the DDoS event.
Testing the Water with Volumetric Attacks
The event’s opening shot was a small-scale SYN flood attack, which lasted for less than an hour and peaked at around 30Gbps. Compared to what followed, this attack was relatively unremarkable. The only interesting thing about it was lack of amplification, which led us to believe that it was executed by only one or two sources.
From a mitigation standpoint, network attacks like these represent the most basic of threats, and can be easily mitigated with sufficient network capacity. This was no exception. The low-volume attempt was easily absorbed by Incapsula’s 400GBps network without triggering any major alarms or specific interest.
But the attack was far from over. Just as the SYN flood subsided, the site was hit again by another volumetric attack. This time the aggression came in form of 10M requests/second HTTP flood, which targeted several specifically chosen resource-heavy pages. These attempts were mitigated on-the-spot by our Client Classification algorithms – the outer ring of our Layer 7 DDoS protection. Still, unlike the network attack, the HTTP floods never ceased.
As the event progressed, these attacks continued to hit the site for weeks, serving as a “smokescreen” for other, much more sophisticated, Layer 7 attacks.
Targeted Attacks on Special Resources
Recognizing that the target wouldn’t go down easily, the attackers shifted gear and decided to go after Incapsula itself, by attacking our own special resources (e.g., our temporary blocking pages). These attempts were misguided, as all such assets are also protected by Incapsula and the attack “ which employed the same HTTP flood tactics “ was just as easily mitigated.
Next on the target’s list were the website’s AJAX objects. This was a smart choice, as some bot filtering methods (e.g., JavaScript challenges) will not be completely effective in protecting AJAX resources from Layer 7 attacks. Moreover, attacking AJAX objects ensures direct impact on the database – typically one of the most sensitive chokepoints.
In this case, all AJAX objects belonged to an innocent bystander “ a 3rd party SaaS platform, which was used to support the site’s functions. The fact that the targeted objects were located in a “registered users only” area also says a lot about the attacker’s familiarity with site’s architecture, and also hints at the level of reconnaissance that preceded the attack.
We used the targeted nature of this attack to our advantage during its mitigation. By limiting the number of ‘suspects’ to a small sub-group of registered-only users, we were able to filter out malicious bots by Visitor Reputation while identifying Abnormal Behavior Patterns. Even without relying on Progressive Challenges and other more common mitigation methodologies, our algorithms were able to provide pinpoint identification, thus allowing the SaaS platform to remain fully operational and accessible throughout the attack.
Using Smarter Bots and Browser-Botnet
By this time the attack had already dragged on for a full day, but the worst was still to come. The first indication of these impending troubles was a wave of HTTP floods executed by a new smarter type of bots, which were able to capture session cookies.
Such malicious bots are becoming more and more common, and are used to overcome cookie-reliant DDoS protection solutions. In this case, this cookie challenge is only one of Incapsula’s filtering tools and even as it was bypassed, the attack was stopped by other DDoS protection measures.
What came next wasn’t as simple to prepare for.
The incoming attack was all but transparent, only made noticeable by its impact on the site’s performance. It looked like an abnormally high spike in human traffic. Still, even if the volumes and behavioral patterns were all wrong, every test we performed showed that these were real human visitors.
To prevent damage to our client we selectively deployed CAPTCHA challenges – a relatively low-tech and somewhat disruptive mitigation tool which we only use as a last resort. Even in this case, the CAPTCHA’s were only presented to a very narrow group of visitors (~1%), who sported a specific configuration that matched that of the attacker’s.
It worked but it wasn’t the solution we wanted. While looking for a more transparent approach, we became aware of people who were trying to reach us via our Social Media channels and support ticket, complaining about how Incapsula had “invaded” their desktop browsers.
Investigating these claims led us to the source of the targeted DDoS attack; a large-scale botnet that was using hijacked computers to bombard our customer’s website with browser sessions. While working with the owner of one such compromised PC, we were able to get a hold of the Trojan, and identify it as a PushDo/Cutwail client.
By monitoring the botnet’s client, we saw that it was receiving remote instructions that caused it to open numerous stealthy browser sessions, which were then used to attack our customer’s website. The process was supposed to be transparent but due to some compatibility issues with Vista OS, it actually opened the browser, populating the screen with multiple versions of Incapsula’s blocking page.
With this information in hand, we were able to identify the botnet’s C&C and see how it was abusing over 20,000 compromised machines to launch the attack. Unfortunately, the C&C was removed by the attackers before we could act; however, the intelligence we had was enough to patch a new rule to block further PushDo attacks.
Aftermath
The attack has been raging on for weeks, but it no longer has the ability to affect our client. Featuring a combination of network and application layer threats, as well using sophisticated Layer 7 attack vectors, this event epitomizes “DDoS at its worst”. The chronology of escalation serves as an important reminder of the ever-increasing sophistication of DDoS attack methods. There is no doubt that in the future Layer 7 threats will become more and more dominant, as they are already being used to bypass the more traditional and commonly known defensive methods.
Try Imperva for Free
Protect your business for 30 days on Imperva.
