This article is primarily intended for an international audience of networks professionals, information security specialists, security researchers and technical stakeholders. Whether or not you belong to the target audience, but particularly if you do not, please be mindful of your conclusions.

Table of Contents

• 1. Introduction
• 2. Carpet-bombing is more popular than ever
• 3. The rise of packet rate attacks: billion(s) of packets per second
• 4. Ever-growing hyper-volumetric attacks: 4 Tbps reached
• 5. Institutional and residential ISPs spoofing
• 6. Operation PowerOFF and consequences
• 7. Conclusion and closing words

1. Introduction

Welcome to this brief retrospective about the DDoS attack landscape in 2024, as seen from OVHcloud’s vantage point.

Like any other cloud provider, we deal with DDoS attacks on a daily basis, automatically detecting and mitigating hundreds of attacks each and every day. We operate our own worldwide anti-DDoS infrastructure, built from systems designed and developped internally. To date, we have more than 50 Tbps of total mitigation capacity, located at the edge of our network as well as in dedicated scrubbing centers, for which we keep adding more capacity each year to keep up the pace.

Thanks to our global backbone and numerous points of presence, we do have a sensible view of Internet traffic and trends, especially when speaking about network-layer DDoS attacks. That’s why we wanted to expose and discuss several topics we encountered during the year, in the hope you may learn something or find it useful for your own sake.

Context aside, let’s dive into this retrospective: what a year! 2024 was definitely an important turning point in DDoS history, at least from our point of view. From good’ol DDoS techniques coming back at scale, to several record-breaking attacks, we’ve seen quite a lot, and no one doubts that 2024 events will be the main driving factor for anti-DDoS infrastructure planning in the coming years.

2. Carpet-bombing is more popular than ever

During the year 2024, we observed a sudden increase of attacks leveraging a technique known as “carpet-bombing”. This attack technique is named after a brutal warfare method which consists in methodically bombing every bit of surface of a large area. Similarly, “carpet-bombing” in our context refers to attacks targeting many more IP addresses than those servicing the actual target.

Carpet-bomb attacks are used in an attempt to evade anti-DDoS systems. This is because they are much harder to detect and mitigate automatically: by sending a few hundreds megabits per second per IP, attacker can reach huge volumes while evading (at least partially) detection heuristics and possible mitigation actions. Simply put, instead of trying hard to bomb a target, just bomb the whole area around it.

By targeting a large number of closely-related IPs (e.g., belonging to a larger prefix), attackers rely on common design characteristics of many networking infrastructures: you generally want to assign an address range to a physical or logical part of your infrastructure for several reasons. Briefly, this is often required because of technical limitations on networking devices and appliances, as well as what is humanly possible to understand and manage: whether for hardware or humans, you cannot store millions to billions entries in routing table, access control lists, etc. At some point, you must aggregate your resources.

Back to the main topic, carpet-bomb attacks are a double-edged sword: the part of the attack possibly reaching your final target will probably not be powerful enough to take it down, but you take a better chance at evading defenses. This is because it’s much more difficult to identify with confidence what is legitimate from what is not, but also to scrub traffic without impacting legitimate users. In the end, the total attack traffic leaking defenses may impact a significant chunk of the hosting infrastructure, even if traffic to any single destination IP would not have been enough to take it down.

2024 has been a turning point in carpet-bomb trends from our point of view. Attackers started to leverage this technique more and more often, with mixed results, and led us to rethink how to deal with such attacks. For some times now, we are testing and calibrating our solution to the issue, but need to treat carefully: facing such a radical threat may lead to actions which could be impactful for other customers. There’s a difficult balance between sensitivity (i.e., make sure you don’t detect or mitigate too much) versus specificity (i.e., make sure you don’t miss anything notable). We will keep working hard to address the matter and minimize disruption.

3. The rise of packet rate attacks: billion(s) of packets per second

In June 2024, we published a blog article titled “The Rise of Packet Rate Attacks: When Core Routers Turn Evil”.¹ This article was presenting our findings related to small core routers participating in DDoS attacks, and was a byproduct of our investigations about a concerning trend with packet rate attacks. Readers should refer to the cited article to have a detailed explanation of how they work, and why these attacks remain a longstanding threat.

