While this report primarily focuses on 2025 Q1, it also includes late-breaking data from a hyper-volumetric DDoS campaign observed in April 2025, featuring some of the largest attacks ever publicly disclosed. In a historic surge of activity, we blocked the most intense packet rate attack on record, peaking at 4.8 billion packets per second (Bpps), 52% higher than the previous benchmark, and separately defended against a massive 6.5 terabits-per-second (Tbps) flood, matching the highest bandwidth attacks ever reported.

• In the first quarter of 2025, Cloudflare blocked 20.5 million DDoS attacks. That represents a 358% year-over-year (YoY) increase and a 198% quarter-over-quarter (QoQ) increase. 

• Around one third of those, 6.6 million, targeted the Cloudflare network infrastructure directly, as part of an 18-day multi-vector attack campaign.

• Furthermore, in the first quarter of 2025, Cloudflare blocked approximately 700 hyper-volumetric DDoS attacks that exceeded 1 Tbps or 1 Bpps — an average of around 8 attacks per day.

All the attacks were blocked by our autonomous defenses.

To learn more about DDoS attacks and other types of cyber threats, refer to our Learning Center. Visit Cloudflare Radar to view this report in its interactive version where you can drill down further. There's a free API for those interested in investigating Internet trends. You can also learn more about the methodologies used in preparing these reports.

In the first quarter of 2025, we blocked 20.5 million DDoS attacks. For comparison, during the calendar year 2024, we blocked 21.3 million DDoS attacks. In just this past quarter, we blocked 96% of what we blocked in 2024.

The most significant increase was in network-layer DDoS attacks. In 2025 Q1, we blocked 16.8M network-layer DDoS attacks. That’s a 397% QoQ increase and a 509% YoY increase. HTTP DDoS attacks also increased — a 7% QoQ increase and a 118% YoY increase.

We count DDoS attacks based on unique real-time fingerprints generated by our systems. In some instances, a single attack or campaign may generate multiple fingerprints, particularly when different mitigation strategies are applied. While this can occasionally lead to higher counts, the metric offers a strong overall indicator of attack activity during a given period.

Of the 20.5 million DDoS attacks blocked in Q1, 16.8 million were network-layer DDoS attacks, and of those, 6.6M targeted Cloudflare’s network infrastructure directly. Another 6.9 million targeted hosting providers and service providers protected by Cloudflare.

These attacks were part of an 18-day multi-vector DDoS campaign comprising SYN flood attacks, Mirai-generated DDoS attacks, and SSDP amplification attacks to name a few. These attacks, as with all of the 20.5 million, were autonomously detected and blocked by our DDoS defenses.

In the graph below, daily aggregates of attacks against Cloudflare are represented by the blue line, and the other colors represent the various hosting providers and Internet service providers using Cloudflare’s Magic Transit service that were attacked simultaneously.

Hyper-volumetric DDoS attacks are attacks that exceed 1-2 Tbps or 1 Bpps. In 2025 Q1, we blocked over 700 of these attacks. Approximately 4 out of every 100,000 network-layer DDoS attacks were hyper-volumetric. Hyper-volumetric DDoS attacks tend to take place over UDP.

While this report primarily focuses on 2025 Q1, we believe it is important to also highlight the significant hyper-volumetric record-breaking DDoS attacks that continued into Q2. As such, we have included initial insights from that campaign.

In the second half of April 2025, Cloudflare’s systems automatically detected and blocked dozens of hyper-volumetric DDoS attacks as part of an intense campaign. The largest attacks peaked at 4.8 Bpps and 6.5 Tbps, with these massive surges typically lasting between 35 and 45 seconds. At 6.5 Tbps, this attack matches the largest publicly disclosed DDoS attack to date. The 4.8 Bpps attack is the largest ever to be disclosed from the packet intensity perspective, approximately 52% larger than the previous 3.15 Bpps record.

The attacks originated from 147 countries and targeted multiple IP addresses and ports of a hosting provider that is protected by Cloudflare Magic Transit. All the attacks were successfully blocked by Cloudflare’s network.

When surveying Cloudflare customers that were targeted by DDoS attacks, the majority said they didn’t know who attacked them. The ones that did know reported their competitors as the number one threat actor behind the attacks (39%), which is similar to last quarter. This is quite common in the gaming and gambling industry.

Another 17% reported that a state-level or state-sponsored threat actor was behind the attack, and a similar percentage reported that a disgruntled user or customer was behind the attack. 

Another 11% reported that they mistakenly inflicted the DDoS attack on themselves (self-DDoS) and a similar percentage said an extortionist was behind the attacks. 6% reported that the attacks were launched by disgruntled or former employees.

On the network-layer, SYN flood remains the most common Layer 3/4 DDoS attack vector, followed by DNS flood attacks. Mirai-launched DDoS attacks take the third place, replacing UDP flood attacks.

In the HTTP realm, over 60% of the attacks were identified and blocked as known botnets, 21% were attacks with suspicious HTTP attributes, another 10% were launched by botnets impersonating browsers, and the remaining 8% were generic floods, attacks of unusual request patterns, and cache busting attacks.

