Programmable Flow Protection is currently in beta and available to all Magic Transit Enterprise customers for an additional cost. Contact your account team to join the beta or sign up at this page.

Our existing DDoS mitigation systems have been designed to understand and protect popular, well-known protocols from DDoS attacks. For example, our Advanced TCP Protection system uses specific known characteristics about the TCP protocol to issue challenges and establish a client’s legitimacy. Similarly, our Advanced DNS Protection builds a per-customer profile of DNS queries to mitigate DNS attacks. Our generic DDoS mitigation platform also understands common patterns across a variety of other well known protocols, including NTP, RDP, SIP, and many others.

However, custom or proprietary UDP protocols have always been a challenge for Cloudflare’s DDoS mitigation systems because our systems do not have the relevant protocol knowledge to make intelligent decisions to pass or drop traffic. 

Programmable Flow Protection addresses this gap. Now, customers can write their own eBPF program that defines what “good” and “bad” packets are and how to deal with them. Cloudflare then runs the program across our entire global network. The program can choose to either drop or challenge “bad” packets, preventing them from reaching the customer’s origin. 

UDP is a connectionless transport layer protocol. Unlike TCP, UDP has no handshake or stateful connections. It does not promise that packets will arrive in order or exactly once. UDP instead prioritizes speed and simplicity, and is therefore well-suited for online gaming, VoIP, video streaming, and any other use case where the application requires real-time communication between clients and servers.

Our DDoS mitigation systems have always been able to detect and mitigate attacks against well-known protocols built on top of UDP. For example, the standard DNS protocol is built on UDP, and each DNS packet has a well-known structure. If we see a DNS packet, we know how to interpret it. That makes it easier for us to detect and drop DNS-based attacks. 

Unfortunately, if we don’t understand the protocol inside a UDP packet’s payload, our DDoS mitigation systems have limited options available at mitigation time. If an attacker sends a large flood of UDP traffic that does not match any known patterns or protocols, Cloudflare can either entirely block or apply a rate limit to the destination IP and port combination. This is a crude “last line of defense” that is only intended to keep the rest of the customer’s network online, and it can be painful in a couple ways. 

First, a block or a generic rate limit does not distinguish good traffic from bad, which means these mitigations will likely cause legitimate clients to experience lag or connection loss — doing the attacker’s job for them! Second, a generic rate limit can be too strict or too lax depending on the customer. For example, a customer who expects to receive 1Gbps of legitimate traffic probably needs more aggressive rate limiting compared to a customer who expects to receive 25Gbps of legitimate traffic.

^{An illustration of UDP packet contents. A user can define a valid payload and reject traffic that doesn’t match the defined pattern.}

The Programmable Flow Protection platform was built to address this problem by allowing our customers to dictate what “good” versus “bad” traffic actually looks like. Many of our customers use custom or proprietary UDP protocols that we do not understand — and now we don’t have to.

In previous blog posts, we’ve described how “flowtrackd”, our stateful network layer DDoS mitigation system, protects Magic Transit users from complex TCP and DNS attacks. We’ve also described how we use Linux technologies like XDP and eBPF to efficiently mitigate common types of large scale DDoS attacks. 

Programmable Flow Protection combines these technologies in a novel way. With Programmable Flow Protection, a customer can write their own eBPF program that decides whether to pass, drop, or challenge individual packets based on arbitrary logic. A customer can upload the program to Cloudflare, and Cloudflare will execute it on every packet destined to their network. Programs are executed in userspace, not kernel space, which allows Cloudflare the flexibility to support a variety of customers and use cases on the platform without compromising security. Programmable Flow Protection programs run after all of Cloudflare’s existing DDoS mitigations, so users still benefit from our standard security protections. 

There are many similarities between an XDP eBPF program loaded into the Linux kernel and an eBPF program running on the Programmable Flow Protection platform. Both types of programs are compiled down to BPF bytecode. They are both run through a “verifier” to ensure memory safety and verify program termination. They are also executed in a fast, lightweight VM to provide isolation and stability.

However, eBPF programs loaded into the Linux kernel make use of many Linux-specific “helper functions” to integrate with the network stack, maintain state between program executions, and emit packets to network devices. Programmable Flow Protection offers the same functionality whenever a customer chooses, but with a different API tailored specifically to implement DDoS mitigations. For example, we’ve built helper functions to store state about clients between program executions, perform cryptographic validation, and emit challenge packets to clients. With these helper functions, a developer can use the power of the Cloudflare platform to protect their own network.

Let’s step through an example to illustrate how a customer’s protocol-specific knowledge can be combined with Cloudflare’s network to create powerful mitigations.

Say a customer hosts an online gaming server on UDP port 207. The game engine uses a proprietary application header that is specific to the game. Cloudflare has no knowledge of the structure or contents of the application header. The customer gets hit by DDoS attacks that overwhelm the game server and players report lag in gameplay. The attack traffic comes from highly randomized source IPs and ports, and the payload data appears to be random as well. 

To mitigate the attack, the customer can use their knowledge of the application header and deploy a Programmable Flow Protection program to check a packet’s validity. In this example, the application header contains a token that is unique to the gaming protocol. The customer can therefore write a program to extract the last byte of the token. The program passes all packets with the correct value present and drops all other traffic:

#include <linux/ip.h>
#include <linux/udp.h>
#include <arpa/inet.h>

#include "cf_ebpf_defs.h"
#include "cf_ebpf_helper.h"

// Custom application header
struct apphdr {
    uint8_t  version;
    uint16_t length;   // Length of the variable-length token
    uint8_t  token[0]; // Variable-length token
} __attribute__((packed));

uint64_t
cf_ebpf_main(void *state)
{
    struct cf_ebpf_generic_ctx *ctx = state;
    struct cf_ebpf_parsed_headers headers;
    struct cf_ebpf_packet_data *p;

    // Parse the packet headers with provided helper function
    if (parse_packet_data(ctx, &p, &headers) != 0) {
        return CF_EBPF_DROP;
    }

    // Drop packets not destined to port 207
    struct udphdr *udp_hdr = (struct udphdr *)headers.udp;
    if (ntohs(udp_hdr->dest) != 207) {
        return CF_EBPF_DROP;
    }

    // Get application header from UDP payload
    struct apphdr *app = (struct apphdr *)(udp_hdr + 1);
    if ((uint8_t *)(app + 1) > headers.data_end) {
        return CF_EBPF_DROP;
    }

    // Perform memory checks to satisfy the verifier
    // and access the token safely
    if ((uint8_t *)(app->token + token_len) > headers.data_end) {
        return CF_EBPF_DROP;
    }

    // Check the last byte of the token against expected value
    uint8_t *last_byte = app->token + token_len - 1;
    if (*last_byte != 0xCF) {
        return CF_EBPF_DROP;
    }

    return CF_EBPF_PASS;
}

^{An eBPF program to filter packets according to a value in the application header.}

This program leverages application-specific information to create a more targeted mitigation than Cloudflare is capable of crafting on its own. Customers can now combine their proprietary knowledge with the capacity of Cloudflare’s global network to absorb and mitigate massive attacks better than ever before.

Many pattern checks, like the one performed in the example above, can be accomplished with traditional firewalls. However, programs provide useful primitives that are not available in firewalls, including variables, conditional execution, loops, and procedure calls. But what really sets Programmable Flow Protection apart from other solutions is its ability to statefully track flows and challenge clients to prove they are real. A common type of attack that showcases these abilities is a replay attack.

In a replay attack, an attacker repeatedly sends packets that were valid at some point, and therefore conform to expected patterns of the traffic, but are no longer valid in the application’s current context. For example, the attacker could record some of their valid gameplay traffic and use a script to duplicate and transmit the same traffic at a very high rate.

With Programmable Flow Protection, a user can deploy a program that challenges suspicious clients and drops scripted traffic. We can extend our original example as follows:

#include <linux/ip.h>
#include <linux/udp.h>
#include <arpa/inet.h>

#include "cf_ebpf_defs.h"
#include "cf_ebpf_helper.h"

uint64_t
cf_ebpf_main(void *state)
{
    // ...
 
    // Get the status of this source IP (statefully tracked)
    uint8_t status;
    if (cf_ebpf_get_source_ip_status(&status) != 0) {
        return CF_EBPF_DROP;
    }

    switch (status) {
        case NONE:
		// Issue a custom challenge to this source IP
             issue_challenge();
             cf_ebpf_set_source_ip_status(CHALLENGED);
             return CF_EBPF_DROP;


        case CHALLENGED:
		// Check if this packet passes the challenge
		// with custom logic
             if (verify_challenge()) {
                 cf_ebpf_set_source_ip_status(VERIFIED);
                 return CF_EBPF_PASS;
             } else {
                 cf_ebpf_set_source_ip_status(BLOCKED);
                 return CF_EBPF_DROP;
             }


        case VERIFIED:
		// This source IP has passed the challenge
		return CF_EBPF_PASS;

	 case BLOCKED:
		// This source IP has been blocked
		return CF_EBPF_DROP;

        default:
            return CF_EBPF_PASS;
    }


    return CF_EBPF_PASS;
}

^{An eBPF program to challenge UDP connections and statefully manage connections. This example has been simplified for illustration purposes.}

The program statefully tracks the source IP addresses it has seen and emits a packet with a cryptographic challenge back to unknown clients. A legitimate client running a valid gaming client is able to correctly solve the challenge and respond with proof, but the attacker’s script is not. Traffic from the attacker is marked as “blocked” and subsequent packets are dropped.

With these new abilities, customers can statefully track flows and make sure only real, verified clients can send traffic to their origin servers. Although we have focused the example on gaming, the potential use cases for this technology extend to any UDP-based protocol.

We’re excited to offer the Programmable Flow Protection feature to Magic Transit Enterprise customers. Talk to your account manager to learn more about how you can enable Programmable Flow Protection to help keep your infrastructure safe.

We’re still in active development of the platform, and we’re excited to see what our users build next. If you are not yet a Cloudflare customer, let us know if you’d like to protect your network with Cloudflare and Programmable Flow Protection by signing up at this page: https://www.cloudflare.com/lp/programmable-flow-protection/.

The fourth quarter of 2025 was characterized by an unprecedented bombardment launched by the Aisuru-Kimwolf botnet, dubbed “The Night Before Christmas" DDoS attack campaign. The campaign targeted Cloudflare customers as well as Cloudflare’s dashboard and infrastructure with hyper-volumetric HTTP DDoS attacks exceeding rates of 200 million requests per second (rps), just weeks after a record-breaking 31.4 Terabits per second (Tbps) attack.

1. DDoS attacks surged by 121% in 2025, reaching an average of 5,376 attacks automatically mitigated every hour.

2. In the final quarter of 2025, Hong Kong jumped 12 places, making it the second most DDoS’d place on earth. The United Kingdom also leapt by an astonishing 36 places, making it the sixth most-attacked place.

3. Infected Android TVs — part of the Aisuru-Kimwolf botnet — bombarded Cloudflare’s network with hyper-volumetric HTTP DDoS attacks, while Telcos emerged as the most-attacked industry.

In 2025, the total number of DDoS attacks more than doubled to an incredible 47.1 million. Such attacks have soared in recent years: The number of DDoS attacks spiked 236% between 2023 and 2025.

In 2025, Cloudflare mitigated an average of 5,376 DDoS attacks every hour — of these, 3,925 were network-layer DDoS attacks and 1,451 were HTTP DDoS attacks. 

The most substantial growth was in network-layer DDoS attacks, which more than tripled year over year. Cloudflare mitigated 34.4 million network-layer DDoS attacks in 2025, compared to 11.4 million in 2024.

A substantial portion of the network-layer attacks — approximately 13.5 million — targeted global Internet infrastructure protected by Cloudflare Magic Transit and Cloudflare’s infrastructure directly, as part of an 18-day DDoS campaign in the first quarter of 2025. Of these attacks, 6.9 million targeted Magic Transit customers while the remaining 6.6 million targeted Cloudflare directly. 

This assault was a multi-vector DDoS campaign comprising SYN flood attacks, Mirai-generated DDoS attacks, and SSDP amplification attacks to name a few. Our systems detected and mitigated these attacks automatically. In fact, we only discovered the campaign while preparing our DDoS threat report for 2025 Q1 — an example of how effective Cloudflare’s DDoS mitigation is!

In the final quarter of 2025, the number of DDoS attacks grew by 31% over the previous quarter and 58% over 2024. Network-layer DDoS attacks fueled that growth. In 2025 Q4, network-layer DDoS attacks accounted for 78% of all DDoS attacks. The amount of HTTP DDoS attacks remained the same, but surged in their size to rates that we haven’t seen since the HTTP/2 Rapid Reset DDoS campaign in 2023. These recent surges were launched by the Aisuru-Kimwolf botnet, which we will cover in the next section. 

On Friday, December 19, 2025, the Aisuru-Kimwolf botnet began bombarding Cloudflare infrastructure and Cloudflare customers with hyper-volumetric DDoS attacks. What was new in this campaign was its size: The botnet used hyper-volumetric HTTP DDoS attacks exceeding rates of 20 million requests per second (Mrps).

The Aisuru-Kimwolf botnet is a massive collection of malware-infected devices, primarily Android TVs. The botnet comprises an estimated 1-4 million infected hosts. It is capable of launching DDoS attacks that can cripple critical infrastructure, crash most legacy cloud-based DDoS protection solutions, and even disrupt the connectivity of entire nations.

Throughout the campaign, Cloudflare’s autonomous DDoS defense systems detected and mitigated all of the attacks: 384 packet-intensive attacks, 329 bit-intensive attacks, and 189 request-intensive attacks, for a total of 902 hyper-volumetric DDoS attacks, averaging 53 attacks a day.

The average size of the hyper-volumetric DDoS attacks during the campaign were 3 Bpps, 4 Tbps, and 54 Mrps. The maximum rates recorded during the campaign were 9 Bpps, 24 Tbps, and 205 Mrps.

To put that in context, the scale of a 205 Mrps DDoS attack is comparable to the combined populations of the UK, Germany, and Spain all simultaneously typing a website address and then hitting 'enter’ at the same second.

While highly dramatic, The Night Before Christmas campaign accounted for only a small portion of the hyper-volumetric DDoS attacks we saw throughout the year.

Throughout 2025, Cloudflare observed a continuous increase in hyper-volumetric DDoS attacks. In 2025 Q4, hyper-volumetric attacks increased by 40% compared to the previous quarter.

As the number of attacks increased over the course of 2025, the size of the attacks increased as well, growing by over 700% compared to the large attacks seen in late 2024, with one reaching 31.4 Tbps in a DDoS attack that lasted just 35 seconds. The graph below portrays the rapid growth in DDoS attack sizes as seen and blocked by Cloudflare — each one a world record, i.e. the largest ever disclosed publicly by any company at the time.

Like all of the other attacks, the 31.4 Tbps DDoS attack was detected and mitigated automatically by Cloudflare’s autonomous DDoS defense, which was able to adapt and quickly lock on to botnets such as Aisuru-Kimwolf.

Most of the hyper-volumetric DDoS attacks targeted Cloudflare customers in the Telecommunications, Service Providers and Carriers industry. Cloudflare customers in the Gaming industry and customers providing Generative AI services were also heavily targeted. Lastly, Cloudflare’s own infrastructure itself was targeted by multiple attack vectors such as HTTP floods, DNS attacks and UDP flood.

When analyzing DDoS attacks of all sizes, the Telecommunications, Service Providers and Carriers industry was also the most targeted. Previously, the Information Technology & Services industry held that unlucky title.

The Gambling & Casinos and Gaming industries ranked third and fourth, respectively. The quarter’s biggest changes in the top 10 were the Computer Software and Business Services industries, which both climbed several spots. 

The most-attacked industries are defined by their role as critical infrastructure, a central backbone for other businesses, or their immediate, high-stakes financial sensitivity to service interruption and latency.

The DDoS landscape saw both predictable stability and dramatic shifts among the world's most-attacked locations. Targets like China, Germany, Brazil, and the United States were the top five, demonstrating persistent appeal for attackers. 

Hong Kong made a significant move, jumping twelve spots to land at number two. However, the bigger story was the meteoric rise of the United Kingdom, which surged an astonishing 36 places this quarter, making it the sixth most-attacked location.  

Vietnam held its place as the seventh most-attacked location, followed by Azerbaijan in eighth, India in ninth, and Singapore as number ten.

Bangladesh dethroned Indonesia as the largest source of DDoS attacks in the fourth quarter of 2025. Indonesia dropped to the third spot, after spending a year as the top source of DDoS attacks. Ecuador also jumped two spots, making it the second-largest source.

Notably, Argentina soared an incredible twenty places, making it the fourth-largest source of DDoS attacks. Hong Kong rose three places, taking fifth place. Ukraine came in sixth place, followed by Vietnam, Taiwan, Singapore, and Peru.

The top 10 list of attack source networks reads like a list of Internet giants, revealing a fascinating story about the anatomy of modern DDoS attacks. The common thread is clear: Threat actors are leveraging the world's most accessible and powerful network infrastructure — primarily large, public-facing services. 

We see most DDoS attacks coming from IP addresses associated with Cloud Computing Platforms and Cloud Infrastructure Providers, including DigitalOcean (AS 14061), Microsoft (AS 8075), Tencent (AS 132203), Oracle (AS 31898), and Hetzner (AS 24940). This demonstrates the strong link between easily-provisioned virtual machines and high-volume attacks. These cloud sources, heavily concentrated in the United States, are closely followed by a significant presence of attacks coming from IP addresses associated with traditional Telecommunications Providers (Telcos). These Telcos, primarily from the Asia-Pacific region (including Vietnam, China, Malaysia, and Taiwan), round out the rest of the top 10.

This geographic and organizational diversity confirms a two-pronged attack reality: While the sheer scale of the highest-ranking sources often originates from global cloud hubs, the problem is truly worldwide, routed through the Internet's most critical pathways from across the globe. In many DDoS attacks, we see thousands of various source ASNs, highlighting the truly global distribution of botnet nodes.

To help hosting providers, cloud computing platforms and Internet service providers identify and take down the abusive IP addresses/accounts that launch these attacks, we leverage Cloudflare’s unique vantage point on DDoS attacks to provide a free DDoS Botnet Threat Feed for Service Providers. 

Over 800 networks worldwide have signed up for this feed, and we’ve already seen great collaboration across the community to take down botnet nodes.

DDoS attacks are rapidly growing in sophistication and size, surpassing what was previously imaginable. This evolving threat landscape presents a significant challenge for many organizations to keep pace. Organizations currently relying on on-premise mitigation appliances or on-demand scrubbing centers may benefit from re-evaluating their defense strategy.

Cloudflare is dedicated to offering free, unmetered DDoS protection to all its customers, regardless of the size, duration, or volume of attacks, leveraging its vast global network and autonomous DDoS mitigation systems.

Driven by a mission to help defend the Internet, Cloudforce One leverages telemetry from Cloudflare’s global network — which protects approximately 20% of the web — to drive threat research and operational response, protecting critical systems for millions of organizations worldwide.

The third quarter of 2025 was overshadowed by the Aisuru botnet with a massive army of an estimated 1–4 million infected hosts globally. Aisuru unleashed hyper-volumetric DDoS attacks routinely exceeding 1 terabit per second (Tbps) and 1 billion packets per second (Bpps). The number of these attacks surged 54% quarter-over-quarter (QoQ), averaging 14 hyper-volumetric attacks daily. The scale was unprecedented, with attacks peaking at 29.7 Tbps and 14.1 Bpps.

Other than Aisuru, additional key insights in this report include:

1. DDoS attack traffic against AI companies surged by as much as 347% MoM in September 2025, as public concern and regulatory review of AI increases. 

2. Escalating EU-China trade tensions over rare earth minerals and EV tariffs coincide with a significant increase in DDoS attacks against the Mining, Minerals & Metals industry as well as the Automotive industry in 2025 Q3.

3. Overall, in the third quarter of 2025, Cloudflare’s autonomous defenses blocked a total of 8.3 million DDoS attacks. That’s an average of almost 3,780 DDoS attacks per hour. The number of DDoS attacks grew by 15% QoQ and 40% YoY. 

So far in 2025, and with an entire quarter to go until the end of the year, Cloudflare has already mitigated 36.2 million DDoS attacks. That corresponds to 170% of the DDoS attacks Cloudflare mitigated throughout 2024.

In the third quarter of 2025, Cloudflare automatically detected and mitigated 8.3 million DDoS attacks, representing a 15% increase QoQ and 40% increase YoY.

Network-layer DDoS attacks, accounting for 71% of the DDoS attacks in 2025 Q3, or 5.9 million DDoS attacks, increased by 87% QoQ and 95% YoY. However, HTTP DDoS attacks, accounting only for 29% of the DDoS attacks in 2025 Q3, or 2.4 million DDoS attacks, decreased by 41% QoQ and 17% YoY.

In the third quarter of 2025, Cloudflare mitigated an average of 3,780 DDoS attacks every hour.

Disruptive force

Aisuru targeted telecommunication providers, gaming companies, hosting providers, and financial services, to name a few. It has also caused “widespread collateral Internet disruption [in the US]”, as reported by Krebs on Security, simply due to the amount of botnet traffic routing through the Internet Service Providers (ISPs). 

Let that sink in. If Aisuru’s attack traffic can disrupt parts of the U.S. Internet infrastructure when said ISPs were not even the target of the attack, imagine what it can do when it’s directly aimed at unprotected or insufficiently protected ISPs, critical infrastructure, healthcare services, emergency services, and military systems. 

Botnet-for-hire and DDoS stats