Since the end of 2023 and beginning of 2024, we noticed a large increase of packet rate attacks both in frequency and intensity, with intensity reaching an all-time high at the end of summer.

During August, we dealt with more than 50 packet-rate attacks rating over one billion packets per second. Note that the highest publicly known packet rate attack at this time was the 840 Mpps attack we mitigated in April of the same year.

However, this attack campaign not only reached the billion packets per second milestone, but actually went much higher with packet rates up to 1.9 billions packets per second. Such a rate was mind-blowing for our teams, and rightly so! A symbolic threshold was not only reached, but largely exceeded. Since then, several organizations reported observing 1+ Gpps attacks and more: for instance, Cloudflare reported rates greater than 2 billions packets per second ² in an attack campaign which occurred just a few days after the attack campaign targeting OVHcloud and its customers, while Global Secure Layer reported a single 3.15 billions packets per second attack at the same time.³

Before moving on to the next topic, a notable fact related to this attack campaign is that it was heavily leveraging carpet-bombing techniques targeting up to thousands of IPs over hundreds of customers. Attackers are definitely not scared about trying to impact a lot of people in an attempt to take down a specific service, despite the increased attention this kind of attack generates.

4. Ever-growing hyper-volumetric attacks: 4 Tbps reached

During the month of September, we were thrilled to mitigate our very first 3+ Tbps attack ever. However, it was just a warning shot for what was to come: another massive attack campaign during October. Although we had only seen a handful of 2+ Tbps attacks in OVHcloud history, this two weeks campaign led to more than 40 attacks ranging from 2 Tbps up to a record-breaking (at the time) 4.2 Tbps attack.

Since most attacks exhibited similar characteristics, we will focus on the biggest one. At the time it happened, this attack was the largest bit rate attack ever (compared to previous publicly known records). It leveraged multiple attack vectors at once : TCP ACK flood accounted for ~60% of the total traffic, direct-path UDP flood accounted for 20%, while the remaining 20% was performed with various UDP reflections (mostly DNS).

We identified approximately 150,000 source IPs, mostly owned by residential ISPs from Europe and North America. For the most part, attackers did not seem to leverage source spoofing, since our data shows that traffic from IPs belonging to an ISP came from direct peering with said ISP or a related exchange/transit provider. However, the surprising amount of unique source IPs and the significant volume going through exchange/transit suggest there is possibly some undetected spoofing. Total count of unique source IPs should thus be considered with a lot of salt.

One notable thing also is that few tens of attacking IPs were sending 1+ Gbps each, which suggests high-grade residential connections with lot of upload bandwidth. Moreover, according to our analysis, all the direct-path attack traffic (approximately 80% of total) was originating from a Mirai-based botnet.

All these findings are in-line with conclusions from various cloud providers and analysts, showing the continuously growing threat of compromised IoT devices and home routers. 8 years after the initial release of Mirai code, this botnet family is still actively used to attempt disrupting the online economy.

Readers should note that since the 4.2 Tbps attack we just discussed, several actors reported even higher rates such as the 5.6 Tbps at Cloudflare in late 2024 ⁴, or the more recent 6.5 Tbps attack reported by Nokia in February 2025.⁵

5. Institutional and residential ISPs spoofing

Last but not least, we also observed another growing trend during the year: the large-scale spoofing of major residential ISPs.

We are used seeing many IPs belonging to residential ISPs participating in attacks, as a lot of compromised devices are located within those networks (“I see you.. Internet of Things!“). However we observed a growing number of attacks using those IPs, but originating from far abroad: for instance, we found traffic using IPs of major French ISPs (Orange, SFR, Bouygues, Free) but originating from the US west coast or Asia-Pacific, and coming through unrelated peering partners (despite us directly peering with said ISPs!). In this situation, source IPs are obviously spoofed.

We also observed the same technique being used by spoofing large institutional actors, such as state actors or government-backed organizations which own several Internet prefixes.

