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.
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.
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.
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.
It also spiked to over 20,000 requests per second for a while:
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).
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.
As far as network goes, it came from 2,272 different /16 networks and over 1,000 ASNs. Top /16s in terms of requests:
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",
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
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.
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:
|#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/18.104.22.168 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.
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
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!