Extortion by DDoS attack is nothing new. Large botnets can carry out a fairly powerful attack nowadays, which can easily clog several 100 Gbps routes(we have already seen this happen). Fortunately, they are relatively rare because they are expensive. Medium attacks (above 10 Gbps) are encountered more frequently (even several times a month). And smaller ones (under 10 Gbps) are almost a daily occurrence. However, this classical kind of brute force attack (in terms of data volume or packet count) is relatively well detected and filtered. It is worse with application layer attacks, such as those that try to pass themselves off as normal traffic.
An application layer attack (also referred to as a Layer 7 attack) is generally very simple, yet not easy to detect and prevent immediately. It may be a repeated call to a specific page, where the attacker is betting on generating more requests than the target server can handle, or the calls may be spread over multiple pages to make detection more difficult or to look for uncached content (we described this type of attack in the article A wave of new and insidious attacks is coming and WEDOS is ready for it).
In the first case, where the attack is directed at one specific site, the cost to the attacker is lower, so he can perform several such attacks at once. If he automates it nicely and combines it with blackmail, he’ll probably make a lot of money. Want to know how it works?
How do the requests for bail come in
The customer usually has no idea what’s going on. In this particular case, the customer simply wrote to support that his website (eshop) was down. Support passed it on to a technician who wrote back in about 20 minutes that he was being attacked with 50,000 requests (queries to the server) in 30 seconds. Due to the severity of the attack and the fact that the customer had a DNS hosted with us, we set it up straight away in cooperation with our colleagues who are developing our new WEDOS Global Protection.
The customer impatiently writes what he himself can do about it. Our boss inserts himself into the communication and explains that nothing. The volume of requests is so high that the customer cannot do anything. He’ll give him more stats and where the attack is going.
In cooperation with their developer, the customer attempts to remove the site that is the target of the attack. This leads to a large number of 404 errors (the page does not exist). These are handled better by the server, but it doesn’t solve the attack itself (the attacker can change the URL again) and the webserver still has to deal with the connection.
In the next conversation, the boss explains to the customer that it’s nobody’s fault and he can’t really solve it himself, “someone just picked on him”.
The customer responds by forwarding the extortionate email that arrived that day.
Subject: DDoS
Hey. Hey,
as a ransom we want $3000 in Bitcoin for stopping all DDoS attacks.
After
payment, your service will resume as it was automatically.
BTC-Wallet: *****************************************
Thank you for your attention and have a nice rest of the day,
Dark Side
His boss writes back that he definitely shouldn’t pay anything. Our protection will solve it.
Incidentally, in the original conversation with support, he mentioned that it was a repeated outage. For the purpose of this article, we tried to track down the statistics on the server and found a web hosting overload exactly one week before. This led to a number of 503 errors. At that time, the technicians did not examine it in any detail. It seemed to be an unmanaged traffic spike, so the customer was moved to a special server for “overloaders” to avoid affecting other customers on the same physical server.
Even considering this, the striker had to toughen up a lot this time. Because these servers are optimized for impact traffic. If the customer has a well-optimized website (uses cache, etc.), it can withstand a lot (you can find some examples in the article 20 websites with the most traffic on NoLimit, NoLimit Extra and WMS).
Anatomy of an attack
The attack is really simple. One specific URL of the target site is called at short intervals. Malicious traffic comes from compromised devices over HTTP from many IP addresses. So the attack is being carried out by a larger botnet. When the attacker finds out that the site is unavailable, he stops for a while. After the site boots up the attack repeats.
Fortunately, we heard from the customer early and colleagues who develop WEDOS Global Protection were at work on the computer. They quickly added it to the protected sites and modified the DNS record to allow the traffic to go through the protection. Immediately after that, they began to intercept the attacks.
As you can see, during the 1 minute peak period there were over 91,000 malicious requests to the landing page, which the protection stopped.
My colleagues played around with it a bit and tried to filter this kind of attack as best as possible. They alternated different forms of obstacles for the attacker (cookie, redirect, captcha) and optimized it a bit. However, it was enough to loosen the reigns a bit and even the “few” hundred requests that went through in a minute could do damage.
The following statistics are from webserver data. That is, what was entered into the log before the protection was deployed and what passed when colleagues calibrated the protection. On top of all that, there’s our big filter that blocks IP addresses with bad reputations, of which there are hundreds of thousands.
In this case, it was more of a low-budget attack. They did not try to mask the individual requests in any way. Although they were generated by different browsers and operating systems in the header, it was possible to tell that they were attacks and not real traffic by several indications. They could therefore be stopped even with IDS/IPS protection with a suitable configuration.
As for the source of the attack, most of the attacking IP addresses were from Asia and America.
You would not be able to block them yourself (for example, via .htacces). The assailant tried to carry out the attack at the same time. It was more like 10 seconds attack, 50 seconds pause. A test to see if the site is alive. And repeat.
Of course, server administrators have more options to block entire IP ranges quickly. However, if you have multiple customers on the server with you, you certainly don’t want to cut them off from Europe long term. Especially countries like Slovakia and Poland.
However, even if you cut off absolutely everything and left only the Czech Republic, you still can’t help yourself. As you can see in the following graph, the attacks also went through Czech IP addresses and there were a lot of them.
You can check them at abuseipdb.com/check/ These are mostly IP addresses of Czech ISPs, which are often reported to be under attack.
You may be thinking that it would be best to permanently restrict such IP addresses, since they are being attacked from all sides. But behind them there could be a block of flats, a street or even a whole city. Also, the IP address can be dynamically assigned. So if you limit it in some fundamental way, it will have an impact on others. They will lose visitors, customers or be unable to provide the agreed service. Banning and restricting IP addresses is not that simple.
What solutions will we have for these problem attacks?
For now, we are looking for the ideal solution. So far, it looks like a cookie/redirect combination in case the problem IP address and the request from it shows suspicious behavior or has a suspicious header. Then a newcomer to your site would see the following page 1x, where a quick redirect would occur. The attack would not have passed this way.
We think it’s a good compromise. The best part is that this way we will be able to allow even otherwise generally problematic IP addresses, such as exit TOR nodes, to reach you. They are supposed to be used to browse the web anonymously, but in most cases they are only a problem because they are misused for attacks.
Conclusion
There will be more and more attacks like this. You need to prepare for it. Unlike ransomware, where your data is encrypted mostly through your fault, in this case you don’t have to do anything wrong. The attackers don’t even have to pick you out. Their robot simply finds an active eshop, finds the email, creates a unique BTC wallet, sends you a threatening email and launches the attack. Then the extortion email goes to spam and you have no idea.
We believe that by the time this trend takes off, we’ll have the protection up, debugged and deployed 🙂