An explanation about these attacks is that attackers are trying to leverage hypothetical bypasses in defense layers such as lax rate control, allow/forward rules, and others. This makes sense because, as a major european actor based in France (with a significant business in France), we could have considered being less strict with French IPs. It’s also much harder to react against an attack that could lead to actions shutting down legitimate traffic as well, which will be the case if one decides to deny entire ranges against such attacks (we don’t do that!).

Moreover, we sometimes have customers asking us to disable any DDoS protections for their IPs, because “we can trust them”. But that’s not how the Internet works. As a provider, protecting yourself against external spoofing is maybe doable on paper, but in reality, it’s close to impossible. That’s why we have security measures, and bypassing them even with the best intent will often prove itself as a bad decision, not only for the requesting customers but also for any other services which could be impacted because of this.

Finally, this issue highlights a crucial need for DDoS attacks remediation: all network operators have a part to play in preventing IP spoofing. This shall be done at two levels: at server/switch level by locally preventing IP spoofing from a specific host, and at the network level by preventing outbound traffic with source IPs not owned by the network operator.

6. Operation PowerOFF and consequences

Operation PowerOFF is an ongoing joint operation by several law enforcement agencies around the world, specifically aimed at shutting down DDoS-for-hire operations. At the beginning of November 2024, they closed the infamous dstatc.cc platform, which provided means for attackers to benchmark the capabilities and effectiveness of DDoS attacks. Along with this closure, multiple DDoS-for-hire websites were closed, botnets dismantled, and cybercriminals arrested.⁶

This event led to a huge decline in frequency and intensity of network-layer DDoS attacks targeting OVHcloud infrastructures and customers. For some time, our attack statistics were quite below their usual levels of the past two years. This fact proves the effectiveness of global coordinated actions to take down botnets, and should call for more.

7. Conclusion and closing words

In the past, network-layer DDoS attacks were often dismissed as a minor inconvenience, or even a solved problem. However, as year 2024 proved, they still represent a growing and longstanding threat which must be addressed seriously. That’s one reason why DDoS attacks are often stated in threat reports emanating from various actors, such as a recent threat report published by the French national information security agency (ANSSI) in February 2025.⁷

Although application-layer attacks (especially HTTPS) are more popular nowadays for several reasons, no one should dismiss network-layer attacks as an unsignificant risk. If dealing successfully with billions of packets per second or several terabits of traffic may seem like an achievement for a few of us, it is a very difficult challenge for many. Be prepared!

Fighting against these threats must be done at both an individual and a global level. Coordinated efforts are a necessity in today’s DDoS landscape and will probably be even more important in years to come. It may sound scary, but remember it actually has a positive impact as demonstrated once again by Operation PowerOFF.

Thanks for reading.

1. https://blog.ovhcloud.com/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/ ↩︎
2. https://blog.cloudflare.com/ddos-threat-report-for-2024-q3/ ↩︎
3. https://globalsecurelayer.com/blog/unprecedented-3-15-billion-packet-rate-ddos-attack ↩︎
4. https://blog.cloudflare.com/ddos-threat-report-for-2024-q4/ ↩︎
5. https://arstechnica.com/security/2025/03/massive-botnet-that-appeared-overnight-is-delivering-record-size-ddoses/ ↩︎
6. https://www.europol.europa.eu/media-press/newsroom/news/law-enforcement-shuts-down-27-ddos-booters-ahead-of-annual-christmas-attacks ↩︎
7. https://www.cert.ssi.gouv.fr/cti/CERTFR-2025-CTI-001/ ↩︎

2024-07-04 – Edit: We are currently working with MikroTik

A sharp increase of DDoS attacks have been observed since the beginning of 2023. A new trend is to send high packet rate attacks though. This article introduces the findings of our teams in order to bring new insights regarding this threat.

Introduction

