Two more examples of application layer attacks on our customers


Last month, we showed you in the article “DDoS extortion cases on the application layer are starting to appear ” how the extortion and subsequent DDoS attack on a customer’s website takes place. We know that these cases are gradually increasing, but the pace is accelerating unpleasantly. In addition, we can see from the analysis of logs that attackers are trying to mask their attacks better, trying new methods and looking for the limits of protection.

What is an application layer attack

An application layer attack (technically a Layer 7 attack) attempts to overload your website directly. It can be simple queries about a web page by a script, simulated web browsing by a robot or even seemingly legitimate traffic when the user has no idea that he is overloading someone else’s page because the access is through a leaky application or iframe.

If you don’t have an optimized website or if you have some vulnerability in the form of a challenging script, you don’t even need more devices for a successful attack. Thus, it is a DoS attack (Denial of service). However, what we are dealing with is already a coordinated attack of multiple devices that are carrying out the attack together. These attacks are known as DDoS (Distributed denial of service).

Who is carrying out these attacks

If a device (PC, mobile, server, router, smart fridge, IP cameras, etc.) is compromised and taken over by an attacker, it is put into a so-called botnet. The attacker then controls the botnet via C&C (Command and Control) servers.

The botnet may also include compromised sites where there is a hidden backdoor and a script to execute orders that come from the C&C server.

Large botnets (thousands to millions of devices) are controlled by organized groups whose goal is to make money. Thus, most botnets perform the activities that earn them the most money. Currently, it’s mainly ransomware, phishing, stealing sensitive data and getting other devices into the botnet.

Botnets are usually capable of various types of DDoS attacks. If someone pays, they can carry out these attacks.

Case #1 – eshop target, $4500 USD payout

In January, we encountered the first case where our customer was blackmailed by a DDoS attack on the application layer. He also sent us an email from the extortionists asking for $3000 in bitcoin (see previous article). Since the times matched, we assume it was indeed from the striker.

Now the situation was similar. We don’t have a sample e-mail. Just a customer wrote to us that someone wants $4500 in bitcoin. According to the traffic analysis and request headers, we assume that it was the same attacker.

Unlike the previous attack, which was very poorly disguised and it was enough to group the data in a suitable way to get the exact rules for blocking, this one was a bit more sophisticated.

What was really interesting was that he went after non-existent sites. Basically every approach called for:


where the string was composed of 12 alphanumeric characters. In the log, the accesses from the attacker looked like this:

Attacks on non-existent sites. Trying to avoid detection or cached content.

In this attack, it depends on how you have set up 404 error handling, i.e. non-existent pages. If it is handled by the editorial system, such requests are usually not cached and overload can occur very quickly. The ideal is to redirect via .htacces to a static HTML page or to display an error message.

Since it’s 1 access per 1 URL, such attacks can get lost in the log very easily. Of course, forget that you will see these approaches in traffic statistics that are embedded in the form of JavaScript (for example, Google analytics). This measures actual visitors whose browser runs JavaScript, not bots that just send requests.

Theoretically, the attacker could also try to overload the defense. Consider that you would have to automatically create a rule for each URL, or parse a very long log.

The webserver caught it, but the customer’s website started returning 503 errors (exhausted processes) and the pages loaded slowly. He let us know, so we quickly hid it behind WEDOS Global Protection, which is still under development but can already solve these attacks.

All requests to *.php pages of the customer’s website. 5 minute chart.

The problem was over in a moment. My colleagues have really made progress with security. They already have a functional administration, so everything is faster, more convenient and clearer.

The attacker kept trying for about 30 minutes, but when he realized he had hit it, he exploited the potential of his botnet and sent a Layer 4 attack (through the transport layer) in the form of a few hundred thousand SYN packets (SYN flood). It’s already been caught by DDoS protection.

The number of packets that go through 3 routes. (Each has a capacity of 100 Gbps).

This part of the attack was over in about two hours. It was nothing extreme. We get much stronger attacks of this type on a regular basis. In addition, we have extensive experience with them since 2013.

On the other hand, you need to realize who you are actually up against. 500K SYN packets per second is quite a lot for Czech conditions. This is a very insidious attack that you need specific protection against. Not everyone can invest over a million a year in hardware, development and people just to improve protection against DDoS attacks 😉

Case #2 – eshop target, ransom unknown

This attack took place at the beginning of February and surprised us with its power, with the number of blocked accesses exceeding 168,000 per minute.

The target was again the e-shop. The attacker directed all accesses to his main page, which was fortunately very well optimized and cached.

The attack began at 14:00 and gradually increased in intensity. After 14:40 it was so big that the site started to slow down and 503 errors gradually appeared.

On the graph you can see the number of requests for .php pages and how the webserver handled them. 5 minute chart.

A customer wrote to us that he had a problem with the website. The technicians have been monitoring this for some time, but if it doesn’t affect other customers, they don’t interfere. After the agreement, WEDOS Global Protection travelled for our protection.

Of course, the site was immediately relieved. But the striker decided to toughen up. In the end, he pulled up 168,199 hits on the minute chart.

WEDOS Global Protection request handling statistics. Minute chart.

The protection chart also shows how he changed his tactics. He attempted 3 times to break through using multiple approaches at one time.

In total, the attack on the customer lasted approximately 2 hours. From the data on the webserver (before the protection was deployed), we also have data from where the attacks came from.

A table of where the attacks came from in the first 60 minutes or so.

As you can see, a lot of it came from Europe and even the Czech Republic is on 4. Instead. Some geoblocation where you cut off foreign countries would not help in this case.

We then took a close look at the traffic from the Czech Republic.

IP addresses in the Czech Republic from which the attacks were launched for the first 60 minutes.

This attack was specific in that the attacker exploited various anonymous web browsing services (proxy servers, TOR). Basically all 45.153.160.* are TOR exit nodes. The IP address in the first place is on the proxy lists. It comes under attack repeatedly and no useful traffic. She ended up on the permanent blacklist.

We never found out how much the ransom was. Apparently the blackmail email went to spam.


We monitor traffic and improve our protections. We will soon give you a glimpse into the future customer administration of WEDOS Global Protection. We want to make the service as easy to use as possible, but at the same time give you the choice of what to block or allow in addition and how.

By the way, if you would like to participate in the development of protections (L3, L4 or L7), we are recruiting people. WEDOS Global protection will be part of our new global network WEDOS Global. This year we plan to deploy over 1,000 physical servers in 25 locations to help us take our protection to a whole new level. We could use a few more people on the team. We have 8 positions open and are looking for more people to fill some of them. Our growth is currently limited only by the number of people.