In 2025 Q1, we saw a 3,488% QoQ increase in CLDAP reflection/amplification attacks. CLDAP (Connectionless Lightweight Directory Access Protocol) is a variant of LDAP (Lightweight Directory Access Protocol), used for querying and modifying directory services running over IP networks. CLDAP is connectionless, using UDP instead of TCP, making it faster but less reliable. Because it uses UDP, there’s no handshake requirement, which allows attackers to spoof the source IP address, thus allowing attackers to exploit it as a reflection vector. In these attacks, small queries are sent with a spoofed source IP address (the victim's IP), causing servers to send large responses to the victim, overwhelming it. Mitigation involves filtering and monitoring unusual CLDAP traffic.

We also saw a 2,301% QoQ increase in ESP reflection/amplification attacks. The ESP (Encapsulating Security Payload) protocol is part of IPsec and provides confidentiality, authentication, and integrity to network communications. However, it can be abused in DDoS attacks if malicious actors exploit misconfigured or vulnerable systems to reflect or amplify traffic towards a target, leading to service disruption. Like with other protocols, securing and properly configuring the systems using ESP is crucial to block the risks of DDoS attacks.

Despite the increase in hyper-volumetric attacks, most DDoS attacks are small. In 2025 Q1, 99% of Layer 3/4 DDoS attacks were under 1 Gbps and 1 Mpps. Similarly, 94% of HTTP DDoS attacks were 1 million requests per second (rps). However, ‘small’ is a relative term and most Internet properties wouldn’t be able to withstand even those small attacks. They can easily saturate unprotected Internet links and crash unprotected servers.

Furthermore, most attacks are very short-lived. 89% of Layer 3/4 DDoS attacks and 75% of HTTP DDoS attacks end within 10 minutes. Even the largest, record-breaking, hyper-volumetric DDoS attacks can be very short, such as the 35-second attack seen in the examples above. 35 seconds, or even 10 minutes, is not a sufficient time for manual mitigation or activating an on-demand solution: by the time a security analyst receives the alert, and analyzes the attack, it’s already over. And while the attacks may be very short, the trickle effect of attack leads to network and applications failures that can take days to recover from — all whilst services are down or degraded. The current threat landscape leaves no time for human intervention. Detection and mitigation should be always-on, in-line and automated — with sufficient capacity and global coverage to handle the attack traffic along with legitimate peak time traffic.

On the other hand, hyper-volumetric HTTP DDoS attacks that exceed 1 Mrps doubled their share. In 2025 Q1, 6 out of every 100 HTTP DDoS attacks exceeded 1 Mrps. On the network-layer, 1 out of every 100,000 attacks exceeded 1 Tbps or 1 Bpps.

One example of such an attack targeted a Cloudflare Magic Transit customer. The customer itself is a US-based hosting provider that offers web servers, Voice over IP (VoIP) servers, and game servers amongst its solutions. This specific attack targeted port 27015. This port is most commonly associated with multiplayer gaming servers, especially Valve's Source engine games, such as Counter-Strike: Global Offensive (CS:GO), Team Fortress 2, Garry's Mod, Left 4 Dead, and Half-Life 2: Deathmatch.

It's used for the game server connection, letting clients connect to the server to play online. In many cases, this port is open for both UDP and TCP, depending on the game and what kind of communication it's doing. This customer was targeted with multiple hyper-volumetric attacks that were autonomously blocked by Cloudflare.

The first quarter of 2025 saw a significant shift in the top 10 most attacked locations globally. Germany made a notable jump, climbing four spots — making it the most attacked country. In second place, Turkey also experienced a surge of 11 spots. In third, China, on the other hand, slipped two spots compared to the previous quarter, while Hong Kong remained unchanged. India rose four spots, and Brazil stayed the same. Taiwan dropped four positions. The Philippines experienced the largest decline, falling 6 spots. South Korea and Indonesia, however, both jumped up by two spots each.

The top 10 most attacked industries in 2025 Q1 saw some notable changes. The Gambling & Casinos industry jumped up four spots as the most attacked industry, while the Telecommunications, Service Providers and Carriers industry slid down one spot. The Information Technology & Services and Internet industries both saw minor fluctuations, moving up one and down two spots, respectively. The Gaming and Banking & Financial Services industries both saw a one-spot increase, while the Cyber Security industry made a massive leap of 37 spots compared to the previous quarter. Retail saw a slight decline of one spot, while the Manufacturing, Machinery, Technology & Engineering industry surged 28 spots. The Airlines, Aviation & Aerospace industry had the biggest jump of all, moving up 40 spots making it the tenth most attacked industry.

The ranking of the top 10 largest sources of DDoS attacks in 2025 Q1 also shifted notably. Hong Kong soared to the number one position, climbing three spots from the previous quarter. Indonesia edged down to second place, while Argentina rose two spots to third. Singapore slipped two spots to fourth, and Ukraine dropped one to fifth. Brazil made a striking leap, climbing seven places to land in sixth place, closely followed by Thailand, which also rose seven spots to seventh. Germany also increased, moving up two positions to eighth. Vietnam made the most dramatic climb, jumping 15 spots to claim ninth place, while Bulgaria rounded out the list, dipping two spots to tenth.

An ASN (Autonomous System Number) is a unique identifier assigned to a network or group of IP networks that operate under a single routing policy on the Internet. It’s used to exchange routing information between systems using protocols like BGP (Border Gateway Protocol).

When looking at where the DDoS attacks originate from, specifically HTTP DDoS attacks, there are a few autonomous systems that stand out. In 2025 Q1, the German-based Hetzner (AS24940) retained its position as the largest source of HTTP DDoS attacks. It was followed by the French-based OVH (AS16276) in second, the US-based DigitalOcean (AS14061) in third, and another German-based provider, Contabo (AS51167), in fourth. 

Other major sources included the China-based ChinaNet Backbone (AS4134) and Tencent (AS132203), the Austrian-based Drei (AS200373), and three US-based providers to wrap up the top 10 — Microsoft (AS8075), Oracle (AS31898), and Google Cloud Platform (AS396982). Most of the networks in this ranking are well-known cloud computing or hosting providers, highlighting how cloud infrastructure is frequently leveraged — either intentionally or through exploitation — for launching DDoS attacks.

To help hosting providers, cloud computing providers and any Internet service providers identify and take down the abusive accounts that launch these attacks, we leverage Cloudflare’s unique vantage point to provide a free DDoS Botnet Threat Feed for Service Providers. Over 600 organizations worldwide have already signed up for this feed. It gives service providers a list of offending IP addresses from within their ASN that we see launching HTTP DDoS attacks. It’s completely free and all it takes is opening a free Cloudflare account, authenticating the ASN via PeeringDB, and then fetching the threat intelligence via API.

At Cloudflare, our mission is to help build a better Internet. A key part of that commitment is offering free protection against DDoS attacks, as well as supporting the broader Internet community by providing free tools to help other networks detect and dismantle botnets operating within their infrastructure.

As the threat landscape continues to evolve, we see that many organizations still adopt DDoS protection only after experiencing an attack or rely on outdated, on-demand solutions. In contrast, our data shows that those with proactive security strategies are far more resilient. That’s why we focus on automation and a comprehensive, always-on, in-line security approach to stay ahead of both existing and emerging threats.

Backed by our global network with 348 Tbps of capacity spanning 335 cities, we remain dedicated to delivering unmetered, unlimited DDoS protection, regardless of the size, duration, or frequency of attacks.

Published quarterly, this report offers a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network. In this edition, we focus on the fourth quarter of 2024 and look back at the year as a whole.

When we published our first report, Cloudflare’s global network capacity was 35 Terabits per second (Tbps). Since then, our network’s capacity has grown by 817% to 321 Tbps. We also significantly expanded our global presence by 65% from 200 cities in the beginning of 2020 to 330 cities by the end of 2024.

Using this massive network, we now serve and protect nearly 20% of all websites and close to 18,000 unique Cloudflare customer IP networks. This extensive infrastructure and customer base uniquely positions us to provide key insights and trends that benefit the wider Internet community.

• In 2024, Cloudflare’s autonomous DDoS defense systems blocked around 21.3 million DDoS attacks, representing a 53% increase compared to 2023. On average, in 2024, Cloudflare blocked 4,870 DDoS attacks every hour.

• In the fourth quarter, over 420 of those attacks were hyper-volumetric, exceeding rates of 1 billion packets per second (pps) and 1 Tbps. Moreover, the amount of attacks exceeding 1 Tbps grew by a staggering 1,885% quarter-over-quarter.

• During the week of Halloween 2024, Cloudflare’s DDoS defense systems successfully and autonomously detected and blocked a 5.6 Terabit per second (Tbps) DDoS attack — the largest attack ever reported.

To learn more about DDoS attacks and other types of cyber threats, visit our Learning Center, access previous DDoS threat reports on the Cloudflare blog, or visit our interactive hub, Cloudflare Radar. There's also a free API for those interested in investigating these and other Internet trends. You can also learn more about the methodologies used in preparing these reports.

In 2024 Q4 alone, Cloudflare mitigated 6.9 million DDoS attacks. This represents a 16% increase quarter-over-quarter (QoQ) and 83% year-over-year (YoY).

Of the 2024 Q4 DDoS attacks, 49% (3.4 million) were Layer 3/Layer 4 DDoS attacks and 51% (3.5 million) were HTTP DDoS attacks.

^{Distribution of 6.9 million DDoS attacks: 2024 Q4}

The majority of the HTTP DDoS attacks (73%) were launched by known botnets. Rapid detection and blocking of these attacks were made possible as a result of operating a massive network and seeing many types of attacks and botnets. In turn, this allows our security engineers and researchers to craft heuristics to increase mitigation efficacy against these attacks.

An additional 11% were HTTP DDoS attacks that were caught pretending to be a legitimate browser. Another 10% were attacks which contained suspicious or unusual HTTP attributes. The remaining 8% “Other” were generic HTTP floods, volumetric cache busting attacks, and volumetric attacks targeting login endpoints.

^{Top HTTP DDoS attack vectors: 2024 Q4}

These attack vectors, or attack groups, are not necessarily exclusive. For example, known botnets also impersonate browsers and have suspicious HTTP attributes, but this breakdown is our attempt to categorize the HTTP DDoS attacks in a meaningful way.

As of this report’s publication, the current stable version of Chrome for Windows, Mac, iOS, and Android is 132, according to Google’s release notes. However, it seems that threat actors are still behind, as thirteen of the top user agents that appeared most frequently in DDoS attacks were Chrome versions ranging from 118 to 129.

The HITV_ST_PLATFORM user agent had the highest share of DDoS requests out of total requests (99.9%), making it the user agent that’s used almost exclusively in DDoS attacks. In other words, if you see traffic coming from the HITV_ST_PLATFORM user agent, there is a 0.1% chance that it is legitimate traffic.

Threat actors often avoid using uncommon user agents, favoring more common ones like Chrome to blend in with regular traffic. The presence of the HITV_ST_PLATFORM user agent, which is associated with smart TVs and set-top boxes, suggests that the devices involved in certain cyberattacks are compromised smart TVs or set-top boxes. This observation highlights the importance of securing all Internet-connected devices, including smart TVs and set-top boxes, to prevent them from being exploited in cyberattacks.

^{Top user agents abused in DDoS attacks: 2024 Q4}

The user agent hackney came in second place, with 93% of requests containing this user agent being part of a DDoS attack. If you encounter traffic coming from the hackney user agent, there is a 7% chance that it is legitimate traffic. Hackney is an HTTP client library for Erlang, used for making HTTP requests and is popular in Erlang/Elixir ecosystems.

Additional user agents that were used in DDoS attacks are uTorrent, which is associated with a popular BitTorrent client for downloading files. Go-http-client and fasthttp were also commonly used in DDoS attacks. The former is the default HTTP client in Go’s standard library and the latter is a high-performance alternative. fasthttp is used to build fast web applications, but is often exploited for DDoS attacks and web scraping too.

HTTP methods (also called HTTP verbs) define the action to be performed on a resource on a server. They are part of the HTTP protocol and allow communication between clients (such as browsers) and servers.

The GET method is most commonly used. Almost 70% of legitimate HTTP requests made use of the GET method. In second place is the POST method with a share of 27%.

With DDoS attacks, we see a different picture. Almost 14% of HTTP requests using the HEAD method were part of a DDoS attack, despite it hardly being present in legitimate HTTP requests (0.75% of all requests). The DELETE method came in second place, with around 7% of its usage being for DDoS purposes.

The disproportion between methods commonly seen in DDoS attacks versus their presence in legitimate traffic definitely stands out. Security administrators can use this information to optimize their security posture based on these headers.

^{Distribution of HTTP methods in DDoS attacks and legitimate traffic: 2024 Q4}

An HTTP path describes a specific server resource. Along with the HTTP method, the server will perform the action on the resource.

For example, GET https://developers.cloudflare.com/ddos-protection/ will instruct the server to retrieve the content for the resource /ddos-protection/.

DDoS attacks often target the root of the website (“/”), but in other cases, they can target specific paths. In 2024 Q4, 98% of HTTP requests towards the /wp-admin/ path were part of DDoS attacks. The /wp-admin/ path is the default administrator dashboard for WordPress websites.

Obviously, many paths are unique to the specific website, but in the graph below, we’ve provided the top generic paths that were attacked the most. Security administrators can use this data to strengthen their protection on these endpoints, as applicable. 

 ^{Top HTTP paths targeted by HTTP DDoS attacks: 2024 Q4}

In Q4, almost 94% of legitimate traffic was HTTPS. Only 6% was plaintext HTTP (not encrypted). Looking at DDoS attack traffic, around 92% of HTTP DDoS attack requests were over HTTPS and almost 8% were over plaintext HTTP.

^{HTTP vs. HTTPS in legitimate traffic and DDoS attacks: 2024 Q4}

The top three most common Layer 3/Layer 4 (network layer) attack vectors were SYN flood (38%), DNS flood attacks (16%), and UDP floods (14%).

^{Top L3/4 DDoS attack vectors: 2024 Q4}

An additional common attack vector, or rather, botnet type, is Mirai. Mirai attacks accounted for 6% of all network layer DDoS attacks — a 131% increase QoQ. In 2024 Q4, a Mirai-variant botnet was responsible for the largest DDoS attack on record, but we’ll discuss that further in the next section.

Before moving on to the next section, it’s worthwhile to discuss the growth in additional attack vectors that were observed this quarter. 

^{Top emerging threats: 2024 Q4}

Memcached DDoS attacks saw the largest growth, with a 314% QoQ increase. Memcached is a database caching system for speeding up websites and networks. Memcached servers that support UDP can be abused to launch amplification or reflection DDoS attacks. In this case, the attacker would request content from the caching system and spoof the victim's IP address as the source IP in the UDP packets. The victim will be flooded with the Memcache responses, which can be up to 51,200x larger than the initial request.

BitTorrent DDoS attacks also surged this quarter by 304%. The BitTorrent protocol is a communication protocol used for peer-to-peer file sharing. To help the BitTorrent clients find and download the files efficiently, BitTorrent clients may utilize BitTorrent Trackers or Distributed Hash Tables (DHT) to identify the peers that are seeding the desired file. This concept can be abused to launch DDoS attacks. A malicious actor can spoof the victim’s IP address as a seeder IP address within Trackers and DHT systems. Then clients would request the files from those IP addresses. Given a sufficient number of clients requesting the file, it can flood the victim with more traffic than it can handle.

On October 29, a 5.6 Tbps UDP DDoS attack launched by a Mirai-variant botnet targeted a Cloudflare Magic Transit customer, an Internet service provider (ISP) from Eastern Asia. The attack lasted only 80 seconds and originated from over 13,000 IoT devices. Detection and mitigation were fully autonomous by Cloudflare’s distributed defense systems. It required no human intervention, didn’t trigger any alerts, and didn’t cause any performance degradation. The systems worked as intended.

^{Cloudflare’s autonomous DDoS defenses mitigate a 5.6 Tbps Mirai DDoS attack without human intervention}

While the total number of unique source IP addresses was around 13,000, the average unique source IP addresses per second was 5,500. We also saw a similar number of unique source ports per second. In the graph below, each line represents one of the 13,000 different source IP addresses, and as portrayed, each contributed less than 8 Gbps per second. The average contribution of each IP address per second was around 1 Gbps (~0.012% of 5.6 Tbps).

^{The 13,000 source IP addresses that launched the 5.6 Tbps DDoS attack}

In 2024 Q3, we started seeing a rise in hyper-volumetric network layer DDoS attacks. In 2024 Q4, the amount of attacks exceeding 1 Tbps increased by 1,885% QoQ and attacks exceeding 100 Million pps (packets per second) increased by 175% QoQ. 16% of the attacks that exceeded 100 Million pps also exceeded 1 Billion pps.

^{Distribution of hyper-volumetric L3/4 DDoS attacks: 2024 Q4}

The majority of HTTP DDoS attacks (63%) did not exceed 50,000 requests per second. On the other side of the spectrum, 3% of HTTP DDoS attacks exceeded 100 million requests per second.

Similarly, the majority of network layer DDoS attacks are also small. 93% did not exceed 500 Mbps and 87% did not exceed 50,000 packets per second. 

^{QoQ change in attack size by packet rate: 2024 Q4}

^{QoQ change in attack size by bit rate: 2024 Q4}

The majority of HTTP DDoS attacks (72%) end in under ten minutes. Approximately 22% of HTTP DDoS attacks last over one hour, and 11% last over 24 hours.

Similarly, 91% of network layer DDoS attacks also end within ten minutes. Only 2% last over an hour.

Overall, there was a significant QoQ decrease in the duration of DDoS attacks. Because the duration of most attacks is so short, it is not feasible, in most cases, for a human to respond to an alert, analyze the traffic, and apply mitigation. The short duration of attacks emphasizes the need for an in-line, always-on, automated DDoS protection service.

^{QoQ change in attack duration: 2024 Q4}

In the last quarter of 2024, Indonesia remained the largest source of DDoS attacks worldwide for the second consecutive quarter. To understand where attacks are coming from, we map the source IP addresses launching HTTP DDoS attacks because they cannot be spoofed, and for Layer 3/Layer 4 DDoS attacks, we use the location of our data centers where the DDoS packets were ingested. This lets us overcome the spoofability that is possible in Layer 3/Layer 4. We’re able to achieve geographical accuracy due to our extensive network spanning over 330 cities around the world.

Hong Kong came in second, having moved up five spots from the previous quarter. Singapore advanced three spots, coming in third place.

^{Top 10 largest sources of DDoS attacks: 2024 Q4}

An autonomous system (AS) is a large network or group of networks that has a unified routing policy. Every computer or device that connects to the Internet is connected to an AS. To find out what your AS is, visit https://radar.cloudflare.com/ip.

When looking at where the DDoS attacks originate from, specifically HTTP DDoS attacks, there are a few autonomous systems that stand out.

The AS that we saw the most HTTP DDoS attack traffic from in 2024 Q4 was German-based Hetzner (AS24940). Almost 5% of all HTTP DDoS requests originated from Hetzer’s network, or in other words, 5 out of every 100 HTTP DDoS requests that Cloudflare blocked originated from Hetzner.

In second place we have the US-based Digital Ocean (AS14061), followed by France-based OVH (AS16276) in third place.

^{Top 10 largest source networks of DDoS attacks: 2024 Q4}

For many network operators such as the ones listed above, it can be hard to identify the malicious actors that abuse their infrastructure for launching attacks. To help network operators and service providers crack down on the abuse, we provide a free DDoS Botnet threat intelligence feed that provides ASN owners a list of their IP addresses that we’ve seen participating in DDoS attacks. 

When surveying Cloudflare customers that were targeted by DDoS attacks, the majority said they didn’t know who attacked them. The ones that did know reported their competitors as the number one threat actor behind the attacks (40%). Another 17% reported that a state-level or state-sponsored threat actor was behind the attack, and a similar percentage reported that a disgruntled user or customer was behind the attack.

Another 14% reported that an extortionist was behind the attacks. 7% claimed it was a self-inflicted DDoS, 2% reported hacktivism as the cause of the attack, and another 2% reported that the attacks were launched by former employees.

^{Top threat actors: 2024 Q4}

In the final quarter of 2024, as anticipated, we observed a surge in Ransom DDoS attacks. This spike was predictable, given that Q4 is a prime time for cybercriminals, with increased online shopping, travel arrangements, and holiday activities. Disrupting these services during peak times can significantly impact organizations' revenues and cause real-world disruptions, such as flight delays and cancellations.

In Q4, 12% of Cloudflare customers that were targeted by DDoS attacks reported being threatened or extorted for a ransom payment. This represents a 78% QoQ increase and 25% YoY growth compared to 2023 Q4.

^{Reported Ransom DDoS attacks by quarter: 2024}

Looking back at the entire year of 2024, Cloudflare received the most reports of Ransom DDoS attacks in May. In Q4, we can see the gradual increase starting from October (10%), November (13%), and December (14%) — a seven-month-high.

^{Reported Ransom DDoS attacks by month: 2024}

In 2024 Q4, China maintained its position as the most attacked country. To understand which countries are subject to more attacks, we group DDoS attacks by our customers’ billing country. 

Philippines makes its first appearance as the second most attacked country in the top 10. Taiwan jumped to third place, up seven spots compared to last quarter.

In the map below, you can see the top 10 most attacked locations and their ranking change compared to the previous quarter.

^{Top 10 most attacked locations by DDoS attacks: 2024 Q4}

In the fourth quarter of 2024, the Telecommunications, Service Providers and Carriers industry jumped from the third place (last quarter) to the first place as the most attacked industry. To understand which industries are subject to more attacks, we group DDoS attacks by our customers’ industry. The Internet industry came in second, followed by Marketing and Advertising in third.

The Banking & Financial Services industry dropped seven places from number one in 2024 Q3 to number eight in Q4.

^{Top 10 most attacked industries by DDoS attacks: 2024 Q4}

The fourth quarter of 2024 saw a surge in hyper-volumetric Layer 3/Layer 4 DDoS attacks, with the largest one breaking our previous record, peaking at 5.6 Tbps. This rise in attack size renders capacity-limited cloud DDoS protection services or on-premise DDoS appliances obsolete.

The growing use of powerful botnets, driven by geopolitical factors, has broadened the range of vulnerable targets. A rise in Ransom DDoS attacks is also a growing concern.

Too many organizations only implement DDoS protection after suffering an attack. Our observations show that organizations with proactive security strategies are more resilient. At Cloudflare, we invest in automated defenses and a comprehensive security portfolio to provide proactive protection against both current and emerging threats.

With our 321 Tbps network spanning 330 cities globally, we remain committed to providing unmetered and unlimited DDoS protection no matter the size, duration and quantity of the attacks.

Welcome to the 17th edition of Cloudflare’s DDoS threat report. This edition covers the DDoS threat landscape along with key findings as observed from the Cloudflare network during the first quarter of 2024.

But first, a quick recap. A DDoS attack, short for Distributed Denial of Service attack, is a type of cyber attack that aims to take down or disrupt Internet services such as websites or mobile apps and make them unavailable for users. DDoS attacks are usually done by flooding the victim's server with more traffic than it can handle.

To learn more about DDoS attacks and other types of attacks, visit our Learning Center.

Quick reminder that you can access previous editions of DDoS threat reports on the Cloudflare blog. They are also available on our interactive hub, Cloudflare Radar. On Radar, you can find global Internet traffic, attacks, and technology trends and insights, with drill-down and filtering capabilities, so you can zoom in on specific countries, industries, and networks. There’s also a free API allowing academics, data sleuths, and other web enthusiasts to investigate Internet trends across the globe.

To learn how we prepare this report, refer to our Methodologies.

Key insights from the first quarter of 2024 include:

• 2024 started with a bang. Cloudflare’s defense systems automatically mitigated 4.5 million DDoS attacks during the first quarter — representing a 50% year-over-year (YoY) increase.

• DNS-based DDoS attacks increased by 80% YoY and remain the most prominent attack vector.

• DDoS attacks on Sweden surged by 466% after its acceptance to the NATO alliance, mirroring the pattern observed during Finland's NATO accession in 2023.

We’ve just wrapped up the first quarter of 2024, and, already, our automated defenses have mitigated 4.5 million DDoS attacks — an amount equivalent to 32% of all the DDoS attacks we mitigated in 2023.

Breaking it down to attack types, HTTP DDoS attacks increased by 93% YoY and 51% quarter-over-quarter (QoQ). Network-layer DDoS attacks, also known as L3/4 DDoS attacks, increased by 28% YoY and 5% QoQ.

2024 Q1: Cloudflare mitigated 4.5 million DDoS attacks

When comparing the combined number of HTTP DDoS attacks and L3/4 DDoS attacks, we can see that, overall, in the first quarter of 2024, the count increased by 50% YoY and 18% QoQ.

DDoS attacks by year and quarter

In total, our systems mitigated 10.5 trillion HTTP DDoS attack requests in Q1. Our systems also mitigated over 59 petabytes of DDoS attack traffic — just on the network-layer.

Among those network-layer DDoS attacks, many of them exceeded the 1 terabit per second rate — almost on a weekly basis. The largest attack that we have mitigated so far in 2024 was launched by a Mirai-variant botnet. This attack reached 2 Tbps and was aimed at an Asian hosting provider protected by Cloudflare Magic Transit. Cloudflare’s systems automatically detected and mitigated the attack.

The Mirai botnet, infamous for its massive DDoS attacks, was primarily composed of infected IoT devices. It notably disrupted Internet access across the US in 2016 by targeting DNS service providers. Almost eight years later, Mirai attacks are still very common. Four out of every 100 HTTP DDoS attacks, and two out of every 100 L3/4 DDoS attacks are launched by a Mirai-variant botnet. The reason we say “variant” is that the Mirai source code was made public, and over the years there have been many permutations of the original.

Mirai botnet targets Asian hosting provider with 2 Tbps DDoS attack

In March 2024, we introduced one of our latest DDoS defense systems, the Advanced DNS Protection system. This system complements our existing systems, and is designed to protect against the most sophisticated DNS-based DDoS attacks.

It is not out of the blue that we decided to invest in this new system. DNS-based DDoS attacks have become the most prominent attack vector and its share among all network-layer attacks continues to grow. In the first quarter of 2024, the share of DNS-based DDoS attacks increased by 80% YoY, growing to approximately 54%.

DNS-based DDoS attacks by year and quarter

Despite the surge in DNS attacks and due to the overall increase in all types of DDoS attacks, the share of each attack type, remarkably, remains the same as seen in our previous report for the final quarter of 2023. HTTP DDoS attacks remain at 37% of all DDoS attacks, DNS DDoS attacks at 33%, and the remaining 30% is left for all other types of L3/4 attacks, such as SYN Flood and UDP Floods.

Attack type distribution

And in fact, SYN Floods were the second most common L3/4 attack. The third was RST Floods, another type of TCP-based DDoS attack. UDP Floods came in fourth with a 6% share.

Top attack vectors

When analyzing the most common attack vectors, we also check for the attack vectors that experienced the largest growth but didn’t necessarily make it into the top ten list. Among the top growing attack vectors (emerging threats), Jenkins Flood experienced the largest growth of over 826% QoQ.

Jenkins Flood is a DDoS attack that exploits vulnerabilities in the Jenkins automation server, specifically through UDP multicast/broadcast and DNS multicast services. Attackers can send small, specially crafted requests to a publicly facing UDP port on Jenkins servers, causing them to respond with disproportionately large amounts of data. This can amplify the traffic volume significantly, overwhelming the target's network and leading to service disruption. Jenkins addressed this vulnerability (CVE-2020-2100) in 2020 by disabling these services by default in later versions. However, as we can see, even 4 years later, this vulnerability is still being abused in the wild to launch DDoS attacks.

Attack vectors that experienced the largest growth QoQ

Another attack vector that’s worth discussing is the HTTP/2 Continuation Flood. This attack vector is made possible by a vulnerability that was discovered and reported publicly by researcher Bartek Nowotarski on April 3, 2024.

The HTTP/2 Continuation Flood vulnerability targets HTTP/2 protocol implementations that improperly handle HEADERS and multiple CONTINUATION frames. The threat actor sends a sequence of CONTINUATION frames without the END_HEADERS flag, leading to potential server issues such as out-of-memory crashes or CPU exhaustion. HTTP/2 Continuation Flood allows even a single machine to disrupt websites and APIs using HTTP/2, with the added challenge of difficult detection due to no visible requests in HTTP access logs.

This vulnerability poses a potentially severe threat more damaging than the previously known HTTP/2 Rapid Reset, which resulted in some of the largest HTTP/2 DDoS attack campaigns in recorded history. During that campaign, thousands of hyper-volumetric DDoS attacks targeted Cloudflare. The attacks were multi-million requests per second strong. The average attack rate in that campaign, recorded by Cloudflare, was 30M rps. Approximately 89 of the attacks peaked above 100M rps and the largest one we saw hit 201M rps. Additional coverage was published in our 2023 Q3 DDoS threat report.

HTTP/2 Rapid Reset campaign of hyper-volumetric DDoS attacks in 2023 Q3

Cloudflare's network, its HTTP/2 implementation, and customers using our WAF/CDN services are not affected by this vulnerability. Furthermore, we are not currently aware of any threat actors exploiting this vulnerability in the wild.

Multiple CVEs have been assigned to the various implementations of HTTP/2 that are impacted by this vulnerability. A CERT alert published by Christopher Cullen at Carnegie Mellon University, which was covered by Bleeping Computer, lists the various CVEs:

When analyzing attack statistics, we use our customer’s industry as it is recorded in our systems to determine the most attacked industries. In the first quarter of 2024, the top attacked industry by HTTP DDoS attacks in North America was Marketing and Advertising. In Africa and Europe, the Information Technology and Internet industry was the most attacked. In the Middle East, the most attacked industry was Computer Software. In Asia, the most attacked industry was Gaming and Gambling. In South America, it was the Banking, Financial Services and Insurance (BFSI) industry. Last but not least, in Oceania, was the Telecommunications industry.

Top attacked industries by HTTP DDoS attacks, by region

Globally, the Gaming and Gambling industry was the number one most targeted by HTTP DDoS attacks. Just over seven of every 100 DDoS requests that Cloudflare mitigated were aimed at the Gaming and Gambling industry. In second place, the Information Technology and Internet industry, and in third, Marketing and Advertising.

Top attacked industries by HTTP DDoS attacks

With a share of 75% of all network-layer DDoS attack bytes, the Information Technology and Internet industry was the most targeted by network-layer DDoS attacks. One possible explanation for this large share is that Information Technology and Internet companies may be “super aggregators” of attacks and receive DDoS attacks that are actually targeting their end customers. The Telecommunications industry, the Banking, Financial Services and Insurance (BFSI) industry, the Gaming and Gambling industry and the Computer Software industry accounted for the next three percent.

Top attacked industries by L3/4 DDoS attacks

When normalizing the data by dividing the attack traffic by the total traffic to a given industry, we get a completely different picture. On the HTTP front, Law Firms and Legal Services was the most attacked industry, as over 40% of their traffic was HTTP DDoS attack traffic. The Biotechnology industry came in second with a 20% share of HTTP DDoS attack traffic. In third place, Nonprofits had an HTTP DDoS attack share of 13%. In fourth, Aviation and Aerospace, followed by Transportation, Wholesale, Government Relations, Motion Pictures and Film, Public Policy, and Adult Entertainment to complete the top ten.

Top attacked industries by HTTP DDoS attacks (normalized)

Back to the network layer, when normalized, Information Technology and Internet remained the number one most targeted industry by L3/4 DDoS attacks, as almost a third of their traffic were attacks. In second, Textiles had a 4% attack share. In third, Civil Engineering, followed by Banking Financial Services and Insurance (BFSI), Military, Construction, Medical Devices, Defense and Space, Gaming and Gambling, and lastly Retail to complete the top ten.

Top attacked industries by L3/4 DDoS attacks (normalized)

When analyzing the sources of HTTP DDoS attacks, we look at the source IP address to determine the origination location of those attacks. A country/region that's a large source of attacks indicates that there is most likely a large presence of botnet nodes behind Virtual Private Network (VPN) or proxy endpoints that attackers may use to obfuscate their origin.

In the first quarter of 2024, the United States was the largest source of HTTP DDoS attack traffic, as a fifth of all DDoS attack requests originated from US IP addresses. China came in second, followed by Germany, Indonesia, Brazil, Russia, Iran, Singapore, India, and Argentina.

The top sources of HTTP DDoS attacks

At the network layer, source IP addresses can be spoofed. So, instead of relying on IP addresses to understand the source, we use the location of our data centers where the attack traffic was ingested. We can gain geographical accuracy due to Cloudflare’s large global coverage in over 310 cities around the world.

Using the location of our data centers, we can see that in the first quarter of 2024, over 40% L3/4 DDoS attack traffic was ingested in our US data centers, making the US the largest source of L3/4 attacks. Far behind, in second, Germany at 6%, followed by Brazil, Singapore, Russia, South Korea, Hong Kong, United Kingdom, Netherlands, and Japan.

The top sources of L3/4 DDoS attacks

When normalizing the data by dividing the attack traffic by the total traffic to a given country or region, we get a totally different lineup. Almost a third of the HTTP traffic originating from Gibraltar was DDoS attack traffic, making it the largest source. In second place, Saint Helena, followed by the British Virgin Islands, Libya, Paraguay, Mayotte, Equatorial Guinea, Argentina, and Angola.

The top sources of HTTP DDoS attacks (normalized)

Back to the network layer, normalized, things look rather different as well. Almost 89% of the traffic we ingested in our Zimbabwe-based data centers were L3/4 DDoS attacks. In Paraguay, it was over 56%, followed by Mongolia reaching nearly a 35% attack share. Additional top locations included Moldova, Democratic Republic of the Congo, Ecuador, Djibouti, Azerbaijan, Haiti, and Dominican Republic.

The top sources of L3/4 DDoS attacks (normalized)

When analyzing DDoS attacks against our customers, we use their billing country to determine the “attacked country (or region)”. In the first quarter of 2024, the US was the most attacked by HTTP DDoS attacks. Approximately one out of every 10 DDoS requests that Cloudflare mitigated targeted the US. In second, China, followed by Canada, Vietnam, Indonesia, Singapore, Hong Kong, Taiwan, Cyprus, and Germany.

Top attacked countries and regions by HTTP DDoS attacks

When normalizing the data by dividing the attack traffic by the total traffic to a given country or region, the list changes drastically. Over 63% of HTTP traffic to Nicaragua was DDoS attack traffic, making it the most attacked location. In second, Albania, followed by Jordan, Guinea, San Marino, Georgia, Indonesia, Cambodia, Bangladesh, and Afghanistan.

Top attacked countries and regions by HTTP DDoS attacks (normalized)

On the network layer, China was the number one most attacked location, as 39% of all DDoS bytes that Cloudflare mitigated during the first quarter of 2024 were aimed at Cloudflare’s Chinese customers. Hong Kong came in second place, followed by Taiwan, the United States, and Brazil.

Top attacked countries and regions by L3/4 DDoS attacks

Back to the network layer, when normalized, Hong Kong takes the lead as the most targeted location. L3/4 DDoS attack traffic accounted for over 78% of all Hong Kong-bound traffic. In second place, China with a DDoS share of 75%, followed by Kazakhstan, Thailand, Saint Vincent and the Grenadines, Norway, Taiwan, Turkey, Singapore, and Brazil.

Top attacked countries and regions by L3/4 DDoS attacks (normalized)

Cloudflare's mission is to help build a better Internet, a vision where it remains secure, performant, and accessible to everyone. With four out of every 10 HTTP DDoS attacks lasting over 10 minutes and approximately three out of 10 extending beyond an hour, the challenge is substantial. Yet, whether an attack involves over 100,000 requests per second, as is the case in one out of every 10 attacks, or even exceeds a million requests per second — a rarity seen in only four out of every 1,000 attacks — Cloudflare’s defenses remain impenetrable.

Since pioneering unmetered DDoS Protection in 2017, Cloudflare has steadfastly honored its promise to provide enterprise-grade DDoS protection at no cost to all organizations, ensuring that our advanced technology and robust network architecture do not just fend off attacks but also preserve performance without compromise.

Earlier this week, Cloudflare automatically detected and mitigated a DDoS attack that peaked just below 2 Tbps — the largest we’ve seen to date. This was a multi-vector attack combining DNS amplification attacks and UDP floods. The entire attack lasted just one minute. The attack was launched from approximately 15,000 bots running a variant of the original Mirai code on IoT devices and unpatched GitLab instances.

DDoS attack peaking just below 2 Tbps‌‌

Last quarter, we saw multiple terabit-strong DDoS attacks and this attack continues this trend of increased attack intensity. Another key finding from our Q3 DDoS Trends report was that network-layer DDoS attacks actually increased by 44% quarter-over-quarter. While the fourth quarter is not over yet, we have, again, seen multiple terabit-strong attacks that targeted Cloudflare customers.

DDoS attacks peaking at 1-1.4 Tbps

To begin with, our systems constantly analyze traffic samples “out-of-path” which allows us to asynchronously detect DDoS attacks without causing latency or impacting performance. Once the attack traffic was detected (within sub-seconds), our systems generated a real-time signature that surgically matched against the attack patterns to mitigate the attack without impacting legitimate traffic.

Once generated, the fingerprint is propagated as an ephemeral mitigation rule to the most optimal location in the Cloudflare edge for cost-efficient mitigation. In this specific case, as with most L3/4 DDoS attacks, the rule was pushed in-line into the Linux kernel eXpress Data Path (XDP) to drop the attack packet at wirespeed.

A conceptual diagram of Cloudflare’s DDoS protection systems

Read more about Cloudflare’s DDoS Protection systems.

Cloudflare’s mission is to help build a better Internet — one that is secure, faster, and more reliable for everyone. The DDoS team’s vision is derived from this mission: our goal is to make the impact of DDoS attacks a thing of the past. Whether it's the Meris botnet that launched some of the largest HTTP DDoS attacks on record, the recent attacks on VoIP providers or this Mirai-variant that’s DDoSing Internet properties, Cloudflare’s network automatically detects and mitigates DDoS attacks. Cloudflare provides a secure, reliable, performant, and customizable platform for Internet properties of all types.

For more information about Cloudflare’s DDoS protection, reach out to us or have a go with a hands-on evaluation of Cloudflare’s Free plan.

Meris first got our attention due to an exceptionally large 17.2 million requests per second (rps) DDoS attack that it launched against one of our customers. This attack, along with subsequent attacks originated by the Meris botnet, was automatically detected and mitigated by our DDoS protection systems. Cloudflare customers, even ones on the free plan, are protected against Meris attacks.

Over the past months, we’ve been tracking and analyzing the activity of the Meris botnet. Some main highlights include:

• Meris targets approximately 50 different websites every single day with a daily average of 104 unique DDoS attacks.

• More than 33% of all Meris DDoS attack traffic targeted China-based websites.

• More than 12% of all websites that were attacked by Meris are operated by US-based companies.

View more Meris attack insights and trends in the interactive Radar dashboard.

Meris (Latvian for plague) is the name of an active botnet behind a series of recent DDoS attacks that have targeted thousands of websites around the world. It was originally detected in late June 2021 by QRator in joint research they conducted with Yandex. Their initial research identified 30,000 to 56,000 bots, but they estimated that the numbers are actually much higher, in the ballpark of 250,000 bots.

The Meris botnet is formed of infected routers and networking hardware manufactured by the Latvian company MikroTik. According to MikroTik’s blog, the attackers exploited a vulnerability in the router’s operating system (RouterOS) which enabled attackers to gain unauthenticated remote access to read and write arbitrary files (CVE-2018-14847).

RouterOS is the router operating system that’s used by MikroTik’s routers and the RouterBOARD hardware product family, which can also be used to turn any PC into a router. Administration of RouterOS can be done either via direct SSH connection or by using a configuration utility called WinBox. The vulnerability itself was possible due to a directory traversal vulnerability in the WinBox interface with RouterOS.

Directory traversal is a type of exploit that allows attackers to travel to the parent directories to gain access to the operating system’s file system, a method and structure of how data is stored and retrieved in the operating system. Once they gain access to the file system, attackers can then read the existing files that administer the router and write files directly into the file system to administer the routers to their botnet needs.

While the vulnerability was patched after its detection back in 2018, it’s still being exploited in compromised devices that do not use the patched RouterOS versions, or that use the default usernames and passwords. MicroTik has advised its customers to upgrade their devices’ OS version, to only allow access to the devices via secure IPsec, and to inspect for any abnormalities such as unknown SOCKS proxy settings and scripts.

To launch volumetric attacks, the botnet uses HTTP pipelining which allows it to send multiple requests over a single connection, thus increasing its total attack throughput. Furthermore, in an attempt to obfuscate the attack source, the botnet uses open SOCKS proxies to proxy their attack traffic to the target.

Cloudflare’s DDoS protection systems automatically detect and mitigate Meris attacks. One of the mitigation actions that the system can choose to use is the ‘Connection Close’ action which eliminates the risk of HTTP pipelining and helps slow down attackers. Additionally, as part of Cloudflare’s threat intelligence suite, we provide a Managed IP List of Open SOCKS Proxies that customers can use as part of their firewall rules — to block, challenge or rate-limit traffic that arrives via SOCKS proxies.

About five years ago, Mirai (Japanese for future) — the infamous botnet that infected hundreds of thousands of IoT devices —  launched record-breaking DDoS attacks against websites.

There have been many variants of the Mirai botnet since its source code was leaked. One version of Mirai, called Moobot, was detected last year when it attacked a Cloudflare customer with a 654 Gbps DDoS attack. Another variant recently made a resurgence when it targeted Cloudflare customers with over a dozen UDP and TCP based DDoS attacks that peaked multiple times above 1 Tbps, with a max peak of approximately 1.2 Tbps.

While Mirai infected IoT devices with low computational power, Meris is a swarm of routers that have significantly higher processing power and data transfer capabilities than IoT devices, making them much more potent in causing harm at a larger scale to web properties that are not protected by sophisticated cloud-based DDoS mitigation.

Since the appearance of Meris, Cloudflare’s systems automatically detected and mitigated Meris attacks using the existing mitigation rules. During our analysis of the Meris botnet attacks, our security experts noticed the attack vectors adapt to try and bypass Cloudflare’s defenses. Needless to say, they were not successful. But we wanted to stay many steps ahead of attackers — and so our engineers deployed additional rules that mitigate Meris attacks even more comprehensively. A side effect of these mitigation rules is that it also provides us with more granular threat intelligence on the Meris attacks.

Since we deployed the new rules in early August, we’ve seen Meris launch an average of 104 DDoS attacks on Cloudflare customers every day. The highest figure we’ve seen was on September 6, when Meris was used to launch 261 unique attacks against Cloudflare customers.

View the interactive graph on Cloudflare Radar.

During that same day, on September 6, attacks from Meris accounted for a record-breaking 17.5% of all L7 DDoS attacks that Cloudflare observed.

View the interactive graph on Cloudflare Radar.

Overall, Meris targets about 50 different websites and applications every single day. Although the average attack peaked at 106K rps, the median attack size was actually smaller at 17.6K rps. The largest attack we’ve seen was 17.2M rps and that occurred in July. In the graph below, you can see the daily highest requests per second rate after we deployed the new rules. Since then, the largest attack we’ve seen was 16.7M rps, which took place on August 19.

Over the past few months, the industry that received the most attack traffic from the Meris botnet was the Banking, Financial Services, and Insurance (BFSI) industry

View the interactive graph on Cloudflare Radar.

Following the BFSI industry, the most attacked industries were the Publishing, Gaming/Gambling, and IT Services industries. And while BFSI was the number one most attacked industry when considering the Meris DDoS activity rate, it only came in fourth place when considering the percentage of targeted websites.

In terms of the percentage of targeted websites, the Computer Software industry came in first place. Almost 4% of all impacted websites were of Computer Software companies protected by Cloudflare, followed by Gaming/Gambling and IT Services with 3% and 2%, respectively.

View the interactive graph on Cloudflare Radar.

Besides the total breakdowns shown above, we can also view the top industries the botnet attacked over time to understand the changing trends. These trends may be tied to political events, new video game releases, sporting events, or any other global or local public interest events.

Off the top, we can already see the two largest peaks on August 9 and August 29 — mainly on the Computer Software, Gaming/Gambling, and IT industries. Another interesting peak occurred on August 14 against Cryptocurrency providers.

In late August, the botnet was pointed against gambling and casino websites, generating attacks at rates of hundreds of thousands to millions of requests per second. A second significant wave against the same industry was launched in early September.

View the interactive graph on Cloudflare Radar.

Similarly to the analysis of the top industries, we can calculate the Meris DDoS activity rate per target country to identify which countries came under the most attacks. In total, China-based companies saw the largest amount of DDoS attacks. More than 33% of all requests generated by Meris were destined for China-based companies that are protected by Cloudflare. Australia came in second place, and the US in third.

View the interactive graph on Cloudflare Radar.

On the other hand, when we look at the number of websites that were targeted by Meris, the US came in first place. More than 12% of all websites that were targeted by Meris are operated by US-based companies. China came in second place with 5.6% and Russia in third with 4.4%.

View the interactive graph on Cloudflare Radar.

Over time, we can see how the attacks on the top countries change. Similarly to the per-industry breakdown, we can also see two large peaks. The first one occurred on the same spike as the per-industry breakdown on August 9. However, the second one here occurred on September 1.

View the interactive graph on Cloudflare Radar.

Although only tens of thousands of bots have been detected per attack, it is estimated that there are roughly 250,000 bots worldwide. As indicated above, the botnet is formed of MikroTik routers. Using the source IP address of the routers, we’re able to identify the origin country of the bots to paint a geographical representation of the bots' presence and growth over time.

The change in the location of the bots doesn’t necessarily indicate that the botnet is growing or shrinking. It could also be that different bot groups are activated from time to time to spread the load of the attacks while attempting not to get caught.

At the beginning of August, the majority of the bots were located in Brazil. But by the end of August, that number plummeted to a single digit percentage close to zero. Meanwhile, the number of infected devices grew in the United States. From the beginning of September, the number of bots was significantly higher in the US, Russia, India, Indonesia, and China.

View the interactive graph on Cloudflare Radar.

Cloudflare operates autonomous DDoS protection systems that automatically detect and mitigate DDoS attacks of all types, including attacks launched by Meris and Mirai. These systems are also customizable, and Cloudflare customers can tweak and tune their DDoS protection settings as needed with the HTTP DDoS Managed Ruleset and the L3/4 DDoS Managed Ruleset.

Earlier this summer, Cloudflare’s autonomous edge DDoS protection systems automatically detected and mitigated a 17.2 million request-per-second (rps) DDoS attack, an attack almost three times larger than any previous one that we're aware of. For perspective on how large this attack was: Cloudflare serves over 25 million HTTP requests per second on average. This refers to the average rate of legitimate traffic in 2021 Q2. So peaking at 17.2 million rps, this attack reached 68% of our Q2 average rps rate of legitimate HTTP traffic.

Comparison graph of Cloudflare’s average request per second rate versus the DDoS attack

This attack, along with the additional attacks provided in the next sections, were automatically detected and mitigated by our autonomous edge DDoS protection systems. The system is powered by our very own denial of service daemon (dosd). Dosd is a home-grown software-defined daemon. A unique dosd instance runs in every server in each one of our data centers around the world. Each dosd instance independently analyzes traffic samples out-of-path. Analyzing traffic out-of-path allows us to scan asynchronously for DDoS attacks without causing latency and impacting performance. DDoS findings are also shared between the various dosd instances within a data center, as a form of proactive threat intelligence sharing.

Once an attack is detected, our systems generate a mitigation rule with a real-time signature that matches the attack patterns. The rule is propagated to the most optimal location in the tech stack. As an example, a volumetric HTTP DDoS attack may be blocked at L4 inside the Linux iptables firewall instead of at L7 inside the L7 reverse proxy which runs in the user space. Mitigating lower in the stack, e.g. dropping the packets at L4 instead of responding with a 403 error page in L7, is more cost-efficient. It reduces our edge CPU consumption and intra-data center bandwidth utilization — thus helping us mitigate large attacks at scale without impacting performance.

This autonomous approach, along with our network’s global scale and reliability, allow us to mitigate attacks that reach 68% of our average per-second-rate, and higher, without requiring any manual mitigation by Cloudflare personnel, nor causing any performance degradation.

This attack was launched by a powerful botnet, targeting a Cloudflare customer in the financial industry. Within seconds, the botnet bombarded the Cloudflare edge with over 330 million attack requests.

Graph of 17.2M rps attack

The attack traffic originated from more than 20,000 bots in 125 countries around the world. Based on the bots’ source IP addresses, almost 15% of the attack originated from Indonesia and another 17% from India and Brazil combined. Indicating that there may be many malware infected devices in those countries.

Distribution of the attack sources by top countries

This 17.2 million rps attack is the largest HTTP DDoS attack that Cloudflare has ever seen to date and almost three times the size of any other reported HTTP DDoS attack. This specific botnet, however, has been seen at least twice over the past few weeks. Just last week it also targeted a different Cloudflare customer, a hosting provider, with an HTTP DDoS attack that peaked just below 8 million rps.

Graph of 8M rps attack

Two weeks before, a Mirai-variant botnet launched over a dozen UDP and TCP based DDoS attacks that peaked multiple times above 1 Tbps, with a max peak of approximately 1.2 Tbps. And while the first HTTP attacks targeted Cloudflare customers on the WAF/CDN service, the 1+ Tbps network-layer attacks targeted Cloudflare customers on the Magic Transit and Spectrum services. One of these targets was a major APAC-based Internet services, telecommunications and hosting provider. The other was a gaming company. In all cases, the attacks were automatically detected and mitigated without human intervention.

Graph of Mirai botnet attack peaking at 1.2 Tbps

The Mirai botnet started with roughly 30K bots and slowly shrinked to approximately 28K. However, despite losing bots from its fleet, the botnet was still able to generate impressive volumes of attack traffic for short periods. In some cases, each burst lasted only a few seconds.

These attacks join the increase in Mirai-based DDoS attacks that we’ve observed on our network over the past weeks. In July alone, L3/4 Mirai attacks increased by 88% and L7 attacks by 9%. Additionally, based on the current August per-day average of the Mirai attacks, we can expect L7 Mirai DDoS attacks and other similar botnet attacks to increase by 185% and L3/4 attacks by 71% by the end of the month.

Graph of change in Mirai based DDoS attacks by month

Mirai, which means ‘future’ in Japanese, is a codename for malware that was first discovered in 2016 by MalwareMustDie, a non-profit security research workgroup. The malware spreads by infecting Linux-operated devices such as security cameras and routers. It then self-propagates by searching for open Telnet ports 23 and 2323. Once found, it then attempts to gain access to vulnerable devices by brute forcing known credentials such as factory default usernames and passwords. Later variants of Mirai also took advantage of zero-day exploits in routers and other devices. Once infected, the devices will monitor a Command & Control (C2) server for instructions on which target to attack.

Diagram of Botnet operator controlling the botnet to attack websites

While the majority of attacks are small and short, we continue to see these types of volumetric attacks emerging more often. It’s important to note that these volumetric short burst attacks can be especially dangerous for legacy DDoS protection systems or organizations without active, always-on cloud-based protection.

Furthermore, while the short duration may say something about the botnet’s capability to deliver sustained levels of traffic over time, it can be challenging or impossible for humans to react to it in time. In such cases, the attack is over before a security engineer even has time to analyze the traffic or activate their stand-by DDoS protection system. These types of attacks highlight the need for automated, always-on protection.

1. Onboard to Cloudflare to protect your Internet properties.

2. DDoS is enabled out of the box, and you can also customize the protection settings.

3. Follow our preventive best practices, to ensure that both your Cloudflare settings and your origin server settings are optimized. As an example, make sure that you allow only traffic from Cloudflare’s IP range. Ideally, ask your upstream Internet Service Provider (ISP) to apply an access control list (ACL), otherwise, attackers may target your servers’ IP addresses directly and bypass your protection.

1. Change the default username and password of any device that is connected to the Internet such as smart cameras and routers. This will reduce the risk that malware such as Mirai can gain access to your router and IoT devices.

2. Protect your home against malware with Cloudflare for Families. Cloudflare for Families is a free service that automatically blocks traffic from your home to malicious websites and malware communication.

Moobot Targets 654 Gbps towards a Magic Transit Customer

Over those ten days, our systems automatically detected and mitigated over 5,000 DDoS attacks against this one customer, mainly UDP floods, SYN floods, ACK floods, and GRE floods. The largest DDoS attack was a UDP flood and lasted a mere 2 minutes. This attack targeted only one IP address but hit multiple ports. The attack originated from 18,705 unique IP addresses, each believed to be a Moobot-infected IoT device.

Attack Distribution by Country - From 100 countries

The attack was observed in Cloudflare’s data centers in 100 countries around the world. Approximately 89% of the attack traffic originated from just 10 countries with the US leading at 41%, followed by South Korea and Japan in second place (12% each), and India in third (10%). What this likely means is that the malware has infected at least 18,705 devices in 100 countries around the world.

Attack Distribution by Country - Top 10

‘Moobot’ sounds like a cute name, but there’s nothing cute about it. According to Netlab 360, Moobot is the codename of a self-propagating Mirai-based malware first discovered in 2019. It infects IoT (Internet of Things) devices using remotely exploitable vulnerabilities or weak default passwords. IoT is a term used to describe smart devices such as security hubs and cameras, smart TVs, smart speakers, smart lights, sensors, and even refrigerators that are connected to the Internet.

Once a device is infected by Moobot, control of the device is transferred to the operator of the command and control (C2) server, who can issue commands remotely such as attacking a target and locating additional vulnerable IoT devices to infect (self-propagation).

Moobot is a Mirai-based botnet, and has similar capabilities (modules) as Mirai:

1. Self-propagation - The self-propagation module is in charge of the botnet’s growth. After an IoT device is infected, it randomly scans the Internet for open telnet ports and reports back to the C2 server. Once the C2 server gains knowledge of open telnet ports around the world, it tries to leverage known vulnerabilities or brute force its way into the IoT devices with common or default credentials.

Self-propagation

2. Synchronized attacks - The C2 server orchestrates a coordinated flood of packets or HTTP requests with the goal of creating a denial of service event for the target's website or service.

Synchronized attacks

The botnet operator may use multiple C2 servers in various locations around the world in order to reduce the risk of exposure. Infected devices may be assigned to different C2 servers varying by region and module; one server for self-propagation and another for launching attacks. Thus if a C2 server is compromised and taken down by law enforcement authorities, only parts of the botnet are deactivated.

This is the second large scale attack in the past few months that we observed on Cloudflare's network. The previous one peaked at 754M packets per second and attempted to take down our routers with a high packet rate. Despite the high packet rate, the 754Mpps attack peaked at a mere 253 Gbps.

As opposed to the high packet rate attack, this attack was a high bit rate attack, peaking at 654 Gbps. Due to the high bit rates of this attack, it seems as though the attacker tried (and failed) to cause a denial of service event by saturating our Internet link capacity. So let’s explore why this attack was not successful.

Cloudflare’s global network capacity is over 42 Tbps and growing. Our network spans more than 200 cities in over 100 countries, including 17 cities in mainland China. It interconnects with over 8,800 networks globally, including major ISPs, cloud services, and enterprises. This level of interconnectivity along with the use of Anycast ensures that our network can easily absorb even the largest attacks.

The Cloudflare Network

After traffic arrives at an edge data center, it is then load-balanced efficiently using our own Layer 4 load-balancer that we built, Unimog, which uses our appliances' health and other metrics to load-balance traffic intelligently within a data center to avoid overwhelming any single server.

Besides the use of Anycast for inter-data center load balancing and Unimog for intra-data center load balancing, we also utilize various forms of traffic engineering in order to deal with sudden changes in traffic loads across our network. We utilize both automatic and manual traffic engineering methods that can be employed by our 24/7/365 Site Reliability Engineering (SRE) team.

These combined factors significantly reduce the likelihood of a denial of service event due to link saturation or appliances being overwhelmed -- and as seen in this attack, no link saturation occurred.

Detecting & Mitigating DDoS attacks

Once traffic arrives at our edge, it encounters our three software-defined DDoS protection systems:

1. Gatebot - Cloudflare’s centralized DDoS protection systems for detecting and mitigating globally distributed volumetric DDoS attacks. Gatebot runs in our network’s core data center. It receives samples from every one of our edge data centers, analyzes them, and automatically sends mitigation instructions when attacks are detected. Gatebot is also synchronized to each of our customers’ web servers to identify its health and triggers mitigation accordingly.

2. dosd (denial of service daemon) - Cloudflare’s decentralized DDoS protection systems. dosd runs autonomously in each server in every Cloudflare data center around the world, analyzing traffic and applying local mitigation rules when needed. Besides being able to detect and mitigate attacks at super-fast speeds, dosd significantly improves our network resilience by delegating the detection and mitigation capabilities to the edge.

3. flowtrackd (flow tracking daemon) - Cloudflare’s TCP state tracking machine for detecting and mitigating the most randomized and sophisticated TCP-based DDoS attacks in unidirectional routing topologies (such as the case for Magic Transit). flowtrackd is able to identify the state of a TCP connection and then drops, challenges, or rate-limits packets that don’t belong to a legitimate connection.

Cloudflare DDoS Protection Lifecycle

The three DDoS protection systems collect traffic samples in order to detect DDoS attacks. The types of traffic data that they sample include:

1. Packet fields such as the source IP, source port, destination IP, destination port, protocol, TCP flags, sequence number, options, and packet rate.

2. HTTP request metadata such as HTTP headers, user agent, query-string, path, host, HTTP method, HTTP version, TLS cipher version, and request rate.

3. HTTP response metrics such as error codes returned by customers’ origin servers and their rates.

Our systems then crunch these sample data points together to form a real-time view of our network’s security posture and our customer’s origin server health. They look for attack patterns and traffic anomalies. When found, a mitigation rule with a dynamically crafted attack signature is generated in real-time. Rules are propagated to the most optimal place for cost-effective mitigation. For example, an L7 HTTP flood might be dropped at L4 to reduce the CPU consumption.

Rules that are generated by dosd and flowtrackd are propagated within a single data center for rapid mitigation. Gatebot’s rules are propagated to all of the edge data centers which then take priority over dosd’s rules for an even and optimal mitigation. Even if the attack is detected in a subset of edge data centers, Gatebot propagates the mitigation instructions to all of Cloudflare’s edge data centers -- effectively sharing the threat intelligence across our network as a form of proactive protection.

In the case of this attack, in each edge data center, dosd generated rules to mitigate the attack promptly. Then as Gatebot received and analyzed samples from the edge, it determined that this was a globally distributed attack. Gatebot propagated unified mitigation instructions to the edge, which prepared each and every one of our 200+ data centers to tackle the attack as the attack traffic may shift to a different data center due to Anycast or traffic engineering.

DDoS attacks obviously pose the risk of an outage and service disruption. But there is another risk to consider -- the cost of mitigation. During these ten days, more than 65 Terabytes of attack traffic were generated by the botnet. However, as part of Cloudflare’s unmetered DDoS protection guarantee, Cloudflare mitigated and absorbed the attack traffic without billing the customer. The customer doesn't need to submit a retroactive credit request. Attack traffic is automatically excluded from our billing system. We eliminated the financial risk.

This is a guest post by Elie Bursztein who writes about security and anti-abuse research. It was first published on his blog and has been lightly edited.

This post provides a retrospective analysis of Mirai — the infamous Internet-of-Things botnet that took down major websites via massive distributed denial-of-service using hundreds of thousands of compromised Internet-Of-Things devices. This research was conducted by a team of researchers from Cloudflare (Jaime Cochran, Nick Sullivan), Georgia Tech, Google, Akamai, the University of Illinois, the University of Michigan, and Merit Network and resulted in a paper published at USENIX Security 2017.

At its peak in September 2016, Mirai temporarily crippled several high-profile services such as OVH, Dyn, and Krebs on Security via massive distributed Denial of service attacks (DDoS). OVH reported that these attacks exceeded 1 Tbps—the largest on public record.

What’s remarkable about these record-breaking attacks is they were carried out via small, innocuous Internet-of-Things (IoT) devices like home routers, air-quality monitors, and personal surveillance cameras. At its peak, Mirai infected over 600,000 vulnerable IoT devices, according to our measurements.

• Mirai Genesis: Discusses Mirai’s early days and provides a brief technical overview of how Mirai works and propagates.

• Krebs on Security attack: Recounts how Mirai briefly silenced Brian Krebs website.

• OVH DDoS attack: Examines the Mirai author’s attempt to take down one of the world’s largest hosting providers.

• The rise of copycats: Covers the Mirai code release and how multiple hacking groups end-up reusing the code. This section also describes the techniques we used to track down the many variants of Mirai that arose after the release. Finally, this section discusses the targets and the motive behind each major variants.

• Mirai's takedown of the Internet: Tells the insider story behind Dyn attacks including the fact that the major sites (e.g., Amazon) taken down were just massive collateral damage.

• Mirai’s attempted takedown of an entire country: Looks at the multiple attacks carried out against Lonestar, Liberia’s largest operator.

• Deutsche Telekom goes dark: Discusses how the addition of a router exploit to one of the Mirai variant brought a major German Internet provider to its knees.

• Mirai original author outed?: Details Brian Krebs’ in-depth investigation into uncovering Mirai’s author.

• Deutsche Telekom attacker arrested: Recounts the arrest of the hacker who took down Deutsche Telekom and what we learned from his trial.

The first public report of Mirai late August 2016 generated little notice, and Mirai mostly remained in the shadows until mid-September. At that time, It was propelled in the spotlight when it was used to carry massive DDoS attacks against Krebs on Security the blog of a famous security journalist and OVH, one of the largest web hosting provider in the world.

While the world did not learn about Mirai until at the end of August, our telemetry reveals that it became active August 1st when the infection started out from a single bulletproof hosting IP. From thereon, Mirai spread quickly, doubling its size every 76 minutes in those early hours.

By the end of its first day, Mirai had infected over 65,000 IoT devices. By its second day, Mirai already accounted for half of all Internet telnet scans observed by our collective set of honeypots, as shown in the figure above. At its peak in November 2016 Mirai had infected over 600,000 IoT devices.

Retroactively looking at the infected device services banners using Censys' Internet-wide scanning reveals that most of the devices appear to be routers and cameras as reported in the chart above. Each type of banner is represented separately as the identification process was different for each, so it might be that a device is counted multiple times. Mirai was actively removing any banner identification which partially explains why we were unable to identify most of the devices.

Before delving further into Mirai’s story, let’s briefly look at how Mirai works, specifically how it propagates and its offensive capabilities.

At its core, Mirai is a self-propagating worm, that is, it’s a malicious program that replicates itself by finding, attacking and infecting vulnerable IoT devices. It is also considered a botnet because the infected devices are controlled via a central set of command and control (C&C) servers. These servers tell the infected devices which sites to attack next. Overall, Mirai is made of two key components: a replication module and an attack module.

The replication module is responsible for growing the botnet size by enslaving as many vulnerable IoT devices as possible. It accomplishes this by (randomly) scanning the entire Internet for viable targets and attacking. Once it compromises a vulnerable device, the module reports it to the C&C servers, so it can be infected with the latest Mirai payload, as the diagram above illustrates.

To compromise devices, the initial version of Mirai relied exclusively on a fixed set of 64 well-known default login/password combinations commonly used by IoT devices. While this attack was very low tech, it proved extremely effective and led to the compromise of over 600,000 devices. For more information about DDoS techniques, read this Cloudflare primer.

The attack module is responsible for carrying out DDoS attacks against the targets specified by the C&C servers. This module implements most of the code DDoS techniques such as HTTP flooding, UDP flooding, and all TCP flooding options. This wide range of methods allowed Mirai to perform volumetric attacks, application-layer attacks, and TCP state-exhaustion attacks.

Krebs on Security is Brian Krebs’ blog. Krebs is a widely known independent journalist who specializes in cyber-crime. Given Brian’s line of work, his blog has been targeted, unsurprisingly, by many DDoS attacks launched by the cyber-criminals he exposes. According to his telemetry (thanks for sharing, Brian!), his blog suffered 269 DDoS attacks between July 2012 and September 2016. As seen in the chart above, the Mirai assault was by far the largest, topping out at 623 Gbps.

Looking at the geolocation of the IPs that targeted Brian’s site reveals that a disproportionate number of the devices involved in the attack are coming from South American and South-east Asia. As reported in the chart above Brazil, Vietnam and Columbia appear to be the main sources of compromised devices.

One dire consequence of this massive attack against Krebs was that Akamai, the CDN service that provided Brian’s DDoS protection, had to withdraw its support. This forced Brian to move his site to Project Shield. As he discussed in depth in a blog post, this incident highlights how DDoS attacks have become a common and cheap way to censor people.

Brian was not Mirai’s first high-profile victim. A few days before he was struck, Mirai attacked OVH, one of the largest European hosting providers. According to their official numbers, OVH hosts roughly 18 million applications for over one million clients, Wikileaks being one of their most famous and controversial.

We know little about that attack as OVH did not participate in our joint study. As a result, the best information about it comes from a blog post OVH released after the event. From this post, it seems that the attack lasted about a week and involved large, intermittent bursts of DDoS traffic that targeted one undisclosed OVH customer.

Octave Klaba, OVH’s founder, reported on Twitter that the attacks were targeting Minecraft servers. As we will see through this post, Mirai has been extensively used in gamer wars and is likely the reason why it was created in the first place.

According to OVH telemetry, the attack peaked at 1TBs and was carried out using 145,000 IoT devices. While the number of IoT devices is consistent with what we observed, the volume of the attack reported is significantly higher than what we observed with other attacks. For example, as mentioned earlier, Brian’s one topped out at 623 Gbps.

Regardless of the exact size, the Mirai attacks are clearly the largest ever recorded. They dwarf the previous public record holder, an attack against Cloudflare that topped out at ~400Gpbs.

In an unexpected development, on September 30, 2017, Anna-senpai, Mirai’s alleged author, released the Mirai source code via an infamous hacking forum. He also wrote a forum post, shown in the screenshot above, announcing his retirement.

This code release sparked a proliferation of copycat hackers who started to run their own Mirai botnets. From that point forward, the Mirai attacks were not tied to a single actor or infrastructure but to multiple groups, which made attributing the attacks and discerning the motive behind them significantly harder.

To keep up with the Mirai variants proliferation and track the various hacking groups behind them, we turned to infrastructure clustering. Reverse engineering all the Mirai versions we can find allowed us to extract the IP addresses and domains used as C&C by the various hacking groups than ran their own Mirai variant. In total, we recovered two IP addresses and 66 distinct domains.

Applying DNS expansion on the extracted domains and clustering them led us to identify 33 independent C&C clusters that had no shared infrastructure. The smallest of these clusters used a single IP as C&C. The largest sported 112 domains and 92 IP address. The figure above depicts the six largest clusters we found.

These top clusters used very different naming schemes for their domain names: for example, “cluster 23” favors domains related to animals such as 33kitensspecial.pw, while “cluster 1” has many domains related to e-currencies such as walletzone.ru. The existence of many distinct infrastructures with different characteristics confirms that multiple groups ran Mirai independently after the source code was leaked.

Looking at how many DNS lookups were made to their respective C&C infrastructures allowed us to reconstruct the timeline of each individual cluster and estimate its relative size. This accounting is possible because each bot must regularly perform a DNS lookup to know which IP address its C&C domains resolves to.

The chart above reports the number of DNS lookups over time for some of the largest clusters. It highlights the fact that many were active at the same time. Having multiple variants active simultaneously once again emphasizes that multiple actors with different motives were competing to infect vulnerable IoT devices to carry out their DDoS attacks.

Plotting all the variants in the graph clearly shows that the ranges of IoT devices infect by each variant differ widely. As the graph above reveals, while there were many Mirai variants, very few succeeded at growing a botnet large enough to take down major websites.

Notable clusters

Looking at which sites were targeted by the largest clusters illuminates the specific motives behind those variants. For instance, as reported in the table above, the original Mirai botnet (cluster 1) targeted OVH and Krebs, whereas Mirai’s largest instance (cluster 6) targeted DYN and other gaming-related sites. Mirai’s third-largest variant (cluster 2), in contrast, went after African telecom operators, as recounted later in this post.

Looking at the most attacked services across all Mirai variants reveals the following:

1. Booter services monetized Mirai: The wide diversity of targets shows that booter services ran at least some of the largest clusters. A booter service is a service provided by cyber criminals that offers on-demand DDoS attack capabilities to paying customers.

2. There are fewer actors than clusters: Some clusters have strong overlapping targets, which tends to indicate that they were run by the same actors. For example, clusters 15, 26, and 6 were used to target specific Minecraft servers.

On October 21, a Mirai attack targeted the popular DNS provider DYN. This event prevented Internet users from accessing many popular websites, including AirBnB, Amazon, GitHub, HBO, Netflix, PayPal, Reddit, and Twitter, by disturbing the DYN name-resolution service.

We believe this attack was not meant to “take down the Internet,” as it was painted by the press, but rather was linked to a larger set of attacks against gaming platforms.

We reached this conclusion by looking at the other targets of the DYN variant (cluster 6). They are all gaming related. Additionally, this is also consistent with the OVH attack as it was also targeted because it hosted specific game servers as discussed earlier. As sad as it seems, all the prominent sites affected by the DYN attack were apparently just the spectacular collateral damage to a war between gamers.

Lonestar Cell, one of the largest Liberian telecom operators started to be targeted by Mirai on October 31. Over the next few months, it suffered 616 attacks, the most of any Mirai victim.

The fact that the Mirai cluster responsible for these attack has no common infrastructure with the original Mirai or the DYN variant indicate that they were orchestrated by a totally different actor than the original author.

A few weeks after our study was published, this assessment was confirmed when the author of one of the most aggressive Mirai variant confessed during his trial that he was paid to takedown Lonestar. He acknowledged that an unnamed Liberia’s ISP paid him $10,000 to take out its competitors. This validated that our clustering approach is able to accurately track and attribute Mirai’s attacks.

On November 26, 2016, one of the largest German Internet provider Deutsche Telekom suffered a massive outage after 900,000 of its routers were compromised.

Ironically, this outage was not due to yet another Mirai DDoS attack but instead due to a particularly innovative and buggy version of Mirai that knocked these devices offline while attempting to compromise them. This variant also affected thousands of TalkTalk routers.

What allowed this variant to infect so many routers was the addition to its replication module of a router exploit targeting at the CPE WAN Management Protocol (CWMP). The CWMP protocol is an HTTP-based protocol used by many Internet providers to autoconfigure and remotely manage home routers, modems, and other customer-on-premises (CPE) equipment.

Beside its scale, this incident is significant because it demonstrates how the weaponizations of more complex IoT vulnerabilities by hackers can lead to very potent botnets. We hope the Deutsche Telekom event acts as a wake-up call and push toward making IoT auto-update mandatory. This is much needed to curb the significant risk posed by vulnerable IoT device given the poor track record of Internet users manually patching their IoT devices.

In the months following his website being taken offline, Brian Krebs devoted hundreds of hours to investigating Anna-Senpai, the infamous Mirai author. In early January 2017, Brian announced that he believes Anna-senpai to be Paras Jha, a Rutgers student who apparently has been involved in previous game-hacking related schemes. Brian also identified Josia White as a person of interest. After being outed, Paras Jha and Josia White and another individual were questioned by authorities and plead guilty in federal court to a variety of charges, some including their activity related to Mirai.

In November 2016, Daniel Kaye (aka BestBuy) the author of the Mirai botnet variant that brought down Deutsche Telekom was arrested at the Luton airport. Prior to Mirai, a 29-year-old British citizen was infamous for selling his hacking services on various dark web markets.

In July 2017 a few months after being extradited to Germany Daniel Kaye plead guilty and was sentenced to a one year and a half imprisonment with suspension. During the trial, Daniel admitted that he never intended for the routers to cease functioning. He only wanted to silently control them, so he can use them as part of a DDoS botnet to increase his botnet firepower. As discussed earlier he also confessed being paid by competitors to takedown Lonestar.

In Aug 2017 Daniel was extradited back to the UK to face extortion charges after attempting to blackmail Lloyds and Barclays banks. According to press reports, he asked the Lloyds to pay about £75,000 in bitcoins for the attack to be called off.

The prevalence of insecure IoT devices on the Internet makes it very likely that, for the foreseeable future, they will be the main source of DDoS attacks.

Mirai and subsequent IoT botnets can be averted if IoT vendors start to follow basic security best practices. In particular, we recommend that the following should be required of all IoT device makers:

• Eliminate default credentials: This will prevent hackers from constructing a credential main list that allows them to compromise a myriad of devices as MIRAI did.

• Make auto-patching mandatory: IoT devices are meant to be “set and forget,” which makes manual patching unlikely. Having them auto-patch is the only reasonable option to ensure that no widespread vulnerability like the Deutsche Telekom one can be exploited to take down a large chunk of the Internet.

• Implement rate limiting: Enforcing login rate limiting to prevent brute-force attack is a good way to mitigate the tendency of people to use weak passwords. Another alternative would be using a captcha or a proof or work.

Thank you for reading this post until the end!