“Chunks” of Aisuru are offered by distributors as botnets-for-hire, so anyone can potentially inflict chaos on entire nations by crippling backbone networks and saturating Internet links, disrupting millions of users and impairing access to essential services — all at a cost of a few hundred to a few thousand U.S. dollars. 

Since the start of 2025, Cloudflare has already mitigated 2,867 Aisuru attacks. In the third quarter alone, Cloudflare mitigated 1,304 hyper-volumetric attacks launched by Aisuru. That represents an increase of 54% QoQ. These include the world record-breaking 29.7 Tbps DDoS attack and the 14.1 Bpps DDoS attack. 

The 29.7 Tbps was a UDP carpet-bombing attack bombarding an average of 15K destination ports per second. The distributed attack randomized various packet attributes in an attempt to evade defenses, but Cloudflare’s mitigation systems detected and mitigated all the attacks, including this one, fully autonomously. Read more on How Cloudflare mitigates hyper-volumetric DDoS attacks.

While the majority of DDoS attacks are relatively small, in Q3, the amount of DDoS attacks that exceeded 100 million packets per second (Mpps) increased by 189% QoQ. Similarly, attacks exceeding 1 Tbps increased by 227% QoQ. On the HTTP layer, 4 out of every 100 attacks exceeded 1 million requests per second. 

Furthermore, most attacks, 71% of HTTP DDoS and 89% of network-layer, end in under 10 minutes. That's too fast for any human or on-demand service to react. A short attack may only last a few seconds, but the disruption it causes can be severe, and recovery takes far longer. Engineering and operational teams are then stuck with a complex, multi-step process to get critical systems back online, check data for consistency across distributed systems, and restore secure, reliable service to customers. 

The impact of short-lived DDoS attacks, whether hyper-volumetric or not, can extend well beyond the duration of the attack.

Seven out of the ten top sources are locations within Asia, with Indonesia in the lead. Indonesia is the largest source of DDoS attacks, and it has been ranked number one in the world for an entire year (since 2024 Q3). Even prior to this, Indonesia has always been placed in the top lists of attack sources. In 2024 Q2, Indonesia was the second-largest source, after climbing up from lower ranks in previous quarters and years.

To illustrate the rise of Indonesia as a DDoS hub, in just five years (since 2021 Q3), the percentage of HTTP DDoS attack requests originating from Indonesia has increased by a staggering 31,900%. 

DDoS attackers go after rare Earth minerals

DDoS attacks against the Mining, Minerals & Metals industry significantly increased in the third quarter of 2025 as the 25th European Union–China trade summit saw rising tensions over Electric Vehicle (EV) tariffs, rare-earth exports, and cybersecurity issues, according to multiple news outlets. The BBC reported that “China also raised export controls on rare earths and critical minerals.” Overall, the Mining, Minerals & Metals industry surged 24 spots on the global ranking, making it the 49th most attacked industry in the world.

The Automotive industry saw the largest surge in DDoS attacks, leaping the industry by 62 spots in just one quarter, placing it as the sixth most attacked industry in the world. Cybersecurity companies also saw a significant increase in DDoS attacks. The Cybersecurity industry hopped by 17 spots, making it the 13th most attacked industry in the world.

DDoS attacks against AI surge by 347%

In September 2025, a Tony Blair Institute poll showed Britons view AI more as an economic risk than an opportunity, sparking major headlines about automation and trust. The UK Law Commission launched a review into AI use in government, making it a headline month for AI ethics, regulation, and generative-AI adoption. In September 2025, Cloudflare also saw MoM spikes as high as 347% in HTTP DDoS attack traffic against generative AI companies (based on a sample of leading generative AI services).

The top 10

In the third quarter of 2025, Information Technology & Services topped the list as the most attacked industry, followed by Telecommunications, and Gambling & Casinos. Notably, Automotive surged dramatically by 62 spots QoQ. Media, Production & Publishing also saw a sharp rise, preceded by the Banking & Financial Services industry, the Retail industry, and the Consumer Electronics industry.

There is a direct correlation between geopolitical events and DDoS attack activity.

Stop the Loot!

"Lootuvaifi" (Stop the Loot!) in Maldivian, became the rallying chant in the 2025 Maldivian protests as protesters took to the streets objecting the “perceived government corruption and democratic backsliding,” peaking with the “end of free speech” media bill, which the UN Human Rights Chief said will “seriously undermine media freedom and the right to freedom of expression for the people of the Maldives if not withdrawn.” The 2025 Maldivian protests were accompanied by a barrage of DDoS attacks. Correspondingly, the Maldives was the country that saw the highest increase in DDoS attacks. In the third quarter of 2025, the Maldives leaped by 125 spots, making it the 38th most attacked country in the world.

‘Block Everything’

The nationwide protest movement, “Block Everything,” or “Bloquons Tout” in French, was launched by French trade unions in September 2025 to oppose President Macron’s government over new austerity measures, pension system changes, and rising living costs. While trade unions called for coordinated strikes and transport blockades to paralyze the country, cyber threat actors targeted French websites and Internet services with waves of DDoS attacks. France jumped 65 spots QoQ, making it the 18th most attacked country in the world. 

‘Drawing the red line for Gaza in Brussels’

Increases in DDoS attacks were observed alongside protests in more countries. For example, Belgium jumped 63 places making it the 74th most attacked country in the world, as “tens of thousands of protesters drew the Red Line for Gaza in Brussels.”

The top 10

In the third quarter of 2025, China remained the most attacked, followed by Turkey in second, and Germany in third place. The most notable changes within this quarter was an increase in DDoS attacks against the United States, which leaped by 11 spots as the fifth most attacked country. The Philippines saw the largest increase within the top 10 – it jumped by 20 spots.

Network-layer DDoS attacks

The number of UDP DDoS attacks, partially fueled by Aisuru attacks, increased by 231% QoQ making it the top attack vector at the network-layer. DNS floods came in second place, SYN floods in third, and ICMP floods in fourth — accounting for just over half of all network-layer DDoS attacks.

Although almost 10 years have passed since its first major debut, Mirai DDoS attacks are still quite common. Almost 2 out of every 100 network-layer DDoS attacks are launched by permutations of the Mirai botnet.

HTTP DDoS attacks

Nearly 70% of HTTP DDoS attacks originated from botnets already known to Cloudflare. This reflects one of the benefits that our customers gain from using Cloudflare. Once a botnet attacks one out of the millions of Cloudflare customers, everyone is automatically protected from that botnet.

Another ~20% of HTTP DDoS attacks originated from fake or headless browsers, or included suspicious HTTP attributes. The remaining ~10% were a combination of generic floods, unusual requests, cache busting attacks, and attacks that targeted login endpoints.

We've entered an era where DDoS attacks have rapidly grown in sophistication and size — beyond anything we could’ve imagined a few years ago. Many organizations have faced challenges in keeping pace with this evolving threat landscape. 

Organizations relying on on-premise mitigation appliances or on-demand scrubbing center solutions may benefit from reviewing their defense strategy given the current threat landscape.

Cloudflare, with its vast global network and autonomous DDoS mitigation systems, is committed to providing free unmetered DDoS protection to all customers, no matter the size, duration, or quantity of the DDoS attacks they face.

In this blog post, we describe the background to well-known HTTP/2 attacks that trigger Cloudflare defences, which close connections. We then document an easy-to-make mistake using Go's standard library that can cause clients to send PING flood attacks and how you can avoid it.

HTTP/2 defines a binary wire format for encoding HTTP semantics. Request and response messages are encoded as a series of HEADERS and DATA frames, each associated with a logical stream, sent over a TCP connection using TLS. There are also control frames that relate to the management of streams or the connection as a whole. For example, SETTINGS frames advertise properties of an endpoint, WINDOW_UPDATE frames provide flow control credit to a peer so that it can send data, RST_STREAM can be used to cancel or reject a request or response, while GOAWAY can be used to signal graceful or immediate connection closure.

HTTP/2 provides many powerful features that have legitimate uses. However, with great power comes responsibility and opportunity for accidental or intentional misuse. The specification details a number of denial-of-service considerations. Implementations are advised to harden themselves: "An endpoint that doesn't monitor use of these features exposes itself to a risk of denial of service. Implementations SHOULD track the use of these features and set limits on their use."

Cloudflare implements many different HTTP/2 defenses, developed over years in order to protect our systems and our customers. Some notable examples include mitigations added in 2019 to address "Netflix vulnerabilities" and in 2023 to mitigate Rapid Reset and similar style attacks.

When Cloudflare detects that HTTP/2 client behaviour is likely malicious, we close the connection using the GOAWAY frame and include the error code ENHANCE_YOUR_CALM.

One of the well-known and common attacks is CVE-2019-9512, aka PING flood: "The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both." Sending a PING frame causes the peer to respond with a PING acknowledgement (indicated by an ACK flag). This allows for checking the liveness of the HTTP connection, along with measuring the layer 7 round-trip time – both useful things. The requirement to acknowledge a PING, however, provides the potential attack vector since it generates work for the peer.

A client that PINGs the Cloudflare edge too frequently will trigger our CVE-2019-9512 mitigations, causing us to close the connection. Shortly after we launched support for gRPC in 2020, we encountered interoperability issues with some gRPC clients that sent many PINGs as part of a performance optimization for window tuning. We also discovered that the Rust Hyper crate had a feature called Adaptive Window that emulated the design and triggered a similar problem until Hyper made a fix.

When that thread popped up asking which part of our stack was responsible for sending the ENHANCE_YOUR_CALM error code, it was regarding a client communicating over HTTP/2 between two internal microservices.

We suspected that this was an HTTP/2 mitigation issue and confirmed it was a PING flood mitigation in our logs. But taking a step back, you may wonder why two internal microservices are communicating over the Cloudflare edge at all, and therefore hitting our mitigations. In this case, communicating over the edge provides us with several advantages:

1. We get to dogfood our edge infrastructure and discover issues like this!

2. We can use Cloudflare Access for authentication. This allows our microservices to be accessed securely by both other services (using service tokens) and engineers (which is invaluable for debugging).

3. Internal services that are written with Cloudflare Workers can easily communicate with services that are accessible at the edge.

The question remained: Why was this client behaving this way? We traded some ideas as we attempted to get to the bottom of the issue.

The client had a configuration that would indicate that it didn't need to PING very frequently:

t2.PingTimeout = 2 * time.Second
t2.ReadIdleTimeout = 5 * time.Second

However, in situations like this it is generally a good idea to establish ground truth about what is really happening "on the wire." For instance, grabbing a packet capture that can be dissected and explored in Wireshark can provide unequivocal evidence of precisely what was sent over the network. The next best option is detailed/trace logging at the sender or receiver, although sometimes logging can be misleading, so caveat emptor.

In our particular case, it was simpler to use logging with GODEBUG=http2debug=2. We built a simplified minimal reproduction of the client that triggered the error, helping to eliminate other potential variables. We did some group log analysis, combined with diving into some of the Go standard library code to understand what it was really doing. Issac Asimov is commonly credited with the quote "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny...'" and sure enough, within the hour someone declared– the funny part I see is this:

2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote RST_STREAM stream=9 len=4 ErrCode=CANCEL
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote PING len=8 ping="j\xe7\xd6R\xdaw\xf8+"

every ping seems to be preceded by a RST_STREAM

Observant readers will recall the earlier mention of Rapid Reset. However, our logs clearly indicated ENHANCE_YOUR_CALM being triggered due to the PING flood. A bit of searching landed us on this mailing list thread and the comment "Sending a PING frame along with an RST_STREAM allows a client to distinguish between an unresponsive server and a slow response." That seemed quite relevant. We also found a change that was committed related to this topic. This partly answered why there were so many PINGs, but it also raised a new question: Why so many stream resets? So we went back to the logs and built up a little more context about the interaction:

2025/09/02 17:33:18 http2: Transport received DATA flags=END_STREAM stream=47 len=0 data=""
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote RST_STREAM stream=47 len=4 ErrCode=CANCEL
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote PING len=8 ping="\x97W\x02\xfa>\xa8\xabi"

The interesting thing here is that the server had sent a DATA frame with the END_STREAM flag set. Per the HTTP/2 stream state machine, the stream should have transitioned to closed when a frame with END_STREAM was processed. The client doesn't need to do anything in this state – sending a RST_STREAM is entirely unnecessary.

A little more digging and noodling and an engineer proclaimed: I noticed that the reset+ping only happens when you call resp.Body.Close()

I believe Go's HTTP library doesn't actually read the response body automatically, but keeps the stream open for you to use until you call resp.Body.Close(), which you can do at any point you like.

The hilarious thing in our example was that there wasn't actually any HTTP body to read. From the earlier example: received DATA flags=END_STREAM stream=47 len=0 data="".

Science and engineering are at times weird and counterintuitive. We decided to tweak our client to read the (absent) body via io.Copy(io.Discard, resp.Body) before closing it. 

Sure enough, this immediately stopped the client sending both a useless RST_STREAM and, by association, a PING frame. 

Mystery solved?

To prove we had fixed the root cause, the production client was updated with a similar fix. A few hours later, all the ENHANCE_YOUR_CALM closures were eliminated.

It’s worth noting that in some situations, ensuring the response body is always read can sometimes be unintuitive in Go. For example, at first glance it appears that the response body will always be read in the following example:

resp, err := http.DefaultClient.Do(req)
if err != nil {
	return err
}
defer resp.Body.Close()

if err := json.NewDecoder(resp.Body).Decode(&respBody); err != nil {
	return err
}

However, json.Decoder stops reading as soon as it finds a complete JSON document or errors. If the response body contains multiple JSON documents or invalid JSON, then the entire response body may still not be read.

Therefore, in our clients, we’ve started replacing defer response.Body.Close() with the following pattern to ensure that response bodies are always fully read:

resp, err := http.DefaultClient.Do(req)
if err != nil {
	return err
}
defer func() {
	io.Copy(io.Discard, resp.Body)
	resp.Body.Close()
}()

if err := json.NewDecoder(resp.Body).Decode(&respBody); err != nil {
	return err
}

HTTP/2 is a protocol with several features. Many implementations have implemented hardening to protect themselves from misuse of features, which can trigger a connection to be closed. The recommended error code for closing connections in such conditions is ENHANCE_YOUR_CALM. There are numerous HTTP/2 implementations and APIs, which may drive the use of HTTP/2 features in unexpected ways that could appear like attacks.

If you have an HTTP/2 client that encounters closures with ENHANCE_YOUR_CALM, we recommend that you try to establish ground truth with packet captures (including TLS decryption keys via mechanisms like SSLKEYLOGFILE) and/or detailed trace logging. Look for patterns of frequent or repeated frames that might be similar to malicious traffic. Adjusting your client may help avoid it getting misclassified as an attacker.

If you use Go, we recommend always reading HTTP/2 response bodies (even if empty) in order to avoid sending unnecessary RST_STREAM and PING frames. This is especially important if you use a single connection for multiple requests, which can cause a high frequency of these frames.

This was also a great reminder of the advantages of dogfooding our own products within our internal services. When we run into issues like this one, our learnings can benefit our customers with similar setups.

_{One of the several alerts fogos.pt received related to the DDoS attack}

What started in 2015 as a late-night side project with friends around a dinner table in Aveiro has grown into a critical public resource. During wildfires, the site is where firefighters, journalists, citizens, and even government agencies go to understand what’s happening on the ground. Over the years, fogos.pt has evolved from parsing PDFs into visual maps to a full-featured app and website with historical data, weather overlays, and more. It’s also part of Project Galileo, Cloudflare’s initiative to protect vulnerable but important public interest sites at no cost.

Wildfires are not just a Portuguese challenge. They are frequent across southern Europe (Spain, Greece, currently also under alert), California, Australia, and in Canada, which in 2023 faced record-setting fires. In all these cases, reliable information can be crucial, sometimes life-saving. Other organizations offering similar public services can also apply to join Project Galileo to receive protection and handle heavy traffic.

Fogos.pt began with a simple question: why was fire data only available in hard-to-read PDF documents? João and a group of friends, including volunteer firefighters, decided to build something better. They pulled the data, geolocated the fire reports, and visualized them on a map.

Soon, thousands of people were using it. Then tens of thousands. Today, fogos.pt is integrated into official communications, including mentions from the Portuguese government on social media and direct links from the national wildfire information portal (SGIFR.gov.pt).

In 2018, fogos.pt formally joined forces with VOST Portugal, a digital volunteer organization that was early on also part of our Project Galileo — whose story was also featured in an earlier case study. João Pina is also a co-founder of VOSTPT. Together, they created a complementary model: fogos.pt provides data and the platform; VOSTPT validates and communicates it to the public in real-time during emergencies.

It’s an operation run entirely by volunteers, with no funding, no formal team — just passion, and the help of partners.

_{Homepage of fogos.pt on August 20, 2025, highlighting a major wildfire near Piódão in central Portugal.}

On July 31 and August 1, 2025, two Distributed Denial of Service (DDoS) attacks targeted fogos.pt. Cloudflare automatically detected and mitigated both attacks.

July 31 attack: • Duration: 7 minutes • Peak: 33,000 requests per second at 11:27 UTC • Bandwidth: 1.7 Gbps (Max) How the attack looks like in requests per second:

August 1 attack: • Duration: 5 minutes • Peak: 31,000 requests per second at 10:24 UTC • Bandwidth: 849 Mbps (Max) How the attack looks like in requests per second from our perspective:

By Cloudflare’s standards, these were small. For comparison, last year we mitigated an attack exceeding 700,000 requests per second against a high-profile US election campaign site. But for an civic project like fogos.pt, even tens of thousands of requests per second — if unprotected — can be enough to take services offline at the worst possible time.

Attackers typically use three main methods for DDoS attacks:

• IoT devices: hacked cameras, routers, or smart gadgets sending traffic.

• Proxies: open or misconfigured servers, residential proxy networks, or anonymity tools that hide attackers’ IPs.

• Cloud machines: compromised or rented servers from cloud providers.

The July 31 attack likely relied on open proxies, with much of the traffic arriving unencrypted (a common sign of proxy-based attacks). The August 1 attack, in contrast, came largely from cloud machines, matching patterns we see from botnets that exploit cloud infrastructure.

These attacks were blocked without disruption. Cloudflare’s autonomous mitigation systems kicked in, and email alerts were automatically sent to João and the team. No downtime, no manual intervention required.

Fogos.pt has used Cloudflare’s free services since the beginning, starting with DNS and gradually expanding to DDoS mitigation, caching, rate limiting, and more. The site joined Project Galileo, which protects journalists, human rights defenders, and public service projects, to get stronger, upgraded features and service at no cost.

“Without Cloudflare, the site would have gone down many times during fire season,” says João Pina. “We use almost every product — but protection against attacks is critical.”

_{August 11, 2025, detail the area of interest of a wildfire in central Portugal.} 

Traffic to fogos.pt surges when wildfires hit the news or get mentioned by authorities. These spikes can bring tens of thousands of visitors per day. And as attention grows, so does the risk. Attacks can be used to silence or disrupt critical services, or simply as distractions for more malicious activity. In August 2025, the site often had close to 60,000 people browsing at the same time, with around 40,000 being the norm across the web and app services.

In just two weeks (with an August 15 peak of almost 70 million requests), fogos.pt handled over 550 million requests (more than 25 million per day) 9 TB of data transfer, nearly 100 million page views, 15 million visits, and 240 million API calls. A massive load for a volunteer-run project, as the next screenshot from the fogos.pt team shows:

In a time when timely wildfire updates can mean the difference between safety and danger, keeping the site online is essential. 

Fogos.pt is a reminder of what’s possible when public service meets technology, and why we launched Project Galileo: to protect the digital infrastructure that keeps people informed and safe. Built with no formal funding or full-time team, it runs on volunteers, partners, and a shared sense of purpose, an authenticity that João Pina believes is why it works, and why it matters.

And while this story is about Portugal, wildfires are a global challenge. Other organizations providing critical public services can also apply to join Project Galileo and receive this protection.

From a dinner-table idea by an engineer to critical national infrastructure, fogos.pt shows the Internet at its best. Cloudflare is proud to help protect it.

On August 13, security researchers at Tel Aviv University disclosed a new HTTP/2 denial-of-service (DoS) vulnerability that they are calling MadeYouReset (CVE-2025-8671). This vulnerability exists in a limited number of unpatched HTTP/2 server implementations that do not accurately track use of server-sent stream resets, which can lead to resource consumption. If you’re using Cloudflare for HTTP DDoS mitigation, you’re already protected from MadeYouReset.

Cloudflare was informed of this vulnerability in May through a coordinated disclosure process, and we were able to confirm that our systems were not susceptible. We foresaw this sort of attack while mitigating the "Netflix vulnerabilities" in 2019, and added even stronger defenses in response to Rapid Reset (CVE-2023-44487) in 2023. MadeYouReset and Rapid Reset are two conceptually similar attacks that exploit a fundamental feature within the HTTP/2 specification (RFC 9113): stream resets. In the HTTP/2 protocol, a client initiates a bidirectional stream that carries an HTTP request/response exchange, represented as frames sent between the client and server. Typically, HEADERS and DATA frames are used for a complete exchange.  Endpoints can use the RST_STREAM frame to prematurely terminate a stream, essentially cancelling operations and signalling that it won’t process any more request or response data. Furthermore, HTTP/2 requires that RST_STREAM is sent when there are protocol errors related to the stream. For example, section 6.1 of RFC 9113 requires that when a DATA frame is received under the wrong circumstances, "...the recipient MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED". 