Distributed Denial of Services attacks (DDoS) are a longstanding issue which remains an effective way to impact the availability of an online service. Over the past decade, several actors demonstrated how easily they could raise an army of zombie devices with their botnet using a wide range of techniques, from using phishing to install malware on a desktop host up to leveraging different kind of vulnerabilities affecting IoT devices, CCTV, or residential routers.

These botnets have been largely used to send DDoS attacks using tens of thousands of compromised devices all around the world. The patterns of attack were often the same: just craft as many packets as you can in an attempt to reach the highest possible bit rate (or packet rate) to cripple your target’s networking capabilities. This is what happened with the Mirai botnet back in 2016 which has been the first one to generate more than 1 Tbps (Terabit per second). Since then, several botnets have far surpassed the original Mirai up to 3.47 Tbps in 2021. However, 1+ Tbps attacks remained quite rare… until recently.

Since the beginning of 2023, we noticed a sharp increase of DDoS attacks, both in frequency and intensity. Moreover, starting from November of the same year, a significant acceleration of the trend has been observed by our teams at OVHcloud: while DDoS reaching 1 Tbps or above were occasional, they aren’t anymore. In the past 18 months, we went from 1+ Tbps attacks being quite rare, then weekly, to almost daily (averaged out over one week). The highest bit rate we observed during that period was ~2.5 Tbps.

Interestingly, the recent announcement of the 911 S5 Botnet dismantling between May 25^th and May, 30^th 2024 loosely coincides with a significant decline of DDoS attacks, which started by mid of May. However, we cannot affirm with certainty these events are linked together.

While attacks frequency is seemingly back to normal, we are still observing a large amount of DDoS attacks involving packet rates greater than 100 Mpps (Millions packets per second).

What about packet rate attacks?

Usually, most DDoS attacks rely on sending a lot of garbage data to sature the bandwidth (network-layer attacks) or sending a lot of application requests to cause excessive CPU or memory usage (application-layer attacks). Of course there are other methods to leverage: among those are packet rate attacks or packets per second based attacks.

Packet rate attacks objective is to overload the packet processing engines of networking devices close to the destination, instead of starving the available bandwidth. The general idea is to cripple the infrastructures in front of the targeted service (e.g., load-balancers, anti-DDoS systems, …), thus possibly impacting a large infrastructure as collateral damage. Simply put: instead of trying to find holes in anti-DDoS systems, just take them down!

Packet rate attacks are quite effective since dealing with a lot of small packets is usually harder than dealing with bigger but less numerous packets. This is because the computing cost is generally higher. For instance, if you’re using software to process packets, each packet means one memory access at the very least (excluding possible copy, access to stored data such as connection tables, …), instead of simply iterating over more bytes. If you’re using hardware, while packet processing performances are not necessarily affected by the packet rate, the processing pipeline probably depends on other components, such as memory (again!), which could be stressed a lot by high packet rates. In those conditions, you may reach some limits due to the very high rate or just because you don’t have enough buffers to store it all, which will probably induce latency or performance losses. We can summarize this problem into a single sentence: if your job is to deal mostly with payloads, bandwidth may be the hard limit ; but if your job is to deal mostly with packet headers, packet rate is the hard limit.

That’s why in most conditions, dealing with small packets is harder than dealing with big packets. In a nutshell, a 10 Gbps DDoS attack with big packets (1480 bytes) yields ~0.85 Mpps: in comparison, 10 Gbps with the smallest packets (84 bytes on wire for Ethernet) yields a massive ~14.88 Mpps.

In the context of standard Internet MTU (1500), you can fit 17 times more packets on wire when generating only the smallest packets possible, compared to big packets. To give an idea of the computing capabilities needed in the context of DDoS mitigation, consider a 100 Gbps link will fit ~149 Mpps line-rate: this allows up to 6 nanoseconds of processing time per packet, or 18 cycles for a single compute pipeline running at 3 GHz clock speed. Saying it otherwise: even with tens of parallel pipelines, you don’t have many cycles available, especially if you need to access some memory.

