HTTP Flood - DDoS - Analyzed

There is one rule that continues to be proved true, if something is connected to the Internet: Someone will try to break it.

It could be your web application, an exposed service (sshd, remote desktop), or pretty much anything that can be accessed remotely. There is always that person trying to exploit it, whether for amusement or financial gain. If it's online, it is going to get hit.

For the bad guys doing it, they may use your resources to spread malware, use it as a way to attack others, or maybe leverage it for some crypto mining - often some action that benefits them - at your expense.

DDoS Attacks

There are also the jerk attacks, where the bad guys don't gain anything from it. That's where denial of service attacks fit in (also known as DoS or DDoS attacks). Bad actors work to disrupt the availability of your service, and your day. But don't gain much (or anything from it). They just want to see you down. Unless they are a competitor or trying to ransom you to stop the attacks. They don't gain much.

One of the sites we service at NOC was attacked this past week with a DDOS attack. Out of curiosity, we did a dive into the logs to see what we can learn about the attack and to show how insightful logs can be to your DevSecOp operations. Let's see what we can learn.

The HTTP-flood attack

First, there are many types of DDoS (Distributed Denial of Service) attacks. The one executed against this site was a HTTP-flood, where the bad guys generated a large amount of HTTP/HTTPS requests to try to take the site down.

The attack didn't last long, probably because how ineffective it was behind our CDN / WAF platform, but it still generated enough logs to better understand what was going on.

  Date Time
Start Time 2022/Jun/27 22:10:27
End Time 2022/Jun/27 22:30:41


The attack lasted 20 minutes and 14 seconds and as quick as it started, it ended. During that time, the attackers generated 2,346,483 HTTPS requests. That's an average of ~1,930 requests per second.

HTTP Flood in the logs

It also spiked to over 20,000 requests per second for a while:

#requests #time
22,606 22:17:39
23,768 22:17:37
23,789 22:17:34
24,012 22:17:33
24,138 22:17:31
25,837 22:12:54
27,215 22:14:55
27,320 22:14:56
27,408 22:12:52
27,918 22:17:36
28,085 22:12:59
28,241 22:12:57
28,748 22:12:56
28,845 22:13:00
29,832 22:17:32
29,931 22:12:55
32,746 22:12:53
33,181 22:12:58


At 22:12:58, we received 33,181 requests. That's a lot of requests and more than most web servers can handle without some DDoS mitigation in place. The busiest minutes were between 22:12 and 22:17, spiking at 23:17, where it averaged 8,544 requests per second (512,680 in 1 minute).



#requests #time
220,540 22:13
273,869 22:14
287,574 22:15
355,521 22:16
428,214 22:12
512,680 22:17

The attacking IP Addresses

The attack leveraged 7,719 different IP addresses (or you could say 7,000 different servers or computing devices), each one generating a few requests at the same time.

That's the difference between a Denial of Service (DoS) and Distributed Denial of Service (DDoS) - the latter uses many computers and different IPs to make the attack more powerful and harder to block.

The TOP IPs generated around 2,000 requests each across the 20 minute period. Very little impact to each one, but a big impact to the victim receiving them.

#requests #ip
2,762 116.253.208.239
2,303 193.203.8.69
2,197 158.101.127.64
2,115 27.189.129.12
2,021 83.142.52.196
1,990 133.242.237.138
1,745 216.37.138.177
1,742 119.5.225.128
1,741 152.26.192.32
1,714 194.104.11.236


The links above use the NOC IP Reputation scanner to check the reputation of an IP. The reputation service is a free NOC service.


As far as network goes, it came from 2,272 different /16 networks and over 1,000 ASNs. Top /16s in terms of requests:

76,014 193.202.0.0/16
53,778 46.161.0.0/16
50,837 185.61.0.0/16
37,508 146.185.0.0/16
33,258 45.148.0.0/16
32,850 178.20.0.0/16
27,556 109.94.0.0/16
25,305 185.68.0.0/16
25,052 83.142.0.0/16
23,475 193.203.0.0/16


And the ASNs where most IPs came from:



1169 (15%) "as_name": "COGENT-174, US",
953 (12%) "as_name": "STARK-INDUSTRIES-SOLUTIONS-AS, MD",
364 (5%) "as_name": "BTTGROUP-AS, GB",
259 (4%) "as_name": "CHINANET-BACKBONE No.31,Jin-rong Street, CN",
247 (3%) "as_name": "SILVERSTAR-AS, GB",
193 (2%) "as_name": "DIGITALOCEAN-ASN, US",
157 (2%) "as_name": "TELKOMNET-AS-AP PT Telekomunikasi Indonesia, ID",
165 (2%) "as_name": "OVH, FR",
156 (2%) "as_name": "HETZNER-AS, DE",

The attacking countries - GeoIP

With such a diverse range of IPs and ASNs, we decided to look at the GeoIP to country mapping to see if any specific location was being misused the most. And the GeoIP was from all over the place as well (mapping to over 100 countries). Top ones were:

951 (12%) "country_code": "RU",
587 (7%) "country_code": "US",
539 (7%) "country_code": "GB",
460 (5%) "country_code": "CN",
448 (5%) "country_code": "BR",
364 (4%) "country_code": "DE",

Very little in common between the IP addresses used in the attacks. Different countries, ASNs and networks.

One thing we found in common is that about 10% of them were running a web server on port 80. Often to a login page of a router or the default Apache/Nginx pages.

The attacking user agents

Users agents are an interesting piece of information on a http-based DDoS as they tend to be static across the attack or with a slight change between them.

In some cases, you can block (NOC Guide to Block User Agents and Referrers on NGINX and Apache Web server) a few USER AGENTS and stop the attack altogether. In this one, they used 1,027 different USER AGENTS - often of old browser versions. The top USER AGENTS were:

&nspb Browser Quantity User Agent
#1 Chrome/96 92,694 "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36"
#2 Firefox/99 83,244 "Mozilla/5.0 (Android 11; Mobile; rv:99.0) Gecko/99.0 Firefox/99.0"
#3 MSIE/10 83,022 "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 10.0; Trident/6.0; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)"
#4 Chrome/100 82,967 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.0.0 Safari/537.36"
#5 Opera Mini/7 82,792 "Opera/9.80 (Android; Opera Mini/7.5.54678/28.2555; U; ru) Presto/2.10.289 Version/12.02"
#6 Firefox/91 82,758 "Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0"
#7 Safari for iPhone 82,726 "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Mobile/15E148 Safari/604.1"
#8 Safari for iPad 82,610 "Mozilla/5.0 (iPad; CPU OS 15_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/99.0.4844.59 Mobile/15E148 Safari/604.1"


The list goes on with a similar frequency across the top 10 user agents. After that, from the top10 to the rest, all other user agents had around 1,000 entries each. It shows that the attackers tried to randomize the user agents pretty equally, likely from a list of popular browsers.

DDOS For Hire

The other aspect that we found interesting is that most of the IP addresses used in the attack were already blacklisted and used in other attacks. They are likely compromised servers being sold and used by DDoS-for-hire type of services (often called "stressers" to sound legitimate).

We can't know for sure, but the fact that around 10% of all the IPs have some type of router login page available, leads us to believe that were hacked through brute force for using bad passwords.

Also, we don't know why they did the attack and why they stopped after 20 minutes, but we thought it would be interesting to share. If you have any questions, let us know! And if your site is under attack and want to share the logs with us, we would love to investigate more and help!





Posted in   http   ddos     by Daniel Cid (dcid)

Simple, affordable, log management and analysis.