DDoS Attacks Grow More Sophisticated as Imperva Mitigates Largest Attack

Only a few months ago Imperva reported mitigating against two of the largest DDoS attacks of 2020. However, in the past few weeks we’ve observed a rise in the number of DDoS attacks against our customers where both the volume of attacks and their level of intensity have increased significantly. One such attack peaked at nearly 1Tbps, breaking Imperva’s record to date.

Technical breakdown

This attack is of interest not simply because of its scale – the largest Imperva has had to mitigate against – but also due to its sophisticated nature compared to other attacks of this size, which commonly consist of amplification vectors. Read more about amplification vector attacks here.

In this case, the attackers combined two separate vectors, Large SYN and TCP, which they leveraged in two waves. The first consisted of a 90 second burst of Large SYN flood – basically a SYN flood with a large payload, unrecognized by the RFC, the document that describes a SYN packet. A SYN flood consumes server resources by creating endless half-open TCP connections. The combination of server exhaustion by SYN flood with a volumetric attack is what makes a large SYN vector so harmful. This initial burst was so powerful that it peaked at 674Gbps and 148Mpps in under five seconds, emphasising how important it is to start mitigation within seconds. Furthermore, this type of attack would be impossible to mitigate with an on-premise or hybrid DDoS approach where the upstream connectivity would be overwhelmed.

What’s also interesting about this particular attack is that the attackers used a tool similar to that seen in the largest packets per-second attack we mitigated last year. The tool attempts to conceal the attacking packets as legitimate traffic by mimicking an Operating System. However, the tool apparently contains a bug because it ends up sending malformed packets.

The second wave of the attack consisted of a TCP ACK flood aimed at port 443, which mimicked the customer’s legitimate traffic by using large HTTPs packets. Despite the customer owning multiple IP ranges, the entire attack targeted only a handful of IPs – in this case those hosting the customer’s main services. This suggests that a certain amount of research and reconnaissance had been undertaken by the attacker in advance, enabling them to identify the most vulnerable target IPs and carry out a more sophisticated attack.

In addition, we observed that all the attacking IPs belonged to a company offering free cloud servers and, while it’s common practice for hackers to spoof IPs in network DDoS attacks, the location of the attacking IPs matched the destination server, which would suggest that the IPs weren’t spoofed and that cloud servers had possibly been used to generate the actual traffic or as a proxy. This would indicate once again that the attackers had really done their homework ahead of the attack in order to collect such a large number of cloud servers.

Alternatively, the IPs may have been spoofed, but in a minimal enough way to enable retaining the original location of the IPs. In both instances, whether the attackers spoofed the IPs or used real cloud servers, they’d clearly gone to great efforts to put more obstacles in the way of mitigating the attack and improving their chances of creating an impact.

On the whole, our findings indicate that this wasn’t a random DDoS attack but that the attackers had done their research, enabling them to carry out a highly sophisticated and targeted attack tailored to the customer.

Learn more about our DDoS Protection Solutions here.