In recent years, DDoS attacks have become one of the weapons of choice for threat actors who wish to wreak havoc on leading organizations’ online services. DDoS attacks are a simple yet highly effective tool for any attacker who wants to disrupt and deny availability.
These attacks often succeed because traditional DDoS protection is not regularly updated with evolving attack vectors. For example, the the Cloudscraper HTTP/S-GET Flood.
When it comes to DDoS security, organizations lack the necessary visibility into their online services. Adding misconfigurations to the equation, such organizations operate under a false sense of security, which leaves them exposed to successful DDoS attacks, resulting in losses and damages.
What is the Cloudscraper HTTP/S-GET flood?
The Cloudscraper HTTP/S-GET Flood attack is one of the most dangerous HTTPS DDoS attacks today. It is sophisticated enough to bypass many layer 7 protection protocols – an HTTP flood designed to overwhelm web servers’ resources by continuously requesting a chosen URL from many attacking sources.
This DDoS attack vector will be explained in this article in its HTTP nature, but it can also be used by attackers over HTTPS by encapsulating its packets with a secure protocol such as SSL/TLS.
The Cloudscraper HTTP-GET Flood sends HTTP GET requests to online web services. It will bypass the CDN’s anti-bot protections by implementing multiple different parameters inside the HTTP packets of each request.
To make matters worse, the attack vector can successfully pass web-based challenges, such as Captcha.
This makes the CDN service deliver HTTP requests to the back-end origin server, and when the server reaches its limits of concurrent connections, it will no longer respond to legitimate requests from other users – thus, creating a service disruption.
What happens during a Cloudscraper flood attack?
As in many DDoS attacks, the first step is the TCP handshake. Before requesting a web resource with an HTTP GET request, the TCP connection between the client and the server is established, using a 3-Way Handshake (SYN, SYN-ACK, ACK).
Once a TCP connection is established between the client and the server, an HTTP GET request will be transported inside a PSH/ACK packet from the client to the server – a CDN-protected online web service, for example. Multiple HTTP GET request packets will then be sent by the DDoS attacker to the server, with the attacker opening a single TCP-based connection for each HTTP GET request.
Due to its nature, the server takes time to respond to each HTTP GET request, but the DDoS attacker will continue to flood it with more and more HTTP GET requests. This will cause the server to no longer be able to keep up with the request attempts.
And at this point, the damage has been done and the attack is successful.
Discover more elusive attack vectors that evade DDoS protection.
How to protect against DDoS flood attacks?
Regardless of what DDoS protection services an organization employs, the security team must be confident they have complete visibility into the organization’s DDoS security posture. Most DDoS protection providers are still reactive in their approach, mitigating known threats well, but unable to mitigate unknown or misconfigured DDoS attack vectors.
DDoS protection providers and security teams must stay updated and configure their security layers properly, through continuous testing of every attack vector, against every target with no operational downtime. Vulnerabilities should be constantly identified, remediated, and then validated to ensure fully automated DDoS protection: that is the only way to avoid a damaging attack and leaving behind damaging SLAs and emergency scenarios.