The vulnerability exploited by both MadeYouReset and Rapid Reset lies in the potential for malicious actors to abuse this stream reset mechanism. By repeatedly causing stream resets, attackers can overwhelm a server's resources. While the server is attempting to process and respond to a multitude of requests, the rapid succession of resets forces it to expend computational effort on starting and then immediately discarding these operations. This can lead to resource exhaustion and impact the availability of the targeted server for legitimate users; as described previously, the main difference between the two attacks is that Rapid Reset exploits client-sent resets, while MadeYouReset exploits server-sent resets. It works by using a client to persuade a server into resetting streams via intentionally sending frames that trigger protocol violations, which in turn trigger stream errors.

RFC 9113 details a number of denial-of-service considerations. Fundamentally, the protocol provides many features with legitimate uses that can be exploited by attackers with nefarious intent. Implementations are advised to harden themselves: "An endpoint that doesn't monitor use of these features exposes itself to a risk of denial of service. Implementations SHOULD track the use of these features and set limits on their use."

Fortunately, the MadeYouReset vulnerability only impacts a relatively small number of HTTP/2 implementations. In most major HTTP/2 implementations already in widespread use today, the proactive measures taken to implement RFC 9113 guidance and counter Rapid Reset in 2023 have also provided substantial protection against MadeYouReset, limiting its potential impact and preventing a similarly disruptive event.

A note about Cloudflare’s Pingora and its users: Our open-sourced Pingora framework uses the popular Rust-language h2 library for its HTTP/2 support. Versions of h2 prior to 0.4.11 were potentially susceptible to MadeYouReset. Users of Pingora can patch their applications by updating their h2 crate version using the cargo update command. Pingora does not itself terminate inbound HTTP connections to Cloudflare’s network, meaning this vulnerability could not be exploited against Cloudflare’s infrastructure.

We would like to credit researchers Gal Bar Nahum, Anat Bremler-Barr, and Yaniv Harel of Tel Aviv University for discovering this vulnerability and thank them for their leadership in the coordinated disclosure process. Cloudflare always encourages security researchers to submit vulnerabilities like this to our HackerOne Bug Bounty program.

June was the busiest month for DDoS attacks in 2025 Q2, accounting for nearly 38% of all observed activity. One notable target was an independent Eastern European news outlet protected by Cloudflare, which reported being attacked following its coverage of a local Pride parade during LGBTQ Pride Month.

• DDoS attacks continue to break records. During 2025 Q2, Cloudflare automatically blocked the largest ever reported DDoS attacks, peaking at 7.3 terabits per second (Tbps) and 4.8 billion packets per second (Bpps).

• Overall, in 2025 Q2, hyper-volumetric DDoS attacks skyrocketed. Cloudflare blocked over 6,500 hyper-volumetric DDoS attacks, an average of 71 per day. 

• Although the overall number of DDoS attacks dropped compared to the previous quarter — which saw an unprecedented surge driven by a large-scale campaign targeting Cloudflare’s network and critical Internet infrastructure protected by Cloudflare — the number of attacks in 2025 Q2 were still 44% higher than in 2024 Q2. Critical infrastructure continues to face sustained pressure, with the Telecommunications, Service Providers, and Carriers sector jumping again to the top as the most targeted industry.

All the attacks in this report were automatically detected and 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 an interactive version of this report where you can drill down further. Radar also offers a free API for those interested in investigating Internet trends. You can also learn more about the methodologies used in preparing these reports.

In 2025 Q2, Cloudflare mitigated 7.3 million DDoS attacks — down sharply from 20.5 million in Q1, when an 18-day campaign against Cloudflare’s own and other critical infrastructure protected by Cloudflare, drove 13.5 million of those attacks. 

^{DDoS attacks by quarter}

We’ve just crossed halfway through 2025, and so far Cloudflare has already blocked 27.8 million DDoS attacks, equivalent to 130% of all the DDoS attacks we blocked in the full calendar year 2024.

^{DDoS attacks by year}

Breaking it down further, Layer 3/Layer 4 (L3/4) DDoS attacks plunged 81% quarter-over-quarter to 3.2 million, while HTTP DDoS attacks rose 9% to 4.1 million. Year-over-year changes remain elevated. Overall attacks were 44% higher than 2024 Q2, with HTTP DDoS attacks seeing the largest increase of 129% YoY.

^{DDoS attacks by month}

In 2025 Q2, Cloudflare blocked over 6,500 hyper-volumetric DDoS attacks, averaging 71 hyper-volumetric attacks per day. Hyper-volumetric attacks include L3/4 DDoS attacks exceeding 1 Bpps or 1 Tbps, and HTTP DDoS attacks exceeding 1 million requests per second (Mrps).

The number of hyper-volumetric DDoS attacks exceeding 100 million packets per second (pps) surged by 592% compared to the previous quarter, and the number exceeding 1 billion pps and 1 terabits per second (Tbps) doubled compared to the previous quarter. The number of HTTP DDoS attacks exceeding 1 million rps (rps) remained the same at around 20 million in total, an average of almost 220,000 attacks every day.

^{Hyper-volumetric DDoS attacks in 2025 Q2}

When asked who was behind the DDoS attacks they experienced in 2025 Q2, the majority (71%) of respondents said they didn’t know who attacked them. Of the remaining 29% of respondents that claimed to have identified the threat actor, 63% pointed to competitors, a pattern especially common in the Gaming, Gambling and Crypto industries. Another 21% attributed the attack to state-level or state-sponsored actors, while 5% each said they’d inadvertently attacked themselves (self-DDoS), were targeted by extortionists, or suffered an assault from disgruntled customers/users.

^{Top threat actors reported in 2025 Q2}

The percentage of attacked Cloudflare customers that reported being targeted by a Ransom DDoS attack or that were threatened increased by 68% compared to the previous quarter, and by 6% compared to the same quarter in 2024. 

^{Ransom DDoS attacks by quarter 2025 Q2}

Diving deeper, Ransom DDoS attacks soared in June 2025. Around a third of respondents reported being threatened or subjected to Ransom DDoS attacks.

^{Ransom DDoS attacks by month 2025 Q2}

The ranking of the top 10 most attacked locations in 2025 Q2 shifted significantly. China climbed two spots to reclaim first place, Brazil jumped four spots to second place, Germany slipped two spaces to third place, India edged up one to fourth, and South Korea rose four to fifth. Turkey fell four places to sixth, Hong Kong dropped three to seventh, and Vietnam vaulted an astonishing fifteen spots into eighth. Meanwhile, Russia rocketed forty places to ninth, and Azerbaijan surged thirty-one to round out the top ten.

^{The locations most targeted by DDoS attacks for 2025 Q2}

It’s important to note that these attacked locations are determined by the billing country of the Cloudflare customer whose services were targeted — not that those nations themselves are under attack. In other words, a high rank simply means more of our registered customers in that billing jurisdiction were targeted by DDoS traffic, rather than implying direct geopolitical targeting.

The ranking of the top 10 most attacked industries in 2025 Q2 also saw notable movement. Telecommunications, Service Providers and Carriers climbed one spot to claim first place, while the Internet sector jumped two spots to second place. Information Technology & Services held its placement as third most attacked, and Gaming rose one spot to fourth place. Gambling & Casinos slipped four spots to fifth place, and the Banking & Financial Services industry remained in sixth place. Retail inched up one spot to seventh place, and Agriculture made a dramatic 38-place leap into eighth. Computer Software climbed two spots to ninth place, and Government hopped two places to round out the top ten most attacked industries.

^{The top attacked industries of DDoS attacks for 2025 Q2}

The ranking of the top 10 largest sources of DDoS attacks in 2025 Q2 also saw several shifts compared to the previous quarter. Indonesia climbed one spot to claim the first place, Singapore jumped two places to second place, Hong Kong dropped two places to third, Argentina slipped one space as fourth and Ukraine held on as the fifth-largest source of DDoS attacks. Russia surged six spots as the sixth-largest source, followed by Ecuador who jumped seven places. Vietnam inched up one place as the eighth-largest source. The Netherlands moved up four places as the ninth-largest source, and Thailand fell three places as the tenth-largest source of DDoS attacks.

^{The top sources of DDoS attacks for 2025 Q2}

It’s important to note that these “source” rankings reflect where botnet nodes, proxy or VPN endpoints reside — not the actual location of threat actors. For L3/4 DDoS attacks, where IP spoofing is rampant, we geolocate each packet to the Cloudflare data center that first ingested and blocked it, drawing on our presence in over 330 cities for truly granular accuracy.

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).

For the first time in about a year, the German-based Hetzner (AS24940) network dropped from the first place as the largest source of HTTP DDoS attack to the third place. In its place, German-based Drei-K-Tech-GmbH (AS200373), also known as 3xK Tech, jumped 6 places as the number one largest source of HTTP DDoS attacks. The US-based DigitalOcean (AS14061) hopped one spot to the second place.

^{The top 10 ASN sources of HTTP DDoS attacks}

As can be seen in the chart above, 9 out of 10 ASNs listed offer virtual machines (VMs), hosting, or cloud services which indicate the common use of VM-based botnets. These botnets are estimated to be 5,000x stronger than IoT-based botnets. Only ChinaNet Backbone (AS4134) is primarily an ISPs/telecom carriers without significant public VM/cloud offerings.

^{IoT-based botnets versus VM-based botnets}

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, and we’ve already seen great collaboration across the community to take down botnet nodes. This is possible thanks to the threat feed which provides these 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.

With a simple API call, service providers can get a list of offending IPs from within their network. An example response is provided below.

{
  "result": [
    {
      "cidr": "127.0.0.1/32",
      "date": "2024-05-05T00:00:00Z",
      "offense_count": 10000
    },
    // ... other entries ...
  ],
  "success": true,
  "errors": [],
  "messages": []
}

^{Example response from the free ISP DDoS Botnet Threat Feed API}

In Q2 2025, the majority (71%) of HTTP DDoS attacks were launched by known botnets. Rapid detection and blocking of these attacks was possible as a result of operating a massive network and seeing many different types of attacks and botnets. By leveraging real-time threat intelligence, our systems are able to incriminate DDoS botnets very fast, contributing to a more effective mitigation. Even if a DDoS botnet has been incriminated while targeting only one website or IP address, our entire network and customer base is immediately protected against it. This real-time threat intelligence system adapts with botnets as they morph and change nodes.

^{The top HTTP DDoS attack vectors for 2025 Q2}

In Q2 2025, DNS flood attacks were the top L3/4 attack vector accounting for almost a third of all L3/4 DDoS attacks. SYN floods was the second most common attack vector, dipping from 31% in Q1 to 27% in Q2. 

In third place, UDP floods also grew meaningfully, rising from 9% in Q1 to 13% in Q2. RST floods, another form of TCP-based DDoS attacks, accounting for 5% of all L3/4 attacks, was the fourth most common vector. Rounding out the top five, SSDP floods edged into fifth place at 3% despite a decline from 4.3% last quarter, but enough to push the previously prevalent Mirai attacks (which fell from 18% in Q1 to just 2% in Q2) out of the top five altogether.

^{The top L3/4 DDoS attack vectors for 2025 Q2}

Below are details about the top 3 most common L3/4 DDoS attacks. We provide recommendations on how organizations can avoid becoming a reflection and amplification element, and also recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare's customers are protected against these attacks.

• Type: Flood

• How it works: A DNS flood aims to overwhelm a DNS server with a high volume of DNS queries—either valid, random, or malformed—to exhaust CPU, memory, or bandwidth. Unlike amplification attacks, this is a direct flood aimed at degrading performance or causing outages, often over UDP port 53, but sometimes over TCP as well (especially for DNS-over-TCP or DNSSEC-enabled zones). Learn more about DNS attacks.

• How to defend against the attack: Use Cloudflare DNS as primary or secondary, Cloudflare DNS Firewall and/or Cloudflare Magic Transit to absorb and mitigate query floods before they reach your origin. Cloudflare’s global network handles tens of millions of DNS queries per second with built-in DDoS filtering and query caching, blocking malformed or excessive traffic while answering legitimate requests.

• How to avoid unintended impact: Avoid blocking all DNS traffic or disabling UDP port 53, which would break normal resolution. Rely on Cloudflare’s DNS-specific protection such as the Advanced DNS Protection system, and deploy DNSSEC-aware protection to handle TCP-based query floods safely.

• Type: Flood

• How it works: In a SYN flood, threat actors send a large volume of TCP SYN packets—often with spoofed IP addresses—to initiate connections that are never completed. This leaves the target system with half-open connections, consuming memory and connection tracking resources, potentially exhausting server limits and preventing real clients from connecting. Learn more about SYN attacks.

• How to defend against the attack: Use Cloudflare Magic Transit to intercept and mitigate TCP SYN floods at the edge. Cloudflare leverages SYN cookies, connection tracking, and behavioral analysis to distinguish real clients from spoofed or malicious sources, ensuring legitimate TCP connections are completed successfully. Using Cloudflare’s CDN/WAF services or Cloudflare Spectrum which are both reverse-proxy services for HTTP or TCP, respectively. Using a reverse-proxy basically eliminates the possible impact of TCP-based DDoS attacks.

• How to avoid unintended impact: Blocking all SYN traffic or applying aggressive timeouts can block real users. Instead, rely on Cloudflare’s Advanced TCP protection system, which uses SYN rate shaping, anomaly detection, and spoofed-packet filtering to mitigate attacks without affecting genuine client connections.

• Type: Flood

• How it works: A high volume of UDP packets is sent to random or specific ports on the target IP address(es). It may attempt to saturate the Internet link or overwhelm its in-line appliances with more packets than it can handle in order to create disruption or an outage. Learn more about UDP attacks.

• How to defend against the attack: Deploy cloud-based volumetric DDoS protection that can fingerprint attack traffic in real-time such as Cloudflare Magic Transit or Cloudflare Spectrum, apply smart rate-limiting on UDP traffic, and drop unwanted UDP traffic altogether with the Magic Firewall.

• How to avoid unintended impact: Aggressive filtering may disrupt legitimate UDP services such as VoIP, video conferencing, or online games. Apply thresholds carefully.

Among emerging L3/4 DDoS threats in 2025 Q2, Teeworlds flood saw the biggest spike. These attacks jumped 385% QoQ, followed by the RIPv1 flood, which surged 296%. RDP floods climbed by 173%, and Demon Bot floods increased by 149%. Even the venerable VxWorks flood made a comeback, rising 71% quarter-over-quarter. These dramatic upticks highlight threat actors’ ongoing experimentation with lesser-known and legacy protocols to evade standard defenses.

^{The top emerging threats for 2025 Q2}

Below are details about the emerging threats for 2025 Q2, mostly recycling of very old attack vectors. We provide recommendations on how organizations can avoid becoming a reflection and amplification element, and also recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare's customers are protected against these attacks.

• Type: Flood

• How it works: Teeworlds is a fast-paced, open-source 2D multiplayer shooter game that uses a custom UDP-based protocol for real-time gameplay. Threat actors flood the target’s game server with spoofed or excessive UDP packets that mimic in-game actions or connection attempts. This can overwhelm server resources and cause lag or outages.

• How to defend against the attack: Use Cloudflare Spectrum or Cloudflare Magic Transit to protect the servers. Cloudflare automatically detects and mitigates these types of attacks using real-time fingerprinting, blocking attack traffic while allowing real players through. Magic Transit also provides a packet-level firewall capability, the Magic Firewall which can be used to craft custom protection.

• How to avoid unintended impact: When crafting custom rules, avoid blocking or aggressively rate-limiting UDP port 8303 directly as it can disrupt overall gameplay. Instead, rely on intelligent detection and mitigation services to avoid affecting legitimate users.

^{Teeworlds Screenshot Jungle. Source: Wikipedia}

• Type: Reflection + (Low) Amplification

• How it works: Exploits the Routing Information protocol version 1 (RIPv1), an old unauthenticated distance-vector routing protocol that uses UDP/520. Threat actors send spoofed routing updates to flood or confuse networks.

• How to prevent becoming a reflection / amplification element: Disable RIPv1 on routers. Use RIPv2 with authentication where routing is needed.

• How to defend against the attack: Block inbound UDP/520 from untrusted networks. Monitor for unexpected routing updates.

• How to avoid unintended impact: RIPv1 is mostly obsolete; disabling it is generally safe. If legacy systems rely on it, validate routing behavior before changes.

• Type: Reflection + Amplification

• How it works: The Remote Desktop Protocol (RDP) is used for remote access to Windows systems and typically runs over TCP port 3389. In some misconfigured or legacy setups, RDP can respond to unauthenticated connection attempts, making it possible to abuse for reflection or amplification. Threat actors send spoofed RDP initiation packets to exposed servers, causing them to reply to a victim, generating high volumes of unwanted traffic.

• How to defend against the attack: Use Cloudflare Magic Transit to protect your network infrastructure. Magic Transit provides L3/L4 DDoS protection, filtering out spoofed or malformed RDP traffic before it reaches your origin. For targeted application-layer abuse, Cloudflare Gateway or Zero Trust Network Access (ZTNA) can help secure remote desktop access behind authenticated tunnels.

• How to avoid unintended impact: Do not block TCP/3389 globally if RDP is actively used. Instead, restrict RDP access to known IPs or internal networks, or use Cloudflare Tunnel with Zero Trust Network Access (ZTNA) to remove public exposure altogether while maintaining secure access for legitimate users.

• Type: Botnet-based Flood

• How it works: DemonBot is a malware strain that infects Linux-based systems—particularly unsecured IoT devices—via open ports or weak credentials. Once infected, devices become part of a botnet that can launch high-volume UDP, TCP, and application-layer floods. Attacks are typically command-and-control (C2) driven and can generate significant volumetric traffic, often targeting gaming, hosting, or enterprise services. To avoid infection, leverage antivirus software and domain filtering. 

• How to defend against the attack: Use Cloudflare Magic Transit to absorb and filter large-scale network-layer floods before they reach your infrastructure. Cloudflare’s real-time traffic analysis and signature-based detection neutralize traffic originating from DemonBot-infected devices. For application-layer services, Cloudflare DDoS protection and WAF can mitigate targeted HTTP floods and connection abuse.

• How to avoid unintended impact: Instead of broadly blocking traffic types or ports, rely on Cloudflare’s adaptive mitigation to distinguish between legitimate users and botnet traffic. Combine with IP reputation filtering, geo-blocking, and rate limiting to reduce false positives and maintain service availability.

• Type: Flood (IoT-based)

• How it works: VxWorks is a real-time operating system (RTOS) used in millions of embedded and IoT devices (e.g., routers, industrial controllers). Devices running outdated or misconfigured versions of VxWorks can be compromised and used to launch DDoS attacks. Once infected—often via public exploits or weak credentials—they send high volumes of UDP, TCP, or ICMP traffic to overwhelm targets, similar to traditional IoT botnets.

• How to defend against the attack: Deploy Cloudflare Magic Transit to block volumetric traffic at the network edge. Cloudflare uses real-time fingerprinting and  proprietary heuristics to identify traffic from compromised VxWorks devices and mitigate it in real-time. For application services, Cloudflare’s DDoS mitigation and Gateway services provide additional protection against protocol-level abuse.

• How to avoid unintended impact: Avoid over-blocking UDP or ICMP traffic, as it may disrupt legitimate diagnostics or real-time services. Instead, use Cloudflare’s intelligent filtering, rate limiting, and geo/IP reputation tools to safely mitigate attacks while avoiding impact to legitimate traffic.

^{Cloudflare’s real-time fingerprint generation flow}

Most DDoS attacks are small and short. In 2025 Q2, 94% of L3/4 DDoS attacks didn’t exceed 500 Mbps. Similarly, around 85% of L3/4 DDoS attacks didn’t exceed 50,000 pps. The majority of HTTP DDoS attacks are also small, 65% stay below 50K rps. “Small”, though, is a relative term.

An average modern server typically refers to a general-purpose physical or virtual machine with around 4–8 CPU cores (e.g. Intel Xeon Silver), 16–64 GB RAM, and a 1 Gbps NIC, running a Linux OS like Ubuntu or CentOS with NGINX or similar software. This setup can handle ~100,000–500,000 pps, up to ~940 Mbps throughput, and around 10,000–100,000 rps for static content or 500–1,000 rps for database-backed dynamic applications, depending on tuning and workload.

Assuming the server is unprotected by a cloud DDoS protection service, if it’s targeted by “small” DDoS attacks during peak time traffic rates, it is very likely that the server won’t be able to handle it. Even “small” DDoS attacks can cause significant impact to unprotected servers.

^{DDoS attacks size and duration in 2025 Q2}

While the majority of DDoS attacks are small, hyper-volumetric DDoS attacks are increasing in size and frequency. 6 out of every 100 HTTP DDoS attacks exceed 1M rps, and 5 out of every 10,000 L3/4 DDoS attacks exceed 1 Tbps — a 1,150% QoQ increase.

^{The largest attack in the world: 7.3 Tbps}

Most DDoS attacks are short in duration, even the largest and most intense ones. Threat actors often rely on brief bursts of concentrated traffic—sometimes lasting as little as 45 seconds as seen with the monumental 7.3 Tbps DDoS attack — in an attempt to avoid detection, overwhelm targets and cause maximum disruption before defenses can fully activate. This tactic of short, high-intensity bursts makes detection and mitigation more challenging and underscores the need for always-on, real-time protection. Thankfully, Cloudflare’s autonomous DDoS defenses kick in immediately.

At Cloudflare, we’re committed to helping build a better Internet. A part of that mission is offering free, unmetered DDoS protection regardless of size, duration and quantity. We don’t just defend against DDoS attacks. The best defense is a good offense, and using our free ISP Botnet Threat Feed, we contribute to botnet takedowns. 