As a side note, this is one of the reason why OVHcloud is building its own networking appliances for DDoS infrastructures. We use a combination of FPGA and userland software (DPDK) to build appliances with off-the-shelf hardware. Each network appliance used to mitigate DDoS attacks is designed, implemented and maintained in-house (just like the rest of our anti-DDoS systems by the way!). Thanks to this streamlined approach, we are able to finely adjust performance expectations and constraints, then ensure our appliances match accordingly.

The rise of (big) packet rate attacks

DDoS attacks relying on high packet rate are not new and network operators all over the world had to face such attacks at least once. As an example, the highest publicly-known packet rate attack was reported by Akamai in 2020 and reached 809 Mpps. However, despite this big figure, a vast majority of packet rate attacks are well below 100 Mpps. This is probably because generating a lot of small packets is harder than generating big ones (you need much more compute – similarly to processing) and is harder to hide from network monitoring and anti-abuse systems.

Packet rate attacks started to seriously get some attention at OVHcloud two years ago, after we were hit —  but successfully mitigated —  by a gigantic UDP flood for more than 6 hours, reaching ~700 Mpps in average for ~4 hours.

In the past 18 months, and especially in the past 6 months, we noticed a sharp increase of DDoS attacks leveraging packet rates greater than 100 Mpps. We went from mitigating few of them each week, to tens or even hundreds per week. Our infrastructures had to mitigate several 500+ Mpps attacks at the beginning of 2024, including one peaking at 620 Mpps. In April 2024, we even mitigated a record-breaking DDoS attack reaching ~840 Mpps, just above the previous record reported by Akamai.

This attack was 99% of TCP ACK, originating from approximately 5,000 source IPs. Interestingly, the 1% remainder was a DNS reflection attack, leveraging ~15,000 DNS servers to amplify the traffic, which is not really efficient when trying to achieve high packet rate attacks.

While the attack was distributed worldwide, 2/3 of total packets entered from only 4 PoPs, all located in the US with 3 of them being on the west coast. This highlights the capability of the adversary to send a huge packet rate through only few peerings, which can prove very problematic. Generally, anti-DDoS response teams — not only at OVHcloud — assumes that it’s really hard to send massive DDoS from only few geographical locations. Based on this assumption, our infrastructures are scaled horizontally, spread worldwide, and they absorb the load more easily. However, the traffic distribution of the 840 Mpps attack has strongly questioned this assumption. While we do have the local capacity to mitigate this attack, we will consider to adjust the general scaling and distribution model of our anti-DDoS infrastructures to ensure to cope with future (and probably bigger) attacks, just as we do today.

In the end, the significant rise of high packet rate attacks led us to deep dive the topic. As a worldwide cloud provider, OVHcloud is scrubbing many DDoS attacks on a daily basis, which gives us an exceptional vantage point on this topic. We wanted to understand how these attacks were generated, where they came from, and possibly determine what we could do to better protect our infrastructures and customers against this kind of firepower.

Unveiling evil core routers

During our analysis campaign, manually dissecting almost a hundred packet rate attacks ranging from 100 up to 500 Mpps, we noticed that many attacks originated from not-that-many sources, which are sending a large proportion of the total traffic. We established a list of well-known offending IPs capable of generating at least 1 Mpps each, and decided to dig further.

We analyzed the top 70 IPs issuing the highest packet rates, up to 14.8 Mpps per IP. These IPs belongs mostly to Autonomous Systems (AS) in Asia, but Europe, Middle-East, North American and South America are also represented. The ASs identified seem to belong mostly to business ISPs or Cloud Connectivity providers.

To understand what kind of devices were involved in these DDoS, we used Onyphe to determine if these IPs were known. Indeed, a great part of these IPs are known as MikroTik Routers and are exposing on the Internet — at least — the configuration webpage. 

At this point, it remains possible this traffic is generated either by servers located behind a router configured with NAT, using spoofed IP, or leveraging some kind of weird TCP reflection. However, we quickly dismissed these hypotheses due to the improbability of encountering such a significant number of identified MikroTik routers, given that MikroTik does not hold a proportionately large market share. In addition, exposing an administration interface reflects poor management practices. It increases the device’s attack surface and can facilitate its compromise by an attacker. Moreover, RouterOS — MikroTik’s operating system — has suffered from several critical CVE over the past years. Even if a patch has been released, these devices may have not been patched so far.

Since the HTTP interface is open on most of the devices, it is possible to use it to recover the version of RouterOS running on said devices. Half of them are running a RouterOS version prior to 6.49.8 – released on May, 23^rd. 2023 – and the other half is running a later version. For instance, devices running RouterOS 6.49.14 – released on Aprit, 4^th. 2024 – have been identified.

We have been surprised to discover devices with a recent firmware being potentially compromised though. As far as we know, no vulnerability affecting RouterOS 6.49.14 and later versions have been publicly published so far. A possible explanation would be these devices may have been patched after their compromission.

We can’t say yet why these devices are involved in coordinated DDoS attacks, but one possible hypothesis could be the “Bandwidth test” feature from RouterOS. It allows the administrator to test the real throughput of a router by crafting packets and perform stress tests. Coincidentally, the documentation states the following: “Up to RouterOS version 6.44beta39, Bandwidth Test used only single CPU core and reached its limits when core was 100% loaded. Bandwidth Test [now] uses all available bandwidth (by default) and may impact network usability“. This is quite interesting since we mostly identified RouterOS v6.44 or above among the offending IPs.

99,382 devices available on the Internet

Using SNMP on devices exposing it, we have been able to determine what kind of devices were capable to issue such a high packet rate. As expected these are not residential routers, but rather core network devices.

The results highlight the MikroTik CCR series, which stands for Cloud Core Router. Indeed, SNMP returned several CCR1036-8G-2S+ and CCR1072-1G-8S+.

In order to have an overview of how many devices could be compromised and used in such massive packet rate DDoS attacks, we used Onyphe once again to search for CCR devices wide open on the Internet. 99,382 CCR devices were identified.

We can see that both device models involved in the packet rate attacks observed by our teams – CCR1036-8G-2S+ and CCR1072-1G-8S+ – represents at least 40,000 devices open on the Internet. The CCR1036-8G-2S+ is the most found device on the Internet with 30,976 occurrences, and the CR1072-1G-8S+ is the 4^th most found device with 9,353 occurrences. Since we still don’t know what kind of vulnerability has been leveraged to compromise these device models, we can’t say yet whether other CCR models could be compromised as well or not. Nonetheless, exposing the administration panel on the Internet remains a big risk for the security of the device though.

Even more evil models?

Thanks to internal data sharing and discussions, we were reminded about a L7 attack which occurred during November 2023. At the time, MikroTik routers were identified, but it did not ring bells. This attack reached 1.2 millions requests per second using HTTPS and involved roughly 3,000 source IPs. Considering our recent findings, we decided to take another look at it.

In order to understand which kind of routers were involved, we recovered the 3,000 IPs involved in the attack. Past investigations shown approximately 700 IPs identified as MikroTik routers and exposing the port TCP/8291. However, we did not check at the time which kind of device were involved.

Just like we did before – we made a quick research using Onyphe. We first did it manually and quickly found the exact same results as before: Cloud Core Routers devices were involved in this attack as well. Among the IPs identified as CCR devices, over 10% were publicly exposing SMNP. Once again, we found core network devices: for instance, 16% of exposed devices are CCR1009-7G-1C-1S+ which is another similar model. This specific model is the 2^nd most exposed model on the Internet according to our findings described in the previous section.

Determining the RouterOS version running on identified devices 8 months ago is probably not relevant, since we can’t say which version was running on the device at the time. However, analysis shows that 22% of the devices are running a RouterOS released between July 1^st. 2023 and July 1^st 2024. The most recent version is v6.49.15 (2024-05-24), while the oldest one is v5.20 (2012-08-15).

Unfortunately, we do not have enough data anymore to provide possible requests rate depending on the device model.

As said before, it’s still hard to know how these devices have been compromised. Likewise, it is difficult to determine whether these attacks are related and if the same botnet is involved in the high packet rate attacks and the L7 attacks. In any case, highlighting the presence of network core devices in L7 attacks remains interesting since it demonstrates how much of a threat these devices could represent.

Let’s do some math

In order to hint at the possible capacity of a botnet leveraging these devices, we decided to focus on packet rate attacks which are well identified.

A quick overview of advertised capabilities for identified devices shows they are capable of handling up to 28 Gbps – for the CCR1036-8G-2S+ – or 80 Gbps – for the CCR1072-1G-8S+. In terms of packet rate, they claim to handle the approximate theoretical packet line-rate with respect to their bandwidth processing capabilities. As a reminder for readers, you can fit ~1.5 Mpps at most in a 1 Gbps link. Depending on the capabilities of devices to craft packets instead of just forwarding them, which is generally done in CPU whenever necessary instead of using ASICs, the amount of packets per second possibly generated by the device could vary greatly and be far lower than advertised processing capabilities. Moreover, generating traffic using the hardware of a compromised device is far from trivial: an intruder will most likely attempt to leverage CPU capabilities only or built-in features whose use has been slightly diverted from their intended usage.

In the context of this thought exercise, we assume networking devices are capable of crafting packets at a rate equal to 10% of their maximal capacity, leading to the following assumptions:

• CCR1036-8G-2S+ should be able to generate 4 Mpps each
• CCR1072-1G-8S+ should be able to generate 12 Mpps each

These estimations seems mostly accurate when compared to what we actually observed in terms of packet rates depending on the identified model. Considering the available CPU on these devices, we think these estimations are quite conservative: for instance, in the case of CCR1036-8G-2S+ devices, generating more than 4 Mpps with 36 cores @ 1.2GHz should not be difficult.

At this point, anyone can do the math to build a naive scale model of a botnet leveraging these devices. Considering a rate of 1% (arbitrary conservative value) of exposed devices being compromised, and focusing only on the first two models we identified as compromised:

• ~ 300x CCR1036-8G-2S+ / 4 Mpps each
• ~   90x CCR1072-1G-8S+ / 12 Mpps each

Such a botnet would theoretically be able to generate 2.28 billions packets per second (or Gpps).

In terms of requests per second capacity for L7 attacks, we do not have enough data to emit a strong enough hypothesis. We can only affirm theses devices seems well able to perform L7 attacks and high packet rate attacks. Attempting to estimate possible L7 capacity is left as an exercise for the reader.

Conclusion

The evidences highlighted in this article suggests a new trend: leveraging compromised network core devices to perform powerful attacks. Even if MikroTik devices may have been already involved in DDoS attacks, no evidence yet was indicating these botnets were relying upon network core devices.

While any high-end server could perfectly be capable of generating packet rates at this scale, they will probably be limited by the actual amount of available public bandwidth. Because of their location within network, core devices are much less affected by this assertion: they are generally connected to even bigger devices using high-capacity network links. Moreover, the mitigations implemented by network administrators to identify abnormal behaviours on the network — such as servers initiating DDoS attacks — can be bypassed in this case because routers are generally not subject to these measures.

Depending on the number of compromised devices and their actual capabilities, this could be a new era for packet rate attacks: with botnets possibly capable of issuing billions of packets per second, it could seriously challenge how anti-DDoS infrastructures are built and scaled. We will definitely take this new threat into account when thinking about how we build and scale our own anti-DDoS infrastructures to make sure we remain out of any possible impact. 

To conclude, the security of network devices is both a pressing concern and an actual issue. Since January, 1^st. 2024, more than 10 critical CVEs have been released affecting various network devices from multiple vendors (Ivanti, Cisco, Fortinet, Palo Alto, ..). Some of them were even exploited in the wild before the public release of the CVE. However, this is the first time we face network core devices participating in coordinated DDoS attacks. This is somewhat concerning since identified devices are designed for small & medium-sized network cores, and much more powerful equipment is available today. 

Closing note: we reached out to MikroTik through several communication channels to expose them the situation. MikroTik reached out to us on 2024-07-04 and is investigating the possible causes of the issue.

We are also currently contacting different AS to report them the issue.