While many still adopt protection reactively or rely on outdated solutions, our data shows proactive, always-on security is far more effective. Powered by a global network with 388 Tbps capacity across 330+ cities, we provide automated, in-line, battle-proven defense against all types of DDoS attacks.

^{New world record: 7.3 Tbps DDoS attack autonomously blocked by Cloudflare}

The attack targeted a Cloudflare customer, a hosting provider, that uses Magic Transit to defend their IP network. Hosting providers and critical Internet infrastructure have increasingly become targets of DDoS attacks, as we reported in our latest DDoS threat report. Pictured below is an attack campaign from January and February 2025 that blasted over 13.5 million DDoS attacks against Cloudflare’s infrastructure and hosting providers protected by Cloudflare.

^{DDoS attack campaign target Cloudflare infrastructure and hosting providers protected by Cloudflare}

Let's start with some stats, and then we’ll dive into how our systems detected and mitigated this attack.

37.4 terabytes is not a staggering figure in today’s scales, but blasting 37.4 terabytes in just 45 seconds is. It’s the equivalent to flooding your network with over 9,350 full-length HD movies, or streaming 7,480 hours of high-definition video nonstop (that’s nearly a year of back-to-back binge-watching) in just 45 seconds. If it were music, you’d be downloading about 9.35 million songs in under a minute, enough to keep a listener busy for 57 years straight. Think of snapping 12.5 million high-resolution photos on your smartphone and never running out of storage—even if you took one shot every day, you’d be clicking away for 4,000 years — but in 45 seconds. 

^{The record-breaking 7.3 Tbps DDoS attack delivered 37.4 TB in 45 seconds}

The attack carpet-bombed an average of 21,925 destination ports of a single IP address owned and used by our customer, with a peak of 34,517 destination ports per second. The attack also originated from a similar distribution of source ports. 

^{Distribution of destination ports}

The 7.3 Tbps attack was a multivector DDoS attack. Around 99.996% of the attack traffic was categorized as UDP floods. However, the remaining 0.004%, which accounted for 1.3 GB of the attack traffic, were identified as QOTD reflection attacks, Echo reflection attack, NTP reflection attack, Mirai UDP flood attack, Portmap flood, and RIPv1 amplification attacks.

^{The attack vectors other than UDP floods}

Below are details about the various attack vectors seen in this attack, how organizations can avoid becoming a reflection and amplification participant, and recommendations on how to defend against these attacks whilst avoiding impact to legitimate traffic. Cloudflare's customers are protected against these attacks.

• Type: Flood

• How it works: A high volume of UDP packets is sent to random or specific ports on the target IP address(es). It may attempt to saturate the Internet link or overwhelm its in-line appliances with more packets than it can handle.

• How to defend against the attack: Deploy cloud-based volumetric DDoS protection, apply smart rate-limiting on UDP traffic, and drop unwanted UDP traffic altogether.

• How to avoid unintended impact: Aggressive filtering may disrupt legitimate UDP services such as VoIP, video conferencing, or online games. Apply thresholds carefully.

• Type: Reflection + Amplification

• How it works: Abuses the Quote of the Day (QOTD) Protocol, which listens on UDP port 17 and responds with a short quote or message. Attackers send QOTD requests to exposed servers from a spoofed IP address, causing amplified responses to flood the victim.

• How to prevent becoming a reflection / amplification element: Disable the QOTD service and block UDP/17 on all servers and firewalls.

• How to defend against the attack: Block inbound UDP/17. Drop abnormal small-packet UDP request spikes.

• How to avoid unintended impact: QOTD is an obsolete diagnostic/debugging protocol and is not used by modern applications. Disabling it should not have any negative effect on legitimate services.

• Type: Reflection + Amplification

• How it works: Exploits the Echo protocol (UDP/TCP port 7), which replies with the same data it receives. Attackers spoof the victim’s IP address, causing devices to reflect the data back, amplifying the attack.

• How to prevent becoming a reflection / amplification element: Disable the Echo service on all devices. Block UDP/TCP port 7 at the edge.

• How to defend against the attack: Disable the Echo service and block TCP/UDP port 7 at the network perimeter.

• How to avoid unintended impact: Echo is an obsolete diagnostic tool; disabling or blocking it has no negative effect on modern systems.

• Type: Reflection + Amplification

• How it works: Abuses the Network Time Protocol (NTP), used to sync clocks over the Internet. Attackers exploit the monlist command on old NTP servers (UDP/123) which returns a large list of recent connections. Spoofed requests cause amplified reflections.

• How to prevent becoming a reflection / amplification element: Upgrade or configure NTP servers to disable monlist. Restrict NTP queries to trusted IP addresses only.

• How to defend against the attack: Disable the monlist command, update NTP software, and filter or rate-limit UDP/123 traffic.

• How to avoid unintended impact: Disabling monlist has no effect on time synchronization. However, filtering or blocking UDP/123 could affect time syncing if done too broadly — ensure only untrusted or external sources are blocked.

• Type: Flood

• How it works: The Mirai botnet, made up of compromised IoT devices, floods victims using random or service-specific UDP packets (e.g., DNS, game services).

• How to prevent becoming part of the botnet: Secure your IoT devices, change default passwords, upgrade to the latest firmware versions, and follow IoT security best practices to avoid becoming part of the botnet. When possible, monitor outbound traffic to detect irregularities.

• How to defend against the attack: Deploy cloud-based volumetric DDoS protection and rate-limiting for UDP traffic.

• How to avoid unintended impact: First, understand your network and the type of traffic that you receive, specifically the protocols, their sources and their destinations. Identify services that run over UDP that you want to avoid impacting. Once you have identified those, you can apply rate-limiting in a way that excludes those end points, or takes into account your regular traffic levels. Otherwise, aggressively rate-limiting UDP traffic can impact your legitimate traffic and impact services that run over UDP such as VoIP calls and VPN traffic.

• Type: Reflection + Amplification

• How it works: Targets the Portmapper service (UDP/111) used by Remote Procedure Call (RPC)-based applications to identify available services. Spoofed requests result in reflected responses.

• How to prevent becoming a reflection / amplification element: Disable the Portmapper service if not required. If needed internally, restrict it to trusted IP addresses only.

• How to defend against the attack: Disable the Portmapper service if not needed, block inbound UDP/111 traffic. Use Access Control Lists (ACLs) or firewalls to restrict access to known RPC services.

• How to avoid unintended impact: Disabling Portmapper may disrupt applications relying on RPC (e.g., Network File System protocol). Validate service dependencies before removal.

• Type: Reflection + (Low) Amplification

• How it works: Exploits the Routing Information protocol version 1 (RIPv1), an old unauthenticated distance-vector routing protocol that uses UDP/520. Attackers send spoofed routing updates to flood or confuse networks.

• How to prevent becoming a reflection / amplification element: Disable RIPv1 on routers. Use RIPv2 with authentication where routing is needed.

• How to defend against the attack: Block inbound UDP/520 from untrusted networks. Monitor for unexpected routing updates.

• How to avoid unintended impact: RIPv1 is mostly obsolete; disabling it is generally safe. If legacy systems rely on it, validate routing behavior before changes.

All recommendations here should be taken into consideration with the context and behavior of each unique network or application to avoid any unintended impact to legitimate traffic.

The attack originated from over 122,145 source IP addresses spanning 5,433 Autonomous Systems (AS) across 161 countries. 

Almost half of the attack traffic originated from Brazil and Vietnam, with approximately a quarter each. Another third, in aggregate, originated from Taiwan, China, Indonesia, Ukraine, Ecuador, Thailand, the United States, and Saudi Arabia.

^{Top 10 source countries of the attack traffic}

The average number of unique source IP addresses per second was 26,855 with a peak of 45,097.  

^{Distribution of unique source IP addresses}

The attack originated from 5,433 different networks (ASes). Telefonica Brazil (AS27699) accounted for the largest portion of the DDoS attack traffic, responsible for 10.5% of the total. Viettel Group (AS7552) follows closely with 9.8%, while China Unicom (AS4837) and Chunghwa Telecom (AS3462) contributed 3.9% and 2.9% respectively. China Telecom (AS4134) accounted for 2.8% of the traffic. The remaining ASNs in the top 10, including Claro NXT (AS28573), VNPT Corp (AS45899), UFINET Panama (AS52468), STC (AS25019), and FPT Telecom Company (AS18403), each contributed between 1.3% and 1.8% of the total DDoS attack traffic.

Top 10 source autonomous systems

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 feed via API.

The attacked IP address was advertised from Cloudflare’s network using global anycast. This means that the attack packets that targeted the IP were routed to the closest Cloudflare data center. Using global anycast allows us to spread the attack traffic and use its distributed nature against it, enabling us to mitigate close to the botnet nodes and continue serving users from the data centers closest to them. In the case of this attack, it was detected and mitigated in 477 data centers across 293 locations around the world. In high-traffic locations, we have presence in multiple data centers. 

The Cloudflare global network runs every service in every data center. This includes our DDoS detection and mitigation systems. This means that attacks can be detected and mitigated fully autonomously, regardless of where they originate from. 

When a packet enters our data center, it is intelligently load-balanced to an available server. We then sample packets directly from within the depths of the Linux kernel, from the eXpress Data Path (XDP) using an extended Berkley Packer Filter (eBPF) program to route packet samples to the user space where we run the analysis.

Our system analyzes the packet samples to identify suspicious patterns based on our unique heuristic engine named dosd (denial of service daemon). Dosd looks for patterns in the packet samples, such as finding commonality in the packet header fields and looking for packet anomalies, as well as applying other proprietary techniques.

 ^{Flow diagram of the real-time fingerprint generation}

To our customers, this complex fingerprinting system is encapsulated as a user-friendly group of managed rules, the DDoS Protection Managed Rulesets. 

When patterns are detected by dosd, it generates multiple permutations of those fingerprints in order to find the most accurate fingerprint that will have the highest mitigation efficacy and accuracy, i.e. to try and surgically match against attack traffic without impacting legitimate traffic. 

^{Diagram of Cloudflare’s DDoS Protection systems} 

We count the various packet samples that match each fingerprint permutation, and using a data streaming algorithm, we bubble up the fingerprint with the most hits. When activation thresholds are exceeded, to avoid false positives, a mitigation rule using the fingerprint syntax is compiled as an eBPF program to drop packets that match the attack pattern. Once the attack ends, the rule times out and is automatically removed.

As we mentioned, each server detects and mitigates attacks fully autonomously — making our network highly efficient, resilient, and fast at blocking attacks. In addition, each server gossips (multicasts) the top fingerprint permutations within a data center, and globally. This sharing of real-time threat intelligence helps improve the mitigation efficacy within a data center and globally. 

Our systems successfully blocked this record-breaking 7.3 Tbps DDoS attack fully autonomously without requiring any human intervention, without triggering any alerts, and without causing any incidents. This demonstrates the effectiveness of our world-leading DDoS protection systems. We built this system as part of our mission to help build a better Internet committed to provide free unmetered DDoS protection.

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.

Below, we review all of these changes and additions to Radar.

Since Cloudflare Radar launched in 2020, it has included both network layer (Layers 3 & 4) and application layer (Layer 7) attack traffic insights on a single Security & Attacks page. Over the last four-plus years, we have evolved some of the existing data sets on the page, as well as adding new ones. As the page has grown and improved over time, it risked becoming unwieldy to navigate, making it hard to find the graphs and data of interest. To help address that, the Security section on Radar now features separate Application Layer and Network Layer pages. The Application Layer page is the default, and includes insights from analysis of HTTP-based malicious and attack traffic. The Network Layer page includes insights from analysis of network and transport layer attacks, as well as observed TCP resets and timeouts. Future security and attack-related data sets will be added to the relevant page. Email Security remains on its own dedicated page.

Radar’s quarterly DDoS threat reports have historically provided insights, aggregated on a quarterly basis, into the top source and target locations of application layer DDoS attacks. A new map and table on Radar’s Application Layer Security page now provide more timely insights, with a global choropleth map showing a geographical distribution of source and target locations, and an accompanying list of the top 20 locations by share of all DDoS requests. Source location attribution continues to rely on the geolocation of the IP address originating the blocked request, while target location remains the billing location of the account that owns the site being attacked. 

Over the first week of March 2025, the United States, Indonesia, and Germany were the top sources of application layer DDoS attacks, together accounting for over 30% of such attacks as shown below. The concentration across the top targeted locations was quite different, with customers from Canada, the United States, and Singapore attracting 56% of application layer DDoS attacks.

In addition to extended visibility into the geographic source of application layer DDoS attacks, we have also added autonomous system (AS)-level visibility. A new treemap view shows the distribution of these attacks by source AS. At a global level, the largest sources include cloud/hosting providers in Germany, the United States, China, and Vietnam.

For a selected country/region, the treemap displays a source AS distribution for attacks observed to be originating from that location. In some, the sources of attack traffic are heavily concentrated in consumer/business network providers, such as in Portugal, shown below. However, in other countries/regions that have a large cloud provider presence, such as Ireland, Singapore, and the United States, ASNs associated with these types of providers are the dominant sources. To that end, Singapore was listed as being among the top sources of application layer DDoS attacks in each of the quarterly DDoS threat reports in 2024. 

Every week, it seems like there’s another headline about a data breach, talking about thousands or millions of usernames and passwords being stolen. Or maybe you get an email from an identity monitoring service that your username and password were found on the “dark web”. (Of course, you’re getting those alerts thanks to a complementary subscription to the service offered as penance from another data breach…)

This credential theft is especially problematic because people often reuse passwords, despite best practices advising the use of strong, unique passwords for each site or application. To help mitigate this risk, starting in 2024, Cloudflare began enabling customers to scan authentication requests for their websites and applications using a privacy-preserving compromised credential checker implementation to detect known-leaked usernames and passwords. Today, we're using aggregated data to display trends in how often these leaked and stolen credentials are observed across Cloudflare's network. (Here, we are defining “leaked credentials” as usernames or passwords being found in a public dataset, or the username and password detected as being similar.)

Leaked credentials detection scans incoming HTTP requests for known authentication patterns from common web apps and any custom detection locations that were configured. The service uses a privacy-preserving compromised credential checking protocol to compare a hash of the detected passwords to hashes of compromised passwords found in databases of leaked credentials. A new Radar graph on the worldwide Application Layer Security page provides visibility into aggregate trends around the detection of leaked credentials in authentication requests. Filterable by authentication requests from human users, bots, or all (human + bot), the graph shows the distribution requests classified as “clean” (no leaked credentials detected) and “compromised” (leaked credentials, as defined above, were used). At a worldwide level, we found that for the first week of March 2025, leaked credentials were used in 64% of all, over 65% of bot, and over 44% of human authorization requests.

This suggests that from a human perspective, password reuse is still a problem, as is users not taking immediate actions to change passwords when notified of a breach. And from a bot perspective, this suggests that attackers know that there is a good chance that leaked credentials for one website or application will enable them to access that same user’s account elsewhere.

As a complement to the leaked credentials data, Radar is also now providing a worldwide view into the share of authentication requests originating from bots. Note that not all of these requests are necessarily malicious — while some may be associated with credential stuffing-style attacks, others may be from automated scripts or other benign applications accessing an authentication endpoint. (Having said that, automated malicious attack request volume far exceeds legitimate automated login attempts.) During the first week of March 2025, we found that over 94% of authentication requests came from bots (were automated), with the balance coming from humans. Over that same period, bot traffic only accounted for 30% of overall requests. So although bots don’t represent a majority of request traffic, authentication requests appear to comprise a significant portion of their activity.

As a reminder, bot traffic describes any non-human Internet traffic, and monitoring bot levels can help spot potential malicious activities. Of course, bots can be helpful too, and Cloudflare maintains a list of verified bots to help keep the Internet healthy. Given the importance of monitoring bot activity, we have launched a new dedicated Bots page in the Traffic section of Cloudflare Radar to support these efforts. For both worldwide and location views over the selected time period, the page shows the distribution of bot (automated) vs. human HTTP requests, as well as a graph showing bot traffic trends. (Our bot score, combining machine learning, heuristics, and other techniques, is used to identify automated requests likely to be coming from bots.) 

Both the 2023 and 2024 Cloudflare Radar Year in Review microsites included a “Bot Traffic Sources” section, showing the locations and networks that Cloudflare determined that the largest shares of automated/likely automated traffic was originating from. However, these traffic shares were published just once a year, aggregating traffic from January through the end of November.

In order to provide a more timely perspective, these insights are now available on the new Radar Bots page. Similar to the new DDoS attacks content discussed above, the worldwide view includes a choropleth map and table illustrating the locations originating the largest shares of all bot traffic. (Note that a similar Traffic Characteristics map and table on the Traffic Overview page ranks locations by the bot traffic share of the location’s total traffic.) Similar to Year in Review data linked above, the United States continues to originate the largest share of bot traffic.

In addition, the worldwide view also breaks out bot traffic share by AS, mirroring the treemap shown in the Year in Review. As we have noted previously, cloud platform providers account for a significant amount of bot traffic.

At a location level, depending on the country/region selected, the top sources of bot traffic may be cloud/hosting providers, consumer/business network providers, or a mix. For instance, France’s distribution is shown below, and four ASNs account for just over half of the country’s bot traffic. Of these ASNs, two (AS16276 and AS12876) belong to cloud/hosting providers, and two (AS3215 and AS12322) belong to network providers.

In addition, the Verified Bots list has been moved to the new Bots page on Radar. The data shown and functionality remains unchanged, and links to the old location will automatically be redirected to the new one.

The Cloudflare dashboard provides customers with specific views of security trends, application and network layer attacks, and bot activity across their sites and applications. While these views are useful at an individual customer level, aggregated views at a worldwide, location, and network level provide a macro-level perspective on trends and activity. These aggregated views available on Cloudflare Radar not only help customers understand how their observations compare to the larger whole, but they also help the industry understand emerging threats that may require action.

The underlying data for the graphs and data discussed above is available via the Radar API (Application Layer, Network Layer, Bots, Leaked Credentials). The data can also be interactively explored in more detail across locations, networks, and time periods using Radar’s Data Explorer and AI Assistant. And as always, Radar and Data Explorer charts and graphs are downloadable for sharing, and embeddable for use in your own blog posts, websites, or dashboards.

If you share our security, attacks, or bots graphs on social media, be sure to tag us: @CloudflareRadar and @1111Resolver (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky). If you have questions or comments, you can reach out to us on social media, or contact us via email.

Since being notified about the vulnerability, we've implemented a mitigation to help secure our infrastructure. According to our analysis, we have fully patched this vulnerability and the amplification vector no longer exists. 

QUIC is an Internet transport protocol that is encrypted by default. It offers equivalent features to TCP (Transmission Control Protocol) and TLS (Transport Layer Security), while using a shorter handshake sequence that helps reduce connection establishment times. QUIC runs over UDP (User Datagram Protocol).

The researchers found that a single client QUIC Initial packet targeting a broadcast IP destination address could trigger a large response of initial packets. This manifested as both a server CPU amplification attack and a reflection amplification attack.

When using TCP and TLS there are two handshake interactions. First, is the TCP 3-way transport handshake. A client sends a SYN packet to a server, it responds with a SYN-ACK to the client, and the client responds with an ACK. This process validates the client IP address. Second, is the TLS security handshake. A client sends a ClientHello to a server, it carries out some cryptographic operations and responds with a ServerHello containing a server certificate. The client verifies the certificate, confirms the handshake and sends application traffic such as an HTTP request.

QUIC follows a similar process, however the sequence is shorter because the transport and security handshake is combined. A client sends an Initial packet containing a ClientHello to a server, it carries out some cryptographic operations and responds with an Initial packet containing a ServerHello with a server certificate. The client verifies the certificate and then sends application data.

The QUIC handshake does not require client IP address validation before starting the security handshake. This means there is a risk that an attacker could spoof a client IP and cause a server to do cryptographic work and send data to a target victim IP (aka a reflection attack). RFC 9000 is careful to describe the risks this poses and provides mechanisms to reduce them (for example, see Sections 8 and 9.3.1). Until a client address is verified, a server employs an anti-amplification limit, sending a maximum of 3x as many bytes as it has received. Furthermore, a server can initiate address validation before engaging in the cryptographic handshake by responding with a Retry packet. The retry mechanism, however, adds an additional round-trip to the QUIC handshake sequence, negating some of its benefits compared to TCP. Real-world QUIC deployments use a range of strategies and heuristics to detect traffic loads and enable different mitigations.

In order to understand how the researchers triggered an amplification attack despite these QUIC guardrails, we first need to dive into how IP broadcast works.

In Internet Protocol version 4 (IPv4) addressing, the final address in any given subnet is a special broadcast IP address used to send packets to every node within the IP address range. Every node that is within the same subnet receives any packet that is sent to the broadcast address, enabling one sender to send a message that can be “heard” by potentially hundreds of adjacent nodes. This behavior is enabled by default in most network-connected systems and is critical for discovery of devices within the same IPv4 network.

The broadcast address by nature poses a risk of DDoS amplification; for every one packet sent, hundreds of nodes have to process the traffic. 

To combat the risk posed by broadcast addresses, by default most routers reject packets originating from outside their IP subnet which are targeted at the broadcast address of networks for which they are locally connected. Broadcast packets are only allowed to be forwarded within the same IP subnet, preventing attacks from the Internet from targeting servers across the world.

The same techniques are not generally applied when a given router is not directly connected to a given subnet. So long as an address is not locally treated as a broadcast address, Border Gateway Protocol (BGP) or other routing protocols will continue to route traffic from external IPs toward the last IPv4 address in a subnet. Essentially, this means a “broadcast address” is only relevant within a local scope of routers and hosts connected together via Ethernet. To routers and hosts across the Internet, a broadcast IP address is routed in the same way as any other IP.

Each Cloudflare server is expected to be capable of serving content from every website on the Cloudflare network. Because our network utilizes Anycast routing, each server necessarily needs to be listening on (and capable of returning traffic from) every Anycast IP address in use on our network.

To do so, we take advantage of the loopback interface on each server. Unlike a physical network interface, all IP addresses within a given IP address range are made available to the host (and will be processed locally by the kernel) when bound to the loopback interface.

The mechanism by which this works is straightforward. In a traditional routing environment, longest prefix matching is employed to select a route. Under longest prefix matching, routes towards more specific blocks of IP addresses (such as 192.0.2.96/29, a range of 8 addresses) will be selected over routes to less specific blocks of IP addresses (such as 192.0.2.0/24, a range of 256 addresses).

While Linux utilizes longest prefix matching, it consults an additional step — the Routing Policy Database (RPDB) — before immediately searching for a match. The RPDB contains a list of routing tables which can contain routing information and their individual priorities. The default RPDB looks like this:

$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Linux will consult each routing table in ascending numerical order to try and find a matching route. Once one is found, the search is terminated and the route immediately used.

If you’ve previously worked with routing rules on Linux, you are likely familiar with the contents of the main table. Contrary to the existence of the table named “default”, “main” generally functions as the default lookup table. It is also the one which contains what we traditionally associate with route table information:

$ ip route show table main
default via 192.0.2.1 dev eth0 onlink
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2

This is, however, not the first routing table that will be consulted for a given lookup. Instead, that task falls to the local table:

$ ip route show table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.0.2.2 dev eth0 proto kernel scope host src 192.0.2.2
broadcast 192.0.2.255 dev eth0 proto kernel scope link src 192.0.2.2

Looking at the table, we see two new types of routes — local and broadcast. As their names would suggest, these routes dictate two distinctly different functions: routes that are handled locally and routes that will result in a packet being broadcast. Local routes provide the desired functionality — any prefix with a local route will have all IP addresses in the range processed by the kernel. Broadcast routes will result in a packet being broadcast to all IP addresses within the given range. Both types of routes are added automatically when an IP address is bound to an interface (and, when a range is bound to the loopback (lo) interface, the range itself will be added as a local route).

Deployments of QUIC are highly dependent on the load-balancing and packet forwarding infrastructure that they sit on top of. Although QUIC’s RFCs describe risks and mitigations, there can still be attack vectors depending on the nature of server deployments. The reporting researchers studied QUIC deployments across the Internet and discovered that sending a QUIC Initial packet to one of Cloudflare’s broadcast addresses triggered a flood of responses. The aggregate amount of response data exceeded the RFC's 3x amplification limit.

Taking a look at the local routing table of an example Cloudflare system, we see a potential culprit:

$ ip route show table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.0.2.2 dev eth0 proto kernel scope host src 192.0.2.2
broadcast 192.0.2.255 dev eth0 proto kernel scope link src 192.0.2.2
local 203.0.113.0 dev lo proto kernel scope host src 203.0.113.0
local 203.0.113.0/24 dev lo proto kernel scope host src 203.0.113.0
broadcast 203.0.113.255 dev lo proto kernel scope link src 203.0.113.0

On this example system, the anycast prefix 203.0.113.0/24 has been bound to the loopback interface (lo) through the use of standard tooling. Acting dutifully under the standards of IPv4, the tooling has assigned both special types of routes — a local one for the IP range itself and a broadcast one for the final address in the range — to the interface.

While traffic to the broadcast address of our router’s directly connected subnet is filtered as expected, broadcast traffic targeting our routed anycast prefixes still arrives at our servers themselves. Normally, broadcast traffic arriving at the loopback interface does little to cause problems. Services bound to a specific port across an entire range will receive data sent to the broadcast address and continue as normal. Unfortunately, this relatively simple trait breaks down when normal expectations are broken.

Cloudflare’s frontend consists of several worker processes, each of which independently binds to the entire anycast range on UDP port 443. In order to enable multiple processes to bind to the same port, we use the SO_REUSEPORT socket option. While SO_REUSEPORT has additional benefits, it also causes traffic sent to the broadcast address to be copied to every listener.

Each individual QUIC server worker operates in isolation. Each one reacted to the same client Initial, duplicating the work on the server side and generating response traffic to the client's IP address. Thus, a single packet could trigger a significant amplification. While specifics will vary by implementation, a typical one-listener-per-core stack (which sends retries in response to presumed timeouts) on a 128-core system could result in 384 replies being generated and sent for each packet sent to the broadcast address.

Although the researchers demonstrated this attack on QUIC, the underlying vulnerability can affect other UDP request/response protocols that use sockets in the same way.

As a communication methodology, broadcast is not generally desirable for anycast prefixes. Thus, the easiest method to mitigate the issue was simply to disable broadcast functionality for the final address in each range.

Ideally, this would be done by modifying our tooling to only add the local routes in the local routing table, skipping the inclusion of the broadcast ones altogether. Unfortunately, the only practical mechanism to do so would involve patching and maintaining our own internal fork of the iproute2 suite, a rather heavy-handed solution for the problem at hand.

Instead, we decided to focus on removing the route itself. Similar to any other route, it can be removed using standard tooling:

$ sudo ip route del 203.0.113.255 table local

To do so at scale, we made a relatively minor change to our deployment system:

  {%- for lo_route in lo_routes %}
    {%- if lo_route.type == "broadcast" %}
        # All broadcast addresses are implicitly ipv4
        {%- do remove_route({
        "dev": "lo",
        "dst": lo_route.dst,
        "type": "broadcast",
        "src": lo_route.src,
        }) %}
    {%- endif %}
  {%- endfor %}

In doing so, we effectively ensure that all broadcast routes attached to the loopback interface are removed, mitigating the risk by ensuring that the specification-defined broadcast address is treated no differently than any other address in the range.

While the vulnerability specifically affected broadcast addresses within our anycast range, it likely expands past our infrastructure. Anyone with infrastructure that meets the relatively narrow criteria (a multi-worker, multi-listener UDP-based service that is bound to all IP addresses on a machine with routable IP prefixes attached in such a way as to expose the broadcast address) will be affected unless mitigations are in place. We encourage network administrators and security professionals to assess their systems for configurations that may present a local amplification attack vector.

January 27 marks the International Holocaust Remembrance Day — a solemn occasion to honor the memory of the six million Jews who perished in the Holocaust, along with countless others who fell victim to the Nazi regime's campaign of hatred and intolerance. This tragic chapter in human history serves as a stark reminder of the catastrophic consequences of prejudice and extremism. 

The United Nations General Assembly designated January 27 — the anniversary of the liberation of Auschwitz-Birkenau —  as International Holocaust Remembrance Day. This year, we commemorate the 80th anniversary of the liberation of this infamous extermination camp.

As the world reflects on this dark period, a troubling resurgence of antisemitism underscores the importance of vigilance. This growing hatred has spilled into the digital realm, with cyberattacks increasingly targeting Jewish and Holocaust remembrance and educational websites — spaces dedicated to preserving historical truth and fostering awareness.

For this reason, here at Cloudflare, we began to publish annual reports covering cyberattacks that target these organizations. These cyberattacks include DDoS attacks as well as bot and application attacks. The insights and trends are based on websites protected by Cloudflare. This is our fourth report, and you can view our previous Holocaust Remembrance Day blogs here.

At Cloudflare, we are proud to support these vital organizations through Project Galileo, an initiative providing free security protections to vulnerable groups worldwide. If you or your organization could benefit from this program, consider applying today to help protect these essential platforms and the invaluable work they do.

^{Project Galileo overview. Source: Cloudflare 2024 Impact Report}

One of the organizations that we protect through Project Galileo is Muzeon, a museum dedicated to preserving Jewish history in Cluj-Napoca, Romania. Muzeon faced significant cyberattacks that impacted their website’s performance and hindered operations before using Cloudflare.

As part of Project Galileo, Muzeon implemented Cloudflare's DDoS mitigation, Web Application Firewall (WAF), Managed DNS, and other services. These measures drastically reduced the attacks and allowed Muzeon to focus on its important mission of storytelling and preserving cultural heritage. 

Cloudflare’s solutions not only protected their digital infrastructure but also freed up time for Muzeon to expand its interactive exhibits, ensuring they could continue sharing their essential work globally. You can read more about this case study here. 

Following the October 7, 2023, Hamas-led attack on Israel, there has been a surge in global antisemitic incidents. In the U.S. alone there have been more than 10,000 antisemitic incidents from October 7, 2023 to September 24, 2024, representing an over 200-percent increase compared to the incidents reported during the same period a year before. As we’ve seen, the digital world is often a mirror to the real world. As a result, it is not surprising that websites dedicated to sharing information about the Holocaust, as well as Jewish memorial and education platforms, are now increasingly being targeted online. 

For the years 2020, 2021, and 2022, the number of cyberthreats targeting Holocaust and Jewish educational and memorial websites protected by Cloudflare was, on average, 736,339 malicious HTTP requests annually.

After the October 7 Hamas-led attack, cyberattacks skyrocketed. In 2023, the amount of blocked HTTP requests surged by 872% to 35.7 million compared to 2022. Most of these cyberattacks occurred after October 7, 2023. 

In 2024, the number of blocked HTTP requests exceeded 47 million — representing a 30% increase compared to 2023. Over 3 out of every 100 HTTP requests towards Holocaust and Jewish memorial and education websites protected by Cloudflare were malicious and blocked. 

^{Cyber threats against Holocaust and Jewish memorial and educational websites by year}

In the fourth quarter of 2023, the volume of malicious requests exceeded 27 million. Throughout the first three quarters of 2024, we saw a gradual decrease in the quantity of malicious requests. But in the fourth quarter of 2024, cyberattacks spiked by 33%, to 36 million requests, following the one-year anniversary of the October 7 assault.

^{Cyber threats against Holocaust and Jewish memorial and educational websites by quarter}

Breaking down the quarters into months, we can see an initial peak in October 2023 after the October 7 Hamas-led attack. The volume of cyberattacks remained elevated during November and December 2023.

Afterward, as we entered 2024, the quantity and percentage of cyberattacks against these websites significantly decreased. In November, over a third (34%) of all requests towards these websites were blocked, with over 36 million requests blocked that month alone.

^{Cyber threats against Holocaust and Jewish memorial and educational websites by month}

On the International Holocaust Remembrance Day, we reflect on the importance of standing against both antisemitism and cyber threats — issues that have escalated since the October 7, 2023, Hamas-led attack. 

At Cloudflare, we are unwavering in our commitment to create a safer, more inclusive Internet. The rise in antisemitism has made it even more critical to protect educational websites and communities from harmful cyber attacks. We invite everyone to join us in this fight. Even with our free plan, we offer strong security and performance, ensuring that vital resources and websites remain safe and accessible. By working together, we can protect the lessons of history and foster a more secure digital world for all.

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.

At Cloudflare, with our presence in over 330 cities and 120 countries and interconnection with 12,500 networks, we’ve witnessed firsthand the digital impact of these elections. From monitoring Internet traffic patterns to mitigating cyberattacks, we’ve observed trends that reveal how elections increasingly play out online. As detailed in our just-published Cloudflare Impact report, we’ve also worked to protect media outlets, political campaigns, and help elections worldwide.

Here’s the map of countries with national elections that took place in 2024, from our elections report.

We’ve been monitoring 2024 elections worldwide on our blog and in the 2024 Election Insights report available on Cloudflare Radar.

In terms of Internet patterns, we’ve observed how cyber activity in 2024 continues to intersect with real-world events. Online attacks are clearly a significant part of elections, even when unsuccessful in disrupting candidates or election-related websites due to strong protections. Additionally, Internet traffic patterns often vary on election day depending on the country, and government-directed Internet shutdowns continue, including ones related to elections. Email activity is also influenced, especially for more popular candidates in “polarized battles.”

Let’s start our review with attacks. 

During 2024, elections saw a rise in DDoS attacks targeting political campaigns, parties, and election infrastructure.

In the United States, over 6 billion malicious requests were blocked between November 1-6. A set of DDoS attacks leading up to Election Day on November 5 targeted one of the campaigns with multiple days of attacks, peaking at 700,000 requests per second and sustaining 8 Gbps during major strikes. Key attack tactics included cache-busting, geodiverse patterns, and randomized user agents.

State and local websites also faced increased threats, with 290 million malicious requests blocked since September under Cloudflare’s Athenian Project. Compared to 2020, attacks in 2024 were far more intense, underscoring the growing need for robust cybersecurity to protect elections from disruption.

In France, DDoS attacks plagued multiple political parties, with peaks reaching 96,000 requests per second (rps) on election day, July 7. Additional details are available in our related blog post.

In the United Kingdom, DDoS attacks targeted political parties, with the most severe incident affecting a campaign website, reaching 156,000 rps shortly after the results were announced on election day. Additional details are available in our related blog post.

During the European parliamentary elections in early June, cyberattacks targeted several political websites around election days. Notably, a significant DDoS attack focused on two politically-related websites in the Netherlands on June 5–6 (with June 6 being election day), peaking at 73,000 rps.

In Romania, the weeks leading up to the election cycle culminating in the December 1 parliamentary elections saw DDoS attacks targeting political party websites and news organizations.

In South Africa, where the general election took place on May 29, there was a relevant DDoS attack in the weeks leading up to the election, targeting a major news site within the country for several days, with a peak on May 7 of 54,000 requests per second.

In Portugal, several DDoS attacks targeted political party websites on election day, March 10, particularly after polling stations closed. One political party’s websites experienced a peak of 69,000 rps on May 11 at 00:50 UTC.

In Taiwan, a local fact-checking website faced a DDoS attack three days before the election, on January 10.

In Japan, a DDoS attack targeted a website used to report scams and misinformation a week before the October 27 election.

While some of these rates may seem small to Cloudflare, they can be devastating for websites not well-protected against such high levels of traffic. DDoS attacks not only overwhelm systems but also serve, if successful, as a distraction for IT teams while attackers attempt other types of breaches.

Several times in 2024, election-related Internet shutdowns were imposed by authorities for various reasons, such as in the Comoros and Pakistan.

Comoros, a small archipelago country in Southeastern Africa with a population of less than 1 million, held presidential elections on January 14, which led to protests against the re-election of President Azali Assoumani. Authorities shut down the Internet on January 17, causing a 50% drop in traffic compared to the previous week, lasting for two days.

Pakistan’s general election day on February 8 was marked by an Internet shutdown targeting mobile networks. The outage began around 02:00 UTC, reducing Internet traffic by 50% compared to the previous week. Traffic only began recovering after 15:00, highlighting the severe impact of government-initiated shutdowns on Internet connectivity.

In Mauritius, an island nation in the Indian Ocean with under 2 million residents, the government suspended access to social media platforms from November 1 to November 11 ahead of the November 10 parliamentary elections. 

Election-day Internet traffic patterns often reflect a country’s dominant device usage, with mobile-first nations like Indonesia, Mozambique, and Ghana experiencing noticeable traffic drops after polling stations closed. While mobile-friendly countries generally see steady or higher weekend traffic compared to desktop-focused regions like Europe and the Americas, no consistent trend emerged linking device preference to overall election-day traffic increases or decreases.

Here’s a world map from our Year in Review 2024 showing countries where mobile (purple) or desktop (green) dominates Internet traffic.

Now, let’s explore a selection of relevant elections with Internet traffic impacts, ordered by election dates:

Taiwan (January 13) Taiwan’s presidential election saw traffic drop slightly during polling hours, especially in the morning with an 8% drop. Traffic returned to usual levels after 17:00 local time. Post-election, traffic rose by 5% the next morning compared to the previous week.

Finland (January 28) On January 28, Finland held its presidential election. Internet traffic dropped by 24% at 11:00 local time, coinciding with higher voter turnout in the morning. A second noticeable drop of 13% occurred at 20:00 when polling stations closed and TV stations broadcast initial projections, though traffic was slightly higher than usual afterward.

Indonesia (February 14)  Indonesia held its general election on February 14. With over 200 million voters spread across 17,000 islands, it likely had the highest number of voters on a single day, unlike India’s multi-week election. During polling hours (08:00 to 13:00 local time), Internet traffic dropped by up to 15%. Traffic remained lower than the previous week for the rest of the day, with drops ranging from 8% to 16% throughout the night. Mobile device usage surged to 77%, the highest of the year, reflecting Indonesia’s mobile-first Internet culture. Traffic recovered the next morning, surpassing the previous week’s levels.

Portugal (March 10) Portugal’s parliamentary election on March 10 saw a sharp 16% traffic drop at 20:00 local time when TV stations began broadcasting projections. Traffic picked up after that and remained stable during the day.

Russia (March 17) Russia’s presidential election showed steady Internet traffic throughout the day but experienced a 7% decrease after polls closed as results and reactions were broadcast on TV. Unlike other countries, where post-election traffic surges are common, Russia’s pattern reflects the strong influence of broadcast media on election coverage.

South Korea (April 10) South Korea held legislative elections on April 10. Traffic was higher than usual before 05:00 local time but dropped 14% by 07:15 after polling stations opened at 06:00. By 11:45, traffic had rebounded above typical levels. After polling stations closed at 18:00, traffic dropped again, with a 7% decline compared to the previous week.

India (April 19–June 1) - related blog post India’s seven-phase general election saw significant Internet traffic fluctuations. May 7 recorded the largest nationwide traffic dip of 6%, with populous states like Uttar Pradesh seeing a 9% drop and Maharashtra experiencing a 17% decline. On the final election day (June 1), mobile device usage peaked at 68%, the highest of the year. These patterns underscore India’s mobile-first Internet habits and its diverse election timelines.

North Macedonia (April 24 & May 8) North Macedonia’s two-round presidential election featured a 56% traffic increase after 11:00 local time on May 8, sustained throughout the day. Similar, albeit smaller, trends were observed during the first round on April 24.

Panama (May 5) On May 5, Panama’s presidential and parliamentary election day, Internet traffic dropped significantly while voting stations were open, with a 23% decrease in the afternoon and 25% lower traffic at 21:30 local time as results were announced. Traffic picked up after that.

South Africa (May 29) - related blog post On May 29, South Africa’s general election saw Internet traffic decrease by 16% at 05:45 and remain lower throughout polling hours. Traffic surged by 25% the night before the election, peaking at midnight. Post-election, traffic increased by up to 12% early on May 30, highlighting the transition from offline to online engagement.

Mexico (June 2) - related blog post Mexico’s general election on June 2 saw a 3% daily traffic drop, with hourly dips of up to 11% during polling hours (08:00–20:00 local time). Traffic surged by 14% at 01:30 the following day as results were announced, peaking at 8% above the previous week by 22:00 local time.

Iceland (June 1) Iceland’s presidential election on June 1 saw minor Internet traffic drops, including a 12% dip between 14:00 and 16:00 local time, but traffic increased at night by as much as 11% at 20:00. The day after, traffic rose by 26% compared to the previous week. Iceland elected Halla Tómasdóttir as its second female president.

European Union (June 6–9) - related blog post The 2024 European Parliament elections showed notable Internet traffic shifts and cybersecurity challenges. The Czech Republic and Slovakia experienced traffic drops of over 10%, while Finland and Ireland saw moderate declines. Key speeches, such as Belgian Prime Minister Alexander De Croo’s resignation and French President Macron’s snap election announcement, also caused traffic fluctuations.

^{Source: Cloudflare; created with Datawrapper}

Iran (June 28) Iran’s presidential election saw significant traffic fluctuations, with traffic falling by 16% after 17:30 local time. Extended polling hours (including at night) led to continued drops, falling to 24% lower by 22:30. After midnight, traffic rebounded, showing a 13% increase compared to the previous week.

France (June 30 & July 7) - related blog post France’s legislative elections brought significant Internet and cybersecurity activity. On July 7, Internet traffic dropped 16% at 20:00 local time as polling stations closed and TV broadcasts announced results. Mobile device usage surged to 58%, and DNS traffic to news outlets spiked by 250% during the first round and by 244% on runoff day, reflecting heightened public interest.

United Kingdom (July 4) - related blog post The UK’s general election on July 4 saw the Labour Party win a majority after 14 years of Conservative rule. Internet traffic declined slightly during voting hours, with a 2% drop at noon, before surging in the evening as results were announced. Northern Ireland experienced the sharpest traffic drop (10%), compared to 6% in Scotland and 5% in Wales. DNS traffic to election-related domains peaked with increases of 600% at 22:00 and 671% at 04:00 the following day.

Sri Lanka (September 21) Sri Lanka’s presidential election caused a 9% morning traffic dip and an 18% post-election surge after polls closed. Results triggered a 109% traffic increase at 03:00 local time on September 22.

Tunisia (October 6) Tunisia’s presidential election saw a 15% traffic dip at 17:00, followed by a 13% decline at 19:30 when results started arriving. The steady traffic decrease highlights the evening focus on offline engagement and result tracking.

Mozambique (October 9) Mozambique’s election drove an Internet traffic drop throughout the day, falling as much as 51% by 20:30 local time, and continuing lower than usual after that. A post-election surge of 16% occurred at 01:30. The election, held on a public holiday, resulted in a 31% daily traffic drop compared to the previous week.

Georgia (October 26) When Georgia held its parliamentary election on October 26, Internet traffic was 11% higher than the previous week, peaking at 67% above normal around 23:00 when results were announced. Unlike other countries, traffic only dipped slightly (2%) in the afternoon during polling hours.

Japan (October 27) Japan’s House of Representatives election saw Internet traffic decrease by 4% at 20:00 after polling stations closed, but it rose later in the evening.

Botswana (October 30) A traffic drop was observed throughout the day of Botswana’s general election, with a 42% decrease around 21:30 local time compared to the previous week.

United States (November 5) - related blog post The US elections saw a 15% spike in Internet traffic, particularly after polls closed, with the Midwest leading. There were also specific spikes related to key moments during election night, as the next chart shows: 

DNS traffic surged by 756% to polling services and 325% to news sites. As highlighted in our recent Internet Services Year in Review blog post, the US election also boosted DNS traffic and ranking positions for CNN, Fox News, and The New York Times, underscoring the Internet’s critical role during major political events.

In the US, beyond election day, we also reported in 2024 on trends surrounding the first Biden vs. Trump debate, the attempted assassination of Trump and the Republican National Convention, the Democratic National Convention, and the Harris-Trump presidential debate.

Ghana (December 7) Ghana’s general election caused mid-morning traffic drops of 11%, followed by declines of 13% and 14% after polling stations closed at 17:00. These patterns indicate offline focus during results announcements.

Romania (December 1) Romania’s parliamentary election showed minimal traffic fluctuations during the day, though its November 24 presidential election remains disputed.

From a cybersecurity perspective, trending events, topics, and individuals often attract more emails, including malicious, phishing, and spam messages. In our analysis earlier this year, we focused on the US presidential elections and the two major party candidates.

From June 1 to November 5, 2024, Cloudflare processed over 19 million emails mentioning "Donald Trump" or "Kamala Harris," with Trump appearing more frequently and in higher rates of spam (12%) and malicious emails (1.3%) compared to Harris (0.6% spam, 0.2% malicious). Nearly half were sent after September, with a surge in the final 10 campaign days.

As a global election year, 2024 underscored how deeply the Internet is woven into the democratic process, serving both as a tool for engagement and a target for disruption. From relevant DDoS attacks to government-imposed Internet shutdowns, the challenges faced during these elections reflect a growing need for robust cybersecurity measures to safeguard critical infrastructure and ensure free, fair electoral processes.

In this context, Germany has announced an anticipated federal election for February 23, 2025, following the collapse of its governing coalition during the 2024 government crisis. This snap election joins others in France and the UK, reflecting a growing trend of political instability requiring urgent electoral responses.

Looking ahead, the increasing frequency and complexity of cyber threats, such as DDoS attacks on campaigns and election infrastructure, demand proactive defenses. Shutdowns like those in Pakistan and Comoros, along with surges in phishing and misinformation, highlight the need for closer collaboration between governments, technology providers, and civil society to safeguard democracy in the digital era.

If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report.

In 2024, Thanksgiving (November 28), Black Friday (November 29), and Cyber Monday (December 2) significantly impacted Internet traffic, similar to trends seen in 2023 and previous years. This year, Thanksgiving in the US drove a 20% drop in daily traffic compared to the previous week, with a notable 33% dip at 15:45 ET. In contrast, Black Friday and Cyber Monday drove traffic spikes. But how global is this trend, and do attacks increase during Cyber Week?

At Cloudflare, we manage and protect a substantial amount of traffic for our customers, providing a unique vantage point to analyze traffic and attack patterns across the Internet. This perspective reveals insights like Cyber Monday being the busiest Internet traffic day of 2024 globally, followed by Black Friday, with patterns varying across countries. Notably, global HTTP request volume on Cyber Monday 2024 was 36% higher than 2023, with 5% of that traffic blocked as potential attacks.

For this analysis, we examined anonymized and aggregated HTTP requests and DNS queries across our network to uncover key patterns. Cyber Monday, December 2, was the day with peak traffic, and key findings for that day include:

• Cloudflare processed a peak of 99.8 million HTTP requests per second at 15:33 UTC on Cyber Monday, December 2.

• Cloudflare handled approximately 5.4 trillion daily requests on Cyber Monday, with blocked potential attacks comprising around 5% of all traffic. This was higher than the 5.1 trillion daily requests on Black Friday, where 6% of request traffic consisted of blocked potential attacks.

• Daily global HTTP request volume on Cyber Monday 2024 (December 2) increased by 36% compared to Cyber Monday 2023. In comparison, Cyber Monday 2023 had shown a 27% increase over Cyber Monday 2022.

This year’s trends, like those observed in previous years, show how Internet traffic typically peaks in late November but tends to drop in December. In 2024, Cyber Monday was again the busiest day for global Internet traffic. However, Black Friday didn’t make the Top 3, as Sunday, December 1, and Tuesday, November 26, saw higher traffic. Black Friday ranked #5, coming behind November 21. Note: On December 1, 2024, a customer-specific software update event contributed to the increased Internet traffic observed that day, including at the country level.

Highest Internet traffic days, worldwide

#1 Cyber Monday, December 2, 2024 #2 Sunday, December 1, the day before Cyber Monday #3 Tuesday, November 26, 2024

In the US, the ranking was similar, with Cyber Monday, Sunday, and Black Friday being the busiest days for Internet traffic. On Cyber Monday, traffic was 12% higher than the previous week and 57% higher than Cyber Monday 2023.

Highest Internet traffic days, United States

#1 Cyber Monday, December 2 #2 Sunday, December 1 #3 Black Friday, November 29

Additionally, most US states show a similar trend, with Cyber Monday generating the most traffic, followed by Sunday, December 1, and Black Friday, November 29. Arizona, West Virginia, and Arkansas saw increases in traffic of over 20% compared to the previous week. Almost all other states experienced traffic increases exceeding 10%, including some of the most populous ones like California (11%), Florida (11%), and New York (11%).

In looking at just traffic to Shopping and Retail sites based in the US that use Cloudflare, Cyber Monday recorded the highest traffic, followed by Black Friday and the Black Friday weekend. Traffic to these sites increased significantly during Cyber Week, starting on Monday, November 25, with a 7% increase compared to the previous week and a 57% jump compared to the first week of November.

During Thanksgiving Day, mobile usage in the US increased significantly, with mobile device traffic accounting for 51.7% of all traffic, compared to 42.4% the previous week. The trend intensified on Black Friday, with mobile’s share peaking at 51.9% (up from 43.9% the prior Friday) and reaching a similar level on Saturday, November 30, at 52%. However, Cyber Monday saw a shift to desktop use, with mobile device share dropping to 43.4%, lower than the previous Monday. This mirrors a similar trend observed in 2023.

These patterns suggest that Black Friday shopping in the US often involves more out of home/office activities, with people relying on mobile devices for Internet access while on the go, whereas the opposite tends to occur on Cyber Monday, a day when many return to work and school in the US.

Internationally, a trend of peak Internet traffic in November is observed in most countries, as highlighted in our 2023 Year in Review. This trend is likely linked to colder weather in the Northern Hemisphere, where approximately 87% of the world's population resides, as well as holidays and shopping periods, among other factors.

Here's a table summarizing the November and early December days with the most traffic, where Cyber Week plays a significant role.

Highest Internet traffic days

Countries like the Philippines (where Singles’ Day was the top shopping day again this year), Japan, South Korea, Thailand, and Indonesia (where Cyber Monday ranked second this year) show increased traffic in October and November compared to other months. However, they do not exhibit an obvious increase in traffic during Cyber Week.

As noted earlier, Singles' Day (November 11), a major Asian shopping event, ranked among the Top 3 traffic days in Turkey, the Philippines, and other countries.

Aggregated data from our 1.1.1.1 resolver reveals category-specific DNS traffic growth to E-commerce sites, showing a steady increase throughout November, similar to the overall Internet traffic trends.

In the US, E-commerce DNS traffic in November 2024 followed a similar pattern compared to 2023. Black Friday (November 29) ranked as the top day for DNS traffic in the E-commerce category, followed closely by Cyber Monday and Tuesday, November 26. This aligns more closely with overall US Internet traffic trends, where Cyber Monday ranked #1.

Also in the E-commerce category, DNS traffic on Black Friday peaked between 15:00 and 18:00 ET (13:00 and 15:00 PT), with an 18% increase at 18:00 ET compared to the previous week. On Cyber Monday, peak traffic occurred later, from 20:00 to 22:00 ET (17:00 to 19:00 PT).

The UK showed a similar trend in DNS traffic to E-commerce sites, mirroring its Internet traffic patterns, and following the same pattern as 2023. In 2024, Black Friday (November 29) ranked #1, followed by Cyber Monday (December 2), and Thursday, November 21.

In Australia, Saturday, November 30 (the day after Black Friday), was the top day for E-commerce DNS traffic, followed by Cyber Monday and Black Friday. Canada followed a similar trend, with Black Friday ranking highest, followed by Cyber Monday.

In Germany, the busiest E-commerce day was Thursday, November 21, a week before Black Friday, followed by Black Friday (November 29) and Monday, November 25. Cyber Monday did not make the top three, consistent with 2023.

In France, Black Friday remained the top E-commerce day, as in 2023, followed by Cyber Monday (December 2) and Thursday, November 21.

Focusing on the US again, so-called “low-cost” E-commerce sites (which include recent entrants like Temu and fast-fashion brands) have become increasingly popular, and experienced more DNS traffic in the days leading up to Black Friday and Thanksgiving, specifically November 26 and 27. Cyber Monday ranked third.

As observed last year, second-hand shopping sites (ones that offer previously used items) in the US gained more momentum and DNS traffic during the two weeks before Black Friday week. Traffic to these sites peaked on November 12, with Cyber Monday coming in as a close second.

DDoS (distributed denial-of-service) attacks remain a common tactic for disrupting Internet properties. Our data shows that Shopping and Retail sites in the United States protected by Cloudflare experienced a significant rise in DDoS activity on Cyber Monday. On that day, 7% of all traffic in this category was mitigated as DDoS attacks, with an additional 8% flagged as potential threats.

More broadly, DDoS activity targeting the US in general (not limited to E-commerce) also spiked during Black Friday week. Starting November 24, the share blocked as DDoS attacks rose sharply, peaking at over 2% of all traffic on November 25. Across the entire Cyber Week, there was a 41% increase in blocked DDoS attack requests compared to the previous week.

From a cybersecurity perspective, trending events, topics, and individuals often trigger spikes in email traffic, including malicious, phishing, and spam messages. This was evident during the Paris 2024 Olympics, the US elections, and shopping periods like Black Friday and Cyber Monday. Between November 1 and December 2, 2024, Cloudflare’s Cloud Email Security service processed nearly 24 million emails mentioning “Black Friday” or “Cyber Monday” in the subject. Of those, 19.4 million referenced “Black Friday” while 4.2 million mentioned “Cyber Monday”, with 76% (3.2 million) of the Cyber Monday emails sent on December 2, 2024.

During this period, “Black Friday” emails were not only higher volume but also showed higher percentages of spam (10.8%) and malicious content (0.9%) compared to emails mentioning “Cyber Monday” in the subject, which had 1.8% spam and 0.2% malicious content.

In the next chart, we focus on emails with “Black Friday” in the subject, given that it generated the highest percentage of spam and malicious emails. Spam emails peaked in mid-November, making up 29% of all emails, and reached 26% on Cyber Monday. Malicious email percentages were also higher in mid-November, with 3% recorded on November 14, before Black Friday week.

The busiest day for “Black Friday” emails was November 29, Black Friday itself, with 4.1 million emails, followed by Saturday, November 30 (1.5 million), and Wednesday, November 27 (1.4 million).

Internet traffic trends during Black Friday and Cyber Monday show varying patterns globally and regionally. Cyber Monday leads in traffic overall, followed closely by Black Friday. While the US and Canada share similar trends, countries like the UK, Germany, and Australia saw traffic higher on Black Friday than Cyber Monday. In most countries, activity also increased in the days leading up to Black Friday.

On the cybersecurity front, DDoS attacks were more noticeable during Cyber Week in 2024, especially targeting shopping-related sites.

If you’re interested in more trends and insights about the Internet, check out Cloudflare Radar. Follow us on social media at @CloudflareRadar (X), https://noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky), or contact us via email.

​​Happy Holidays from everyone at Cloudflare!

If we look at the metrics associated with large attacks mitigated in the last 10 years, does the graph show a steady increase in an exponential curve that keeps getting steeper, especially over the last few years, or is it closer to linear growth? We found that the growth is not linear, but rather is exponential, with the slope dependent on the metric we are looking at.

Why is this question interesting? Simple. The answer to it provides valuable insights into the evolving strategies of attackers, the sophistication of their tools, and the readiness of defense mechanisms. 

As an example, an upward curve of the number of requests per second (rps) suggests that the attackers are changing something on their side that enables them to generate larger volumes of requests. This is an insight that prompts us to investigate more and look at other data to understand if anything new is happening.

For instance, at one of those moments, we looked at the source of the traffic and saw a shift from subscriber/enterprise IP address space (suggesting IoT) to cloud provider IP address space (suggesting VMs), and realized there was a shift in the type and capabilities of devices used by attackers. 

As another example: when the HTTP/2 Rapid Reset attack happened, the record number of requests per second seen at that time suggested that a new technique was being employed by attackers, prompting us to swiftly investigate what was being executed and adapt our defenses.

Delimiting an individual attack in time is surprisingly blurry. First of all, an attack analysis can provide inconsistent observations at different layers of the OSI model. The footprint seen at all these different layers may tell different stories for the same attack. There are, however, some variables that together can allow us to create a fingerprint and enable us to group a set of events, establishing that they are part of the same individual attack. Examples include: 

• Do we see the same attack vector(s) being used across this set of events?

• Are all the attack events focused on the same target(s)?

• Do the payloads on events share the same signature? (Specific data payloads or request types unique to certain types of attacks or botnets, like Mirai, which may use distinctive HTTP request headers or packet structures).

Before we dive into a growth analysis of DDoS attacks over the last 10 years, let's take a step back and have a look at the metrics typically used to measure them: requests per second (rps), packets per second (pps), and bits per second (bps). Each metric captures a different aspect of the attack's scale and impact.

• Requests per second (rps): Measures the number of HTTP or similar protocol requests made each second. This metric is particularly relevant for application-layer attacks (Layer 7), where the intent is to overwhelm a specific application or service by overloading its request handling, and is useful for measuring attacks targeting web servers, APIs, or applications because it reflects the volume of requests, not just raw data transfer.

• Packets per second (pps): Represents the number of individual packets sent to the target per second, regardless of their size. This metric is critical for network-layer attacks (Layers 3 and 4), where the goal is to overwhelm network infrastructure by exceeding its packet-processing capacity. pps measurements are useful for volumetric attacks, identifying a quantity of packets that can impact routers, switches, or firewalls.

• Bits per second (bps): This measures the total data transferred per second and is especially useful in evaluating network-layer attacks that aim to saturate the bandwidth of the target or its upstream provider. bps is widely used measuring Layer 3 and 4 attacks, such as UDP floods, where the attack intends to clog network bandwidth. This metric is often highlighted for DDoS attacks because high bps values (often measured in gigabits or terabits) signal bandwidth saturation, which is a common goal of large-scale DDoS campaigns.

So, how have DDoS attack sizes changed in the last decade? During this period, DDoS attacks have grown bigger and stronger, each year having the potential to be more disruptive. 

If we look at the metrics associated with large attacks seen in the last 10 years, does it look like we have a steady increase in an exponential curve that keeps steepening, especially in the last few years, or is it closer to a linear growth? We found that it is exponential, so let’s have a look at the details around why we came to that conclusion.

In this analysis, we used attacks that Google has seen from 2010 until 2022 as a baseline (Figure 1) that we extended with attacks that Cloudflare has seen in 2023 and 2024 (Figure 2). 

Going back in time, early in the 2010s, the largest attacks were measured in the Gigabits per second (Gbps) scale, but these days, it’s all about Terabits per second (Tbps). The number of requests per second (rps) and bits per second (bps) are also significantly higher these days, as we will see.

The historical data from Google shown below in Figure 1 reveals a rising trend in requests per second during DDoS attacks observed between 2010 and 2022, peaking at 6 Million requests per second (Mrps) in 2020. The increase highlights a significant escalation in attack volume across the decade.

^{Figure 1. Largest known DDoS attacks, 2010 - 2022. (Source: Google)} 

Figure 2 (below) provides a view of trends seen across the different metrics. The escalation seen in Google’s statistics is also visible in Cloudflare’s data regarding large mitigated DDoS attacks observed in 2023 and 2024, reaching 201 Mrps (green line) in September 2024. The rate of packets per second (pps) demonstrates (blue line) a slight exponential growth over time, rising from 230 Mpps in 2015 to 2,100 Mpps in 2024, suggesting that attackers are achieving higher throughput. For bits per second (bps), the trend is also exponential and with a steeper upwards curve (red line), building from a 309 Gbps attack in 2013 to a 5.6 Tbps (5,600 Gbps) attack in 2024. 

Over roughly the last decade, attacks driving these metrics have seen significant growth rates:

• Bits per second increased by 20x between 2013 and 2024

• Packets per second increased by 10x between 2015 and 2024

• Requests per second increased by 70x between 2014 and 2024

^{Figure 2. Data from Figure 1 extended with large attacks observed by Cloudflare in 2023 and 2024.}

The blog posts listed in Table 1 highlight some of the attacks that we observed from 2021 to 2024.

^{Table 1. Notable DDoS attacks observed by Cloudflare between 2021 - 2024.}

An overview of other selected significant high volume DDoS attacks that have occurred over the last decade, including 2018’s Memcached abuse and 2023’s HTTP/2 “Rapid Reset” attacks, can be found on the Cloudflare Learning Center.

Attack duration is not an effective metric to use to qualify attack aggressiveness because establishing a duration of a single attack or campaign is challenging, due to their possible intermittent nature, the potential for a multitude of attack vectors being used at the same time, or how the different defense layers triggered over time. 

The attack patterns can differ considerably, with some consisting of a single large spike, while others featuring multiple tightly grouped spikes, or a continuous load maintained over a period of time, along with other changing characteristics.

DDoS attacks are increasingly shifting from IoT-based botnets to more powerful VM-based botnets. This change is primarily due to the higher computational and throughput capabilities of cloud-hosted virtual machines, which allow attackers to launch massive attacks with far fewer devices. 

This shift is facilitated by several factors: VM botnets can be easier to establish than IoT botnets, as they don’t necessarily require widespread malware infections, since attackers can deploy them on cloud provider infrastructure anonymously using stolen payment details from data breaches or Magecart attacks.

This trend points to the evolution of DDoS tactics, as attackers exploit both the processing power of VMs and anonymized access to cloud resources, enabling smaller, more efficient botnets capable of launching large-scale attacks without the complexities involved in infecting and managing fleets of IoT devices.

Cloudflare's Connectivity Cloud, built on our expansive anycast global network, plays a crucial role in defending against DDoS attacks by leveraging automated detection, traffic distribution, and rapid response capabilities. Here’s how it strengthens DDoS protection:

Automated attack detection and mitigation: Cloudflare’s DDoS protection relies heavily on automation, using machine learning algorithms to identify suspicious traffic patterns in real time. By automating the detection process, Cloudflare can quickly recognize and block DDoS attacks without requiring manual intervention, which is critical in high-volume attacks that would overwhelm human responders.

Global traffic distribution with IP anycast: Cloudflare's network spans over 330 cities worldwide, and DDoS traffic gets distributed across our multiple data centers. IP anycast allows us to distribute traffic across this global network, and this wide distribution helps absorb and mitigate large-scale attacks, as attack traffic is not directed towards a single point, reducing strain on individual servers and networks. 

Layered defense: Cloudflare’s Connectivity Cloud offers defense across multiple layers, including network (Layer 3), transport (Layer 4), and application (Layer 7). This layered approach allows for tailored defense strategies depending on the attack type, ensuring that even complex, multi-layered attacks can be mitigated effectively. Learn more about DDoS protection at layers 3, 4, and 7 in our DDoS protection documentation.

Unmetered DDoS mitigation: Pioneering this approach since 2017 to ensure Internet security, Cloudflare provides unmetered DDoS protection, meaning customers are protected without worrying about bandwidth or cost limitations during attacks. This approach helps ensure that businesses, regardless of size or budget, can benefit from robust DDoS protection.

Cloudflare’s distributed cloud infrastructure and advanced technology allows us to detect, absorb, and mitigate DDoS attacks in a way that is both scalable and responsive, avoiding downtime and maintaining service reliability, providing a robust solution to tackle the rising intensity and frequency of DDoS attacks compared to traditional options.

Protecting against DDoS attacks is essential for organizations of every size. Although humans initiate these attacks, they’re carried out by bots, so effective defense requires automated tools to counter bot-driven threats. Real-time detection and mitigation should be as automated as possible, since relying solely on human intervention puts defenders at a disadvantage as attackers adapt to new barriers and can change attack vectors, traffic behavior, payload signatures, among others, creating an unpredicted scenario and thus rendering some manual configurations useless. Cloudflare’s automated systems continuously identify and block DDoS attacks on behalf of our customers, enabling tailored protection that meets individual needs.

Our mission is to help build a better Internet, and providing resilience in the face of DDoS threats is a part of accomplishing that mission.

Read more about Cloudflare DDoS protection in our public technical documentation.

Tuesday, November 5, 2024 was Election Day in the United States. It not only decided the next president and vice president but also included elections for the US Senate, House of Representatives, state governorships, and state legislatures. Results confirm that Republican Donald Trump won the presidential election.

In this blog post, we examine online attacks against election-related sites — some of which were notable but none were disruptive — and how initial election results impacted Internet traffic across the US at both national and state levels, with increases in traffic as much as 15% nationwide. We’ll also explore email phishing trends and general DNS data around news interest, the candidates, and election-related activity.

We’ve been tracking 2024 elections globally through our blog and election report on Cloudflare Radar, covering some of the more than 60 national elections around the globe this year. At Cloudflare, we support many of these efforts to ensure a secure and trustworthy election process. We worked closely with election officials, government agencies, and civil society groups across the country to ensure that groups working in the election space had the tools they needed to stay online. 

Regarding the US elections, we have previously reported on trends surrounding the first Biden vs. Trump debate, the attempted assassination of Trump and the Republican National Convention, the Democratic National Convention, and the Harris-Trump presidential debate.

Key takeaways:

• In the 24 hour period from October 31 - November 1, Cloudflare automatically mitigated over 6 billion HTTP DDoS requests that targeted US election-related websites–such as state and local government election sites and political campaigns. There were no significant disruptions to the targeted websites during this time period.

• The day before the election, DNS traffic to Trump/Republican and Harris/Democrat websites peaked, with daily DNS traffic rising 59% and 4% respectively.

• On election day, states in the midwest saw the highest traffic growth across the US, as compared to the previous week. 

• Internet traffic in the US peaked after the first polling stations closed, with a 15% increase over the previous week. 

• DNS traffic to news, polling, and election websites also saw large traffic jumps. Polling services were up 756% near poll closures and news sites were up 325% by late evening.

Cloudflare’s goal is to ensure that sites that enable democracy — such as voter registration sites, election information portals, campaign websites, and results reporting platforms — remain secure and accessible, especially under heavy traffic periods or cyberattacks. Through our Impact programs, we provide essential cybersecurity resources to more than 800 websites that work on election infrastructure.

• Project Galileo: Launched in 2014, Project Galileo provides free Business level services to media organizations, human rights defenders and non-profit organizations around the world. We protect more than 65 Internet properties related to elections in the United States that work on a range of topics related to voting rights, promoting free and fair elections, and posting election results. These organizations include Vote America, Decision Desk HQ, US Vote Foundation, and Electionland.

• Athenian Project: Launched in 2017, the Athenian Project provides state and local governments that run elections with free Enterprise level services to ensure that voters can access accurate and up-to-date information about voter registration, polling places, and election results without interruption. We currently protect 423 websites in 33 states under the project.

• Cloudflare for Campaigns: Launched in 2020, in partnership with Defending Digital Campaigns, Cloudflare for Campaigns provides a package of products to address the increasing risks posed by cyberattacks on political campaigns and state parties. We currently protect more than 354 campaigns and 34 state-level political parties in the United States. 

Since 2020, we’ve strengthened our partnerships with election officials, government agencies, and nonprofits to provide essential protections. Throughout 2024, we’ve collaborated with CISA (Cybersecurity and Infrastructure Security Agency) and the Joint Cyber Defense Collaborative, briefing over 300 election officials on emerging threats and conducting 50+ calls with state and local governments to review security practices. Additionally, we held webinars on cyber threats to election groups and strategies for protecting election infrastructure.

With Defending Digital Campaigns, we worked to onboard more than 90 campaigns and parties weeks before election day. As part of this, we also worked with political vendors managing campaign infrastructure to provide insight on emerging threats and how to mitigate. Under Project Galileo, we onboarded more than 60 local media and journalism sites reporting on elections to ensure they can provide timely, accurate information on voting processes, candidate platforms, and election results.

As we've seen several times this year, specific DDoS (Distributed Denial of Service) attacks often target political party or candidate websites around election day. While online attacks are frequent and not always election-related, we saw recent DDoS incidents in France, the Netherlands, and the U.K. focused on political parties during election periods. 

In the US, we saw a similar uptick in attacks immediately prior to the election. Cloudflare blocked  cyberattacks targeting websites affiliated with both parties, attempting to take the sites offline. Although some attacks had high volumes of traffic, the targeted websites remained online.

DDoS attacks targeting US political or elections-related Internet properties in particular clearly picked up starting in September, with the more than 6 billion HTTP DDoS requests seen during the first six days of November exceeding the volume seen during all of September and October.

Some campaign websites drove most of the malicious HTTP request traffic as part of DDoS attacks, with a clear increase since October 1, compared to minimal DDoS activity earlier in 2024. 

Let’s look at a few examples of specific DDoS attacks, as these are easier to track.

Cloudflare blocked a series of DDoS attacks targeting a high-profile campaign website. The attacks began on October 29, with a four-minute spike reaching 345,000 requests per second. On October 31, more intense attacks followed, with the first lasting over an hour, peaking at 213,000 requests per second. Hours later, on November 1, a larger attack reached 700,000 requests per second, followed by two more waves at 311,000 and 205,000 requests per second.

Over 16 hours, Cloudflare blocked more than 6 billion malicious HTTP requests between October 31 and November 1. Additional attacks continued on November 3, with peaks at 200,000 requests per second (rps); on November 4, at 352,000; on Election Day, November 5, at 271,000 around 14:33 ET (11:33 PT); and on November 6, at 108,000.

Our data shows that the attacker(s) randomized user agents, attempted cache-busting techniques (methods to bypass cached content and overload servers with unique requests), and employed a geodiverse approach.

The DDoS attack on November 1 reached peak bandwidth of over 16 Gbps sent to Cloudflare and maintained over 8 Gbps throughout the main attack, which lasted more than two hours.

Attackers also expanded their attacks beyond campaign sites, to political parties and their infrastructure, attempting — unsuccessfully — to disrupt services.  For example, on November 3, 2024, a DDoS attack targeted infrastructure associated with a major campaign, lasting two minutes and reaching 260,000 malicious HTTP requests per second. 

On October 29, 2024, a high-volume DDoS attack targeted a U.S. political party website from a specific state. The attack lasted over four hours, from 12:00 to 17:29 ET (09:00 to 14:29 PT), and peaked at 206,000 requests per second. In total, over 2 billion malicious HTTP requests were blocked that day as part of this DDoS attack.

The same method used in the November 1 attack on one of the main campaign websites, mentioned above, was also used in this case. Here, the DDoS attack reached a peak of 5.7 Gbps sent to Cloudflare by the attacker, and sustained over 3 Gbps for most of its four-and-a-half-hour duration.

Since September, US state and local websites protected by Cloudflare under the Athenian Project have experienced increased DDoS attacks, particularly targeting specific counties. These types of sites have seen over 290 million malicious HTTP requests since September 1, with 4% of all requests blocked as threats. These attacks were less frequent and intense than those on US political campaigns infrastructure. 

On September 13, 2024, a DDoS attack targeted a county website from 19:29 UTC to 22:32 UTC (15:29 to 18:32 ET), lasting three hours and peaking at 46,000 of malicious HTTP requests per second.

These rates of DDoS attacks are already significant, even more so when we compare it with the 2020 US presidential election. In 2020, we saw more varied blocked cyberattack HTTP requests, split between WAF (Web Application Firewall) and firewall rules, and DDoS attacks. There were also significantly fewer blocked requests related to DDoS and WAF, with nearly 100 million in the whole month of October 2020 and close to 25 million in November 2020, the month of the election. In contrast, during November 1-6, 2024, alone, we observed over 6 billion malicious HTTP requests in DDoS attacks targeting campaigns.

It’s also important to note that even smaller attacks can be devastating for websites not well-protected against such high levels of traffic. DDoS attacks not only overwhelm systems but also serve, if successful, as a distraction for IT teams while attackers attempt other types of breaches.

Generally, election days do not lead to drastic changes in Internet traffic. Traffic usually slightly dips during voting hours, though not as sharply as on national holidays, and rises in the evening as results are announced. 

In the US, a similar pattern was observed on November 5, 2024, with increased Internet traffic at night. However, traffic throughout the day was generally 6% higher than the previous week, starting as early as 09:15 ET (06:15 PT). This may also be because, unlike in other countries, Election Day in the US is on a weekday rather than a weekend and is not a national holiday. Internet traffic peaked after the first polls closed, around 21:15 ET (18:15 PT), as TV news stations displayed countdown clocks. At that moment, traffic was 15% higher than the previous week.

Note: The previous 7 days line that appears in the next chart is one hour behind due to the Daylight Saving Time change over the weekend in the US. All growth calculations in this post take that change into account.

The biggest spike in traffic growth (compared to the previous week) of Election Day occurred at around 01:30 am ET (22:30 PT), when projections began to favor Trump for the presidential victory and Fox News called Pennsylvania in his favor, with traffic rising 32% compared to the previous week. Later, during Donald Trump's speech between 02:30 and 02:45 am ET (23:30 and 23:45 PT), Internet traffic was 31% higher than the previous week. 

On Election Day, daily Internet traffic in the US reached its highest level of 2024 in terms of requests, showing a 6% increase compared to the previous week.

As expected for a typical election day, considering what we observed in other countries, the share of traffic from mobile devices was also slightly higher on Election Day at 43%, compared to 42% the previous week.

State-level traffic shifts on Election Day, compared to the previous week, reveal more detail than country-level data. The map below highlights the biggest traffic changes, peaking at 21:00 ET (18:00 PT) after polling stations began to close. Notably, traffic increased nationwide and at the state level on Election Day, unlike during the two-hour presidential debates, which were broadcast on nationwide TV.

The most significant traffic increases were observed in Maine (44%), South Dakota (44%), and Montana (44%). Interestingly, central states saw higher percentages of Internet traffic growth than coastal ones. More populous states, such as California (8%), Texas (19%), New York (22%), and Florida (23%), also experienced notable traffic increases.

The seven swing states that are considered to have been decisive in the election — Georgia, Michigan, Nevada, North Carolina, Pennsylvania, and Wisconsin (we’re not considering Arizona due to data issues) — each saw traffic growth between 17% and 36%. Here’s a more focused view of those swing states for easier consumption:

Switching our focus to domain trends, our 1.1.1.1 resolver DNS data reveals a clear impact during the US elections when analyzing specific categories.

Analysis of DNS traffic for US news media outlets shows that traffic from the United States rose significantly right after 09:00 ET (06:00 PT), increasing around 15%, compared to the previous week. Traffic continued to climb throughout the day, peaking between 22:00 and 23:00 ET (19:00 and 20:00 PT) with DNS request traffic volume 325% higher than the previous week. There was also a brief spike on Wednesday, November 6, at 05:00 ET (02:00 PT), showing a 117% increase.

We observed significantly higher DNS traffic for polling services websites — websites of platforms or organizations that conduct and publish polls — on Election Day, peaking at 13:00 ET (10:00 PT) with a 206% increase from the previous week, and again at 22:00 ET (19:00 PT), after the polls started to close, with a 756% increase. Daily traffic to this category was up 145% on Election Day, and 36% the day prior.

Election and voting information-related websites also saw a notable rise in DNS traffic around Election Day. Traffic clearly began to increase the day before the election, and peaked on November 5, 2024, at 12:00 ET (09:00 PT), with a 313% increase from the previous week. Daily traffic was 139% higher on Election Day, and 68% higher the day before.

Social media sites/applications, especially microblogging platforms like X and Threads, were also impacted during Election Day. DNS traffic for these microblogging platforms peaked at 22:00 ET (19:00 PT), aligning with spikes for news organizations and polling services, showing a 91% increase compared to the previous week. In this microblogging category, daily DNS traffic on Election Day rose by 12% from the previous week.

Regarding the two main presidential candidates, DNS traffic for their websites and their parties’ websites was much higher the day before the election than on Election Day. On November 4, 2024, daily DNS traffic to Trump and Republican websites was up 59% compared to the previous week, while traffic to Harris and Democrat websites, which had a more significant increase in DNS traffic the previous week, rose by 4%. 

From a cybersecurity perspective, trending events, topics, and individuals often attract more emails, including malicious, phishing, and spam messages. Our earlier analysis covered email trends involving “Joe Biden” and “Donald Trump” since January. We’ve since updated it to include Kamala Harris after the Democratic Convention and the Harris-Trump debate.

From June 1 through November 4, 2024, Cloudflare’s Cloud Email Security service processed over 19 million emails with “Donald Trump” or “Kamala Harris” in the subject line — 13.9 million for Trump and 5.3 million for Harris. Nearly half of these emails (49%) were sent since September. In the last 10 days of the campaign (since October 24), Harris was named in 800,000 email subject lines and Trump in 1.3 million.

Since June 1, 12% of emails mentioning Trump were marked as spam, and 1.3% were flagged as malicious or phishing. This rate has dropped since September 1, with only 3% marked as spam and 0.3% as malicious. For emails mentioning Harris, the rates were lower: 0.6% were marked as spam and 0.2% as malicious since June, increasing slightly to 1.2% spam and 0.2% malicious since September 1. Trump was mentioned more frequently in email subjects than Harris and was found in higher overall percentages of spam and malicious emails.

Although Cloudflare observed a notable increase in DDoS attacks on political and election-related sites, blocking billions of malicious requests, these attacks resulted in no significant disruption due to planning and proactive defenses. We share the Cybersecurity and Infrastructure Security Agency’s view that “our election infrastructure has never been more secure” and concur with their conclusion that  “We have no evidence of any malicious activity that had a material impact on the security or integrity of our election infrastructure." Keeping our elections secure and resilient is critical to the functioning of democracy, and Cloudflare is proud to have played our part. 

If you want to follow more trends and insights about the Internet and elections in particular, you can check Cloudflare Radar, and more specifically our new 2024 Elections Insights report, which will be updated as elections take place throughout the year.

Welcome to the 19th edition of the Cloudflare DDoS Threat Report. Released quarterly, these reports provide an in-depth analysis of the DDoS threat landscape as observed across the Cloudflare network. This edition focuses on the third quarter of 2024.

With a 296 Terabit per second (Tbps) network located in over 330 cities worldwide, Cloudflare is used as a reverse proxy by nearly 20% of all websites. Cloudflare holds a unique vantage point to provide valuable insights and trends to the broader Internet community.

• The number of DDoS attacks spiked in the third quarter of 2024. Cloudflare mitigated nearly 6 million DDoS attacks, representing a 49% increase QoQ and 55% increase YoY.

• Out of those 6 million, Cloudflare’s autonomous DDoS defense systems detected and mitigated over 200 hyper-volumetric DDoS attacks exceeding rates of 3 terabits per second (Tbps) and 2 billion packets per second (Bpps). The largest attack peaked at 4.2 Tbps and lasted just a minute.

• The Banking & Financial Services industry was subjected to the most DDoS attacks. China was the country most targeted by DDoS attacks, and Indonesia was the largest source of DDoS attacks.

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 the first half of 2024, Cloudflare’s autonomous DDoS defense systems automatically detected and mitigated 8.5 million DDoS attacks: 4.5 million in Q1 and 4 million in Q2. In Q3, our systems mitigated nearly 6 million DDoS attacks bringing it to a total of 14.5 million DDoS attacks year-to-date. That’s an average of around 2,200 DDoS attacks every hour.

Of those attacks, Cloudflare mitigated over 200 hyper-volumetric network-layer DDoS attacks that exceeded 1 Tbps or 1 Bpps. The largest attacks peaked at 3.8 Tbps and 2.2 Bpps. Read more about these attacks and how our DDoS defense systems mitigated them autonomously.

^{Distribution of hyper-volumetric DDoS attacks over time}

As we were writing this blog post, our systems continued to detect and mitigate these massive attacks and a new record has just been broken again, only three weeks after our last disclosure. On October 21, 2024, Cloudflare’s systems autonomously detected and mitigated a 4.2 Tbps DDoS attack that lasted around a minute.

^{4.2 Tbps DDoS attack mitigated autonomously by Cloudflare}

Of the 6 million DDoS attacks, half were HTTP (application layer) DDoS attacks and half were network layer DDoS attacks. Network layer DDoS attacks increased by 51% QoQ and 45% YoY, and HTTP DDoS attacks increased by 61% QoQ and 68% YoY.

90% of DDoS attacks, including the largest of attacks, were very short-lived. We did see, however, a slight increase (7%) in attacks lasting more than an hour. These longer attacks accounted for 3% of all attacks.

In Q3, we saw an even distribution in the number of network-layer DDoS attacks compared to HTTP DDoS attacks. Of the network-layer DDoS attacks, SYN flood was the top attack vector followed by DNS flood attacks, UDP floods, SSDP reflection attacks, and ICMP reflection attacks.

On the application layer, 72% of HTTP DDoS attacks were launched by known botnets and automatically mitigated by our proprietary heuristics. The fact that 72% of DDoS attacks were mitigated by our home-grown heuristics showcases the advantages of operating a large network. The volume of traffic and attacks that we see let us craft, test, and deploy robust defenses against botnets.

Another 13% of HTTP DDoS attacks were mitigated due to their suspicious or unusual HTTP attributes, and another 9% were HTTP DDoS attacks launched by fake browsers or browser impersonators. The remaining 6% of “Other” includes attacks that targeted login endpoints and cache busting attacks.

One thing to note is that 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.

^{Distribution of DDoS attacks in 2024 Q3}

In Q3, we observed a 4,000% increase in SSDP amplification attacks compared to the previous quarter. An SSDP (Simple Service Discovery Protocol) attack is a type of reflection and amplification DDoS attack that exploits the UPnP (Universal Plug and Play) protocol. Attackers send SSDP requests to vulnerable UPnP-enabled devices such as routers, printers, and IP-enabled cameras, and spoof the source IP address to be the victim’s IP address. These devices respond to the victim’s IP address with large amounts of traffic, overwhelming the victim’s infrastructure. The amplification effect allows attackers to generate massive traffic from small requests, causing the victim’s service to go offline. Disabling UPnP on unnecessary devices and using DDoS mitigation strategies can help defend against this attack.

^{Illustration of an SSDP amplification attack}

When launching HTTP DDoS attacks, threat actors want to blend in to avoid detection. One tactic to achieve this is to spoof the user agent. This lets them appear as a legitimate browser or client if done successfully.

In Q3, 80% of HTTP DDoS attack traffic impersonated the Google Chrome browser, which was the most common user agent observed in attacks. More specifically, Chrome 118, 119, 120, and 121 were the most common versions.

In second place, no user agent was seen for 9% of HTTP DDoS attack traffic.

In third and fourth place, we observed attacks using the Go-http-client and fasthttp user agents. 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 used for DDoS attacks and web scraping too.

^{Top user agents used in DDoS attacks}

The user agent hackney came in fifth place. It’s an HTTP client library for Erlang. It's used for making HTTP requests and is popular in Erlang/Elixir ecosystems.

An interesting user agent shows up in the sixth place: HITV_ST_PLATFORM. This user agent appears to be associated with smart TVs or set-top boxes. Threat actors typically avoid using uncommon user agents, as evidenced by the frequent use of Chrome user agents in cyberattacks. Therefore, the presence of HITV_ST_PLATFORM likely suggests that the devices in question are indeed compromised smart TVs or set-top boxes.

In seventh place, we saw the uTorrent user agent being used in attacks. This user agent is associated with a popular BitTorrent client that’s used for downloading files.

Lastly, okhttp was the least common user agent in DDoS attacks despite its popularity as an HTTP client for Java and Android applications. 

While 89% of HTTP DDoS attack traffic used the GET method, it is also the most commonly used HTTP method. So when we normalize the attack traffic by dividing the number of attack requests by total request per HTTP method, we get a different picture.

Almost 12% of all requests that used the DELETE method were part of an HTTP DDoS attack. After DELETE, we see that HEAD, PATCH and GET are the methods most commonly used in DDoS attack requests.

While 80% of DDoS attack requests were over HTTP/2 and 19% were over HTTP/1.1, they represented a much smaller portion when normalized by the total traffic by version. When we normalize the attack requests by all requests by version, we see a different picture. Over half of traffic to the non-standard or mislabeled “HTTP/1.2” version was malicious and part of DDoS attacks. It's important to note that “HTTP/1.2” is not an official version of the protocol.

^{The vast majority of HTTP DDoS attacks are actually encrypted — almost 94% — using HTTPS.}

China was the most attacked location in the third quarter of 2024. The United Arab Emirates was ranked second, with Hong Kong in third place, followed closely by Singapore, Germany, and Brazil.

Canada was ranked seventh, followed by South Korea, the United States, and Taiwan as number ten.

In the third quarter of 2024, Banking & Financial Services was the most targeted by DDoS attacks. Information Technology & Services was ranked in second place, followed by the Telecommunications, Service Providers, and Carriers sector.

Cryptocurrency, Internet, Gambling & Casinos, and Gaming followed closely behind as the next most targeted industries. Consumer Electronics, Construction & Civil Engineering, and the Retail industries rounded out the top ten most attacked industries.

For a few years now, we’ve been surveying our customers that have been subjected to DDoS attacks. The survey covers various factors, such as the nature of the attack and the threat actors. In the case of threat actors, while 80% of survey respondents said that they don’t know who attacked them, 20% said they did. Of those, 32% said that the threat actors were extortionists. Another 25% said a competitor attacked them, and another 21% said that a disgruntled customer or user was behind the attack. 14% of respondents said that the attacks were carried out by a state or a state-sponsored group. Lastly, 7% said that they mistakenly attacked themselves. One example of when a self-DDoS attack occurs is a post-firmware update for IoT devices that causes all devices to phone home at the same time, resulting in a flood of traffic.

^{Distribution of the top threat actors}

While extortionists were the most common threat actor, overall, reports of Ransom DDoS attacks decreased by 42% QoQ, but increased 17% YoY. A total of 7% of respondents reported being subjected to a Ransom DDoS attack or threatened by the attacker. In August, however, that figure increased to 10% — that’s one out of ten.

^{Reports of Ransom DDoS attacks by quarter}

Indonesia was the largest source of DDoS attacks in the third quarter of 2024. The Netherlands was the second-largest source, followed by Germany, Argentina, and Colombia.

The next five largest sources included Singapore, Hong Kong, Russia, Finland, and Ukraine.

For service providers that operate their own networks and infrastructure, it can be difficult to identify who is using their infrastructure for malicious intent, such as generating DDoS attacks. For this reason, we provide a free threat intelligence feed to network operators. This feed provides service providers information on IP addresses from within their networks that we’ve seen participate in subsequent DDoS attacks.

On that note, Hetzner (AS24940), a German-based IT provider, was the largest source of HTTP DDoS attacks in the third quarter of 2024. Linode (AS63949), a cloud computing platform acquired by Akamai in 2022, was the second-largest source of HTTP DDoS attacks. Vultr (AS64515), a Florida-based service provider, came in third place.

Netcup (AS197540), another German-based IT provider, came in fourth place. Google Cloud Platform (AS15169) followed in fifth place. DigitalOcean (AS14061) came in sixth place, followed by French provider OVH (AS16276), Stark Industries (AS44477), Amazon Web Services (AS16509), and Microsoft (AS8075).

^{Networks that were that largest sources of HTTP DDoS attacks in 2024 Q3}

This quarter, we observed an unprecedented surge in hyper-volumetric DDoS attacks, with peaks reaching 3.8 Tbps and 2.2 Bpps. This mirrors a similar trend from the same period last year, when application layer attacks in the HTTP/2 Rapid Reset campaign exceeded 200 million requests per second (Mrps). These massive attacks are capable of overwhelming Internet properties, particularly those relying on capacity-limited cloud services or on-premise solutions.

The increasing use of powerful botnets, fueled by geopolitical tensions and global events, is expanding the range of organizations at risk — many of which were not traditionally considered prime targets for DDoS attacks. Unfortunately, too many organizations reactively deploy DDoS protections after an attack has already caused significant damage.

Our observations confirm that businesses with well-prepared, comprehensive security strategies are far more resilient against these cyberthreats. At Cloudflare, we’re committed to safeguarding your Internet presence. Through significant investment in our automated defenses and a robust portfolio of security products, we ensure proactive protection against both current and emerging threats — so you don’t have to.

Our always-on DDoS protection runs inside every server across our global network.  It constantly analyzes incoming traffic, looking for signals associated with previously identified DDoS attacks. We dynamically create fingerprints to flag malicious traffic, which is dropped when detected in high enough volume — so it never reaches its destination — keeping customer websites online.

In many cases, flagging bad traffic can be straightforward. For example, if we see too many requests to a destination with the same protocol violation, we can be fairly sure this is an automated script, rather than a surge of requests from a legitimate web browser.

Our DDoS systems are great at detecting attacks, but there’s a minor catch. Much like the human immune system, they are great at spotting attacks similar to things they have seen before. But for new and novel threats, they need a little help knowing what to look for, which is an expensive and time-consuming human endeavor.

Cloudflare protects millions of Internet properties, and we serve over 60 million HTTP requests per second on average, so trying to find unmitigated attacks in such a huge volume of traffic is a daunting task. In order to protect the smallest of companies, we need a way to find unmitigated attacks that may only be a few thousand requests per second, as even these can be enough to take smaller sites offline.

To better protect our customers, we also have a system to automatically identify unmitigated, or partially mitigated DDoS attacks, so we can better shore up our defenses against emerging threats. In this post we will introduce this anomaly detection pipeline, we’ll provide an overview of how it builds statistical models which flag unusual traffic and keep our customers safe. Let’s jump in!

A DDoS attack, by definition, is characterized by a higher than normal volume of traffic destined for a particular destination. We can use this fact to loosely sketch out a potential approach. Let’s look at an example website, and look at the request volume over the course of a day, broken down into 1 minute intervals.

We can plot this same data as a histogram:

The data follows a bell-shaped curve, also known as a normal distribution. We can use this fact to flag observations which appear outside the usual range. By first calculating the mean and standard deviation of our dataset, we can then use these values to rate new observations by calculating how many standard deviations (or sigma) the data is from the mean.

This value is also called the z-score — a z-score of 3 is the same as 3-sigma, which corresponds to 3 standard deviations from the mean. A data point with a high enough z-score is sufficiently unusual that it might signal an attack. Since the mean and standard deviation are stationary, we can calculate a request volume threshold for each z-score value, and use traffic volumes above these thresholds to signal an ongoing attack.

^{Trigger thresholds for z-score of 3, 4 and 5}

Unfortunately, it’s incredibly rare to see traffic that is this uniform in practice, as user load will naturally vary over a day. Here I’ve simulated some traffic for a website which runs a meal delivery service, and as you might expect it has big peaks around meal times, and low traffic overnight since it only operates in a single country.

Our volume data no longer follows a normal distribution and our 3-sigma threshold is now much further away, so smaller attacks could pass undetected.

Many websites elastically scale their underlying hardware based upon anticipated load to save on costs. In the example above the website operator would run far fewer servers overnight, when the anticipated load is low, to save on running costs. This makes the website more vulnerable to attacks during off-peak hours as there would be less hardware to absorb them. An attack as low as a few hundred requests per minute may be enough to overwhelm the site early in the morning, even though the peak-time infrastructure could easily absorb this volume.

This approach relies on traffic volume being stable over time, meaning it’s roughly flat throughout the day, but this is rarely true in practice. Even when it is true, benign increases in traffic are common, such as an e-commerce site running a Black Friday sale. In this situation, a website would expect a surge in traffic that our model wouldn’t anticipate, and we may incorrectly flag real shoppers as attackers.

It turns out this approach makes too many naive assumptions about what traffic should look like, so it’s impossible to choose an appropriate sigma threshold which works well for all customers.

Let’s continue with trying to determine a volumetric baseline for our meal delivery example. A reasonable assumption we could add is that yesterday’s traffic shape should approximate the expected shape of traffic today. This idea is called “seasonality”. Weekly seasonality is also pretty common, i.e. websites see more or less traffic on certain weekdays or on weekends.

There are many methods designed to analyze a dataset, unpick the varying horizons of seasonality within it, and then build an appropriate predictive model. We won’t go into them here but reading about Seasonal ARIMA (SARIMA) is a good place to start if you are looking for further information.

There are three main challenges that make SARIMA methods unsuitable for our purposes. First is that in order to get a good idea of seasonality, you need a lot of data. To predict weekly seasonality, you need at least a few weeks worth of data. We’d require a massive dataset to predict monthly, or even annual, patterns (such as Black Friday). This means new customers wouldn’t be protected until they’d been with us for multiple years, so this isn’t a particularly practical approach.

The second issue is the cost of training models. In order to maintain good accuracy, time series models need to be frequently retrained. The exact frequency varies between methods, but in the worst cases, a model is only good for 2–3 inferences, meaning we’d need to retrain all our models every 10–20 minutes. This is feasible, but it’s incredibly wasteful.

The third hurdle is the hardest to work around, and is the reason why a purely volumetric model doesn’t work. Most websites experience completely benign spikes in traffic that lie outside prior norms. Flash sales are one such example, or 1,000,000 visitors driven to a site from Reddit, or a Super Bowl commercial.

So if volumetric modeling won’t work, what can we do instead? Fortunately, volume isn’t the only axis we can use to measure traffic. Consider the end users’ browsers for example. It would be reasonable to assume that over a given time interval, the proportion of users across the top 5 browsers would remain reasonably stationary, or at least within a predictable range. More importantly, this proportion is unlikely to change too much during benign traffic surges.

Through careful analysis we were able to discover about a dozen such variables with the following features for a given zone: 

• They follow a normal distribution

• They aren’t correlated, or are only loosely correlated with volume

• They deviate from the underlying normal distribution during “under attack” events

Recall our initial volume model, where we used z-score to define a cutoff. We can expand this same idea to multiple dimensions. We have a dozen different time series (each feature is a single time series), which we can imagine as a cloud of points in 12 dimensions. Here is a sample showing 3 such features, with each point representing the traffic readings at a different point in time. Note that both graphs show the same cloud of points from two different angles.

To use our z-score analogy from before, we’d want our points to be spherical, since our multidimensional- z-score is then just the distance from the centre of the cloud. We could then use this distance to define a cutoff threshold for attacks.

For several reasons, a perfect sphere is unlikely in practice. Our various features measure different things, so they have very different scales of ‘normal’. One property might vary between 100-300 whereas another property might usually occupy the interval 0-1. A change of 3 in this latter property would be a significant anomaly, whereas in the first this would just be within the normal range.

More subtly, two or more axes may be correlated, so an increase in one is usually mirrored with a proportional increase/decrease in another dimension. This turns our sphere into an off-axis disc shape, as pictured above.

Fortunately, we have a couple of mathematical tricks up our sleeve. The first is scale normalization. In each of our n dimensions, we subtract the mean, and divide by the standard deviation. This makes all our dimensions the same size and centres them around zero. This gives a multidimensional analogue of z-score, but it won’t fix the disc shape.

What we can do is figure out the orientation and dimensions of the disc, and for this we use a tool called Principal Component Analysis (PCA). This lets us reorient our disc, and rescale the axes according to their size, to make them all the same.

Imagine grabbing the disc out of the air, then drawing new X and Y axes on the top surface, with the origin at the center of the disc. Our new Z-axis is the thickness of the disc. We can compare the thickness to the diameter of the disc, to give us a scaling factor for the Z direction. Imagine stretching the disc along the z-axis until it’s as tall as the length across the diameter.

In reality there’s nothing to say that X & Y have to be the same size either, but hopefully you get the general idea. PCA lets us draw new axes along these lines of correlation in an arbitrary number of dimensions, and convert our n-dimensional disc into a nicely behaved sphere of points (technically an n-dimensional sphere).

Having done all this work, we can uniquely define a coordinate transformation which takes any measurement from our raw features, and tells us where it should lie in the sphere, and since all our dimensions are the same size we can generate an anomaly score purely based on its distance from the centre of the cloud.

As a final trick, we can also use a final scaling operation to ensure the sphere for dataset A is the same size as the sphere generated from dataset B, meaning we can do this same process for any traffic data and define a cutoff distance λ which is the same across all our models. Rather than fine-tuning models for each individual customer zone, we can tune this to a value which applies globally.

Another name for this measurement is Mahalanobis distance. (Inclined readers can understand this equivalence by considering the role of the covariance matrix in PCA and Mahalanobis distance. Further discussion can be found on this StackExchange post.) We further tune the process to discard dimensions with little variance — if our disc is too thin we discard the thickness dimension.  In practice, such dimensions were too sensitive to be useful.

We’re left with a multidimensional analogue of the z-score we started with, but this time our variables aren’t correlated with peacetime traffic volume. Above we show 2 output dimensions, with coloured circles which show Mahalanobis distances of 4, 5 and 6. Anything outside the green circle will be classified as an attack.

The approach we’ve outlined is incredibly parallelizable: a single model requires only the traffic data for that one website, and the datasets needed can be quite small. We use 4 weeks of training data chunked into 5 minute intervals which is only ~8k rows/website.

We run all our training and inference in an Apache Airflow deployment in Kubernetes. Due to the parallelizability, we can scale horizontally as needed. On average, we can train about 3 models/second/thread. We currently retrain models every day, but we’ve observed very little intraday model drift (i.e. yesterday’s model is the same as today’s), so training frequency may be reduced in the future.

We don’t consider it necessary to build models for all our customers, instead we train models for a large sample of representative customers, including a large number on the Free plan. The goal is to identify attacks for further study which we then use to tune our existing DDoS systems for all customers.

If you’ve read this far you may have questions, like “how do you filter attacks from your training data?” or you may have spotted a handful of other technical details which I’ve elided to keep this post accessible to a general audience. If so, you would fit in well here at Cloudflare. We’re helping to build a better Internet, and we’re hiring.

^{A mitigated 3.8 Terabits per second DDoS attack that lasted 65 seconds}

^{A mitigated 2.14 billion packet per second DDoS attack that lasted 60 seconds}

Cloudflare customers using Cloudflare’s HTTP reverse proxy services (e.g. Cloudflare WAF and Cloudflare CDN) are automatically protected.

Cloudflare customers using Spectrum and Magic Transit are also automatically protected. Magic Transit customers can further optimize their protection by deploying Magic Firewall rules to enforce a strict positive and negative security model at the packet layer.

The scale and frequency of these attacks are unprecedented. Due to their sheer size and bits/packets per second rates, these attacks have the ability to take down unprotected Internet properties, as well as Internet properties that are protected by on-premise equipment or by cloud providers that just don’t have sufficient network capacity or global coverage to be able to handle these volumes alongside legitimate traffic without impacting performance. 

Cloudflare, however, does have the network capacity, global coverage, and intelligent systems needed to absorb and automatically mitigate these monstrous attacks. 

In this blog post, we will review the attack campaign and why its attacks are so severe. We will describe the anatomy of a Layer 3/4 DDoS attack, its objectives, and how attacks are generated. We will then proceed to detail how Cloudflare’s systems were able to autonomously detect and mitigate these monstrous attacks without impacting performance for our customers. We will describe the key aspects of our defenses, starting with how our systems generate real-time (dynamic) signatures to match the attack traffic all the way to how we leverage kernel features to drop packets at wire-speed.

We have observed this attack campaign targeting multiple customers in the financial services, Internet, and telecommunication industries, among others. This attack campaign targets bandwidth saturation as well as resource exhaustion of in-line applications and devices.

The attacks predominantly leverage UDP on a fixed port, and originated from across the globe with larger shares coming from Vietnam, Russia, Brazil, Spain, and the US. 

The high packet rate attacks appear to originate from multiple types of compromised devices, including MikroTik devices, DVRs, and Web servers, orchestrated to work in tandem and flood the target with exceptionally large volumes of traffic. The high bitrate attacks appear to originate from a large number of compromised ASUS home routers, likely exploited using a CVE 9.8 (Critical) vulnerability that was recently discovered by Censys.

^{Share of packets observed by source location}

Before we discuss how Cloudflare automatically detected and mitigated the largest DDoS attacks ever seen, it‘s important to understand the basics of DDoS attacks. 

^{Simplified diagram of a DDoS attack}

The goal of a Distributed Denial of Service (DDoS) attack is to deny legitimate users access to a service. This is usually done by exhausting resources needed to provide the service. In the context of these recent Layer 3/4 DDoS attacks, that resource is CPU cycles and network bandwidth.

Processing a packet consumes CPU cycles. In the case of regular (non-attack) traffic, a legitimate packet received by a service will cause that service to perform some action, and different actions require different amounts of CPU processing. However, before a packet is even delivered to a service there is per-packet work that needs to be done. Layer 3 packet headers need to be parsed and processed to deliver the packet to the correct machine and interface. Layer 4 packet headers need to be processed and routed to the correct socket (if any). There may be multiple additional processing steps that inspect every packet. Therefore, if an attacker sends at a high enough packet rate, then they can potentially saturate the available CPU resources, denying service to legitimate users.

To defend against high packet rate attacks, you need to be able to inspect and discard the bad packets using as few CPU cycles as possible, leaving enough CPU to process the good packets. You can additionally acquire more, or faster, CPUs to perform the processing — but that can be a very lengthy process that bears high costs. 

Network bandwidth is the total amount of data per time that can be delivered to a server. You can think of bandwidth like a pipe to transport water. The amount of water we can deliver through a drinking straw is less than what we could deliver through a garden hose. If an attacker is able to push more garbage data into the pipe than it can deliver, then both the bad data and the good data will be discarded upstream, at the entrance to the pipe, and the DDoS is therefore successful.

Defending against attacks that can saturate network bandwidth can be difficult because there is very little that can be done if you are on the downstream side of the saturated pipe. There are really only a few choices: you can get a bigger pipe, you can potentially find a way to move the good traffic to a new pipe that isn’t saturated, or you can hopefully ask the upstream side of the pipe to stop sending some or all of the data into the pipe.

If we think about what this means from the attackers point of view you realize there are similar constraints. Just as it takes CPU cycles to receive a packet, it also takes CPU cycles to create a packet. If, for example, the cost to send and receive a packet were equal, then the attacker would need an equal amount of CPU power to generate the attack as we would need to defend against it. In most cases this is not true — there is a cost asymmetry, as the attacker is able to generate packets using fewer CPU cycles than it takes to receive those packets. However, it is worth noting that generating attacks is not free and can require a large amount of CPU power.

Saturating network bandwidth can be even more difficult for an attacker. Here the attacker needs to be able to output more bandwidth than the target service has allocated. They actually need to be able to exceed the capacity of the receiving service. This is so difficult that the most common way to achieve a network bandwidth attack is to use a reflection/amplification attack method, for example a DNS Amplification attack. These attacks allow the attacker to send a small packet to an intermediate service, and the intermediate service will send a large packet to the victim.

In both scenarios, the attacker needs to acquire or gain access to many devices to generate the attack. These devices can be acquired in a number of different ways. They may be server class machines from cloud providers or hosting services, or they can be compromised devices like DVRs, routers, and webcams that have been infected with the attacker’s malware. These machines together form the botnet.

Now that we understand the fundamentals of how DDoS attacks work, we can explain how Cloudflare can defend against these attacks.

The first not-so-secret ingredient is that Cloudflare’s network is built on anycast. In brief, anycast allows a single IP address to be advertised by multiple machines around the world. A packet sent to that IP address will be served by the closest machine. This means when an attacker uses their distributed botnet to launch an attack, the attack will be received in a distributed manner across the Cloudflare network. An infected DVR in Dallas, Texas will send packets to a Cloudflare server in Dallas. An infected webcam in London will send packets to a Cloudflare server in London.

^{Anycast vs. Unicast networks}

Our anycast network additionally allows Cloudflare to allocate compute and bandwidth resources closest to the regions that need them the most. Densely populated regions will generate larger amounts of legitimate traffic, and the data centers placed in those regions will have more bandwidth and CPU resources to meet those needs. Sparsely populated regions will naturally generate less legitimate traffic, so Cloudflare data centers in those regions can be sized appropriately. Since attack traffic is mainly coming from compromised devices, those devices will tend to be distributed in a manner that matches normal traffic flows sending the attack traffic proportionally to datacenters that can handle it. And similarly, within the datacenter, traffic is distributed across multiple machines.

Additionally, for high bandwidth attacks, Cloudflare’s network has another advantage. A large proportion of traffic on the Cloudflare network does not consume bandwidth in a symmetrical manner. For example, an HTTP request to get a webpage from a site behind Cloudflare will be a relatively small incoming packet, but produce a larger amount of outgoing traffic back to the client. This means that the Cloudflare network tends to egress far more legitimate traffic than we receive. However, the network links and bandwidth allocated are symmetrical, meaning there is an abundance of ingress bandwidth available to receive volumetric attack traffic.

By the time you’ve reached an individual server inside a datacenter, the bandwidth of the attack has been distributed enough that none of the upstream links are saturated. That doesn’t mean the attack has been fully stopped yet, since we haven’t dropped the bad packets. To do that, we need to sample traffic, qualify an attack, and create rules to block the bad packets. 

Sampling traffic and dropping bad packets is the job of our l4drop component, which uses XDP (eXpress Data Path) and leverages an extended version of the Berkeley Packet Filter known as eBPF (extended BPF). This enables us to execute custom code in kernel space and process (drop, forward, or modify) each packet directly at the network interface card (NIC) level. This component helps the system drop packets efficiently without consuming excessive CPU resources on the machine. 

^{Cloudflare DDoS protection system overview}

We use XDP to sample packets to look for suspicious attributes that indicate an attack. The samples include fields such as the source IP, source port, destination IP, destination port, protocol, TCP flags, sequence number, options, packet rate and more. This analysis is conducted by the denial of service daemon (dosd). Dosd holds our secret sauce. It has many filters which instruct it, based on our curated heuristics, when to initiate mitigation. To our customers, these filters are logically grouped by attack vectors and exposed as the DDoS Managed Rules. Our customers can customize their behavior to some extent, as needed.

As it receives samples from XDP, dosd will generate multiple permutations of fingerprints for suspicious traffic patterns. Then, using a data streaming algorithm, dosd will identify the most optimal fingerprints to mitigate the attack. Once an attack is qualified, dosd will push a mitigation rule inline as an eBPF program to surgically drop the attack traffic. 

The detection and mitigation of attacks by dosd is done at the server level, at the data center level and at the global level — and it’s all software defined. This makes our network extremely resilient and leads to almost instant mitigation. There are no out-of-path “scrubbing centers” or “scrubbing devices”. Instead, each server runs the full stack of the Cloudflare product suite including the DDoS detection and mitigation component. And it is all done autonomously. Each server also gossips (multicasts) mitigation instructions within a data center between servers, and globally between data centers. This ensures that whether an attack is localized or globally distributed, dosd will have already installed mitigation rules inline to ensure a robust mitigation.

Our software-defined, autonomous DDoS detection and mitigation systems run across our entire network. In this post we focused mainly on our dynamic fingerprinting capabilities, but our arsenal of defense systems is much larger. The Advanced TCP Protection system and Advanced DNS Protection system work alongside our dynamic fingerprinting to identify sophisticated and highly randomized TCP-based DDoS attacks and also leverages statistical analysis to thwart complex DNS-based DDoS attacks. Our defenses also incorporate real-time threat intelligence, traffic profiling, and machine learning classification as part of our Adaptive DDoS Protection to mitigate traffic anomalies. 

Together, these systems, alongside the full breadth of the Cloudflare Security portfolio, are built atop of the Cloudflare network — one of the largest networks in the world — to ensure our customers are protected from the largest attacks in the world.