2025 DDoS Attack Statistics: 12 Months of Platform Data from Taiwan (Peak 2.4 Tbps)

1. How the scale of global DDoS attacks changed in 2025

To understand what the local data means, start with what happened in the wider environment.

2025 was a year in which DDoS records were broken repeatedly. At mid-year, the largest single attack publicly disclosed in the industry was 7.3 Tbps; by early September that figure had been replaced by 11.5 Tbps; later the same month 22.2 Tbps appeared; a 29.7 Tbps record also fell within the third quarter; and the highest for the full year reached 31.4 Tbps. In other words, within a single year the publicly recorded ceiling grew more than fourfold.

According to Cloudflare's Q4 2025 threat report, the scale of hyper-volumetric attacks grew by more than 700% compared with the end of 2024, and the total number of DDoS attacks grew 121% over 2025. Several record-breaking events were attributed to botnets such as Aisuru, built from millions of infected devices, a substantial share of them home routers and IoT devices.

What do these numbers mean for organizations in Taiwan? Not that "we are about to see 31 Tbps," but two more practical things:

First, the capacity attackers can mobilize is still rising fast.A few years ago, attacks above 1 Tbps were treated as rare events; today they are a routine statistical category. That means any protection capacity sized against "the highest value observed historically" has a shrinking shelf life. A specification that was sufficient three years ago may already be inadequate today.

Second, the cost of launching an attack is falling.Some botnets circulate on underground markets as rentals, priced from a few hundred to a few thousand US dollars. This changes the distribution of the threat: launching a Tbps-class attack used to require a well-resourced attacker, and the barrier is now low enough that anyone with a motive can obtain it. For defenders, the assumption that "we are not a well-known target, so we probably will not be hit" no longer holds.

That is as far as the external data goes. Everything below is actual observation from our own platform.

2. Twelve months of monthly observations

The table below shows the attack peaks for each month of 2025. L4 peak refers to the highest instantaneous traffic in a single event; L7 CC peak refers to the highest number of application-layer connections in a single event.

Network-layer monthly peaks: mean 712 Gbps, median 390 Gbps.

Application-layer monthly peaks: mean 141 QPS, median 121 QPS.

The key metrics are summarized below:

A note on comparability: our L7 statistics are based on application-layer connection counts, which is a different basis from the requests per second (RPS) used by some vendors. The absolute figures should not be compared directly.

3. Four patterns in the data

Reading the table alone, it is easy to remember only the maximum. In fact there are four patterns in this data set that matter more to defense planning than the 2.4 Tbps figure does.

3.1 Risk is dominated by a small number of extreme events

The mean monthly peak is 712 Gbps and the median is 390 Gbps. The near-twofold gap means the distribution is heavily skewed. It is not that every month sees a 712 Gbps attack, but that extreme values in a few months pull the overall average up.

The gap is even clearer at quarterly level. Q3 averaged 1,205 Gbps and Q4 only 204 Gbps, making the former 5.9 times the latter.

Viewed in half-year blocks, another layer of detail appears. The first half averaged 719 Gbps and the second half 704 Gbps, a difference of only 2%, which looks like stable intensity across the year. But the second-half average is carried almost entirely by July (2,400 Gbps) and August (860 Gbps); with those two months removed, the remaining four average just 242 Gbps. By contrast, with May — the highest peak of the first half — removed, the remaining five months still average 623 Gbps.

The practical implication is this: capacity planning based on annual averages will certainly fail during a single extreme event.And once protection fails in one event, the preceding eleven months of stability count for nothing, because customers do not forgive an outage on the grounds of good performance the rest of the time.

3.2 The month with the most events was not the month with the highest intensity

October showed the highest event density of the year (around 40 events, nearly daily), but the highest single event that month was only 383 Gbps, which did not place in the year's top five. Conversely, July had the highest peak of the year, yet its event count fell in the lower range.

The two metrics point to different risks:

• Measured by event count, July's risk is understated. The whole month held only a few events, but one of them reached 2.4 Tbps.

• Measured by intensity, October's drain is understated. Forty medium-intensity events will not interrupt service, but they steadily consume operations staff time, because each one has to be assessed, logged and tracked, and none of them on its own meets the threshold for escalation.

The real damage from October's pattern is alert fatigue. Once alerts become everyday background noise, a genuinely major event can be lost in the noise.

3.3 The two layers do not move in step

Viewed as quarterly averages, the network layer and the application layer follow quite different trajectories:

The network layer surged 122% in Q3 and then fell 83% in Q4. Over the same period the application layer declined steadily quarter by quarter, with no correspondence to the network layer's sharp swings. No clear coordination between the two layers was found during this observation period.

One behavioral change is also worth recording. Comparing the dates on which each layer peaked, four of the six months in the first half (January, February, May and June) had both peaks on the same day, and in the second half this never happened again. The clearest example is July: the largest network-layer event fell on the 19th while the month's highest application-layer figure fell on the 9th, ten days apart, with no temporal relationship.

The implication for defense configuration is direct: you cannot assume that holding one layer will force the attacker to switch to the other.Both layers need to be provisioned separately, rather than treated as an either/or. Planning in the order of "block volumetric attacks first, deal with the application layer later" will fail on both counts in the months where the two occur together.

3.4 A quiet period does not mean the threat is over

June and November were the only two months of the year with peaks below 150 Gbps. November, at just 55 Gbps, was the annual low.

Where these two low points sit is worth noting: June came after five months of sustained pressure, and November came after the diversified campaigns of July through October. And after November's low, December rose again to 173 Gbps.

In sequence, these two quiet periods look less like the end of a threat and more like a phase in which the attacker assesses results and regroups resources after an investment. That means any approach that "adjusts protection configuration according to current activity levels" will fail during the rebound that follows a quiet period. The moment you scale down is precisely the moment the other side is preparing the next round.

4. Three attack profiles and what each one demands

Based on these 12 months of observation, attack behavior can be grouped into three profiles. They differ clearly in intensity, frequency and persistence, and are not easily covered by a single defensive logic.

Concentrated: single extreme events

Representative periods are January, March, May and July. The characteristic is one or two extreme events within a month, with the rest of the time relatively quiet.

Take May as the example. Across the whole month, only one event, on 7 May, reached 1,200 Gbps, and every other event stayed below 40 Gbps. That single event was thirty times the second-highest figure of the month.

The risk in this profile lies not in total volume but in the instantaneous peak. In terms of defense design, what it demands is protection that is always in place: any mechanism requiring manual activation, traffic redirection or cross-system coordination may have a response time longer than the duration of the event itself.

Sustained: high density, medium intensity

The representative period is October. That month saw around 40 events, nearly daily, with intensity concentrated in the 150 to 380 Gbps band and no single event standing out.

That degree of concentration in the intensity band fits the random distribution of multiple independent attack sources less well than it fits a single resource conducting a long-running cost probe, possibly to determine the highest sustained intensity that does not trigger a defensive escalation.

The impact of this profile falls mainly on operations rather than technology, so the focus is alert aggregation and event triage. If every event is handled at the same level, operations capacity can be exhausted within a few weeks.

Quiet: low-activity periods

The representative periods are June and November; the causes and risks are covered in 3.4. The defensive focus is maintaining monitoring intensity and not scaling down configuration because activity has dropped.

Summary of the differences

No single mechanism covers all three:

• Expanding blocking capacity alone does not address the operational drain of the sustained profile.

• Optimizing alert workflows alone cannot handle the instantaneous impact of the concentrated profile.

• Adjusting configuration according to current activity levels will fail during the rebound that follows the quiet profile.

5. The largest event of the year: five days, three waves, escalating intensity

This mid-July event is the one most worth documenting in full for the whole year.

5.1 What happened

The three waves escalated in order, and the intervals between them were long enough to observe the defender's response. This structure fits the characteristics of an incremental stress test rather than a random burst.

There is a very concrete inference here for capacity planning: had protection resources been sized on the basis of the first wave, the final wave would have exceeded that provision by nearly 2.5 times.

5.2 Handling record for the third wave

5.3 Technical characteristics derived from the data

Packet size:dividing 2.4 Tbps by 209.19 Mpps gives an average packet size of roughly 1,434 bytes. That figure indicates a large-packet amplification attack, aimed at saturating bandwidth rather than exhausting packet-processing capacity.

This assessment points to a scenario that has not yet occurred. If the attacker switched to small packets at a high packet rate, the number of packets at the same bandwidth would rise substantially, and the protection bottleneck would move from bandwidth capacity to packet forwarding capability. Using this event as the example, if packet size dropped to 64 bytes, the same 2.4 Tbps of traffic would correspond to a packet rate of roughly 4.7 Gpps, which is 22 times the figure measured here. Packet-processing demand at that scale did not appear at any point during this observation period.

Timing:20:45 local time, outside business hours.

How the rule was hit:this mitigation was triggered by a generic high-volume UDP signature rule, not by a custom rule targeting a specific source or signature. That tells us two things: the attack did not use obfuscation sufficient to evade generic signatures; and if an attacker were to use vectors closer to the characteristics of normal traffic, the effectiveness of generic rules would decline.

5.4 Three implications of this event

First, the period following an initial medium-scale event should be treated as a high-risk window.
In this case, raising the monitoring level after the 695 Gbps event on 15 July would have allowed preparation to be completed before the following two waves arrived. This adjustment involves no equipment investment; it only requires writing a rule into the incident-handling process — for example, that once a single event exceeds a set threshold, monitoring level and alert sensitivity are automatically raised for a defined period afterwards.

Second, the attack occurred after hours.
This is not a coincidence but a common choice. The hours when on-duty staffing is thinnest are exactly the hours when an attacker is most likely to get results.

Third, the handling window is shorter than the response time of a manual process.
Industry statistics show that in 2025 around 90% of attacks lasted less than 10 minutes. When most attacks are over within ten minutes, the manual chain of detect → notify → assess → act is a bottleneck at every step. This event was mitigated from start to finish by pre-deployed automated rules, with no human intervention. Given when attacks occur and how long they last, there is no longer any time margin for human judgment.

One further point worth recording alongside this: industry statistics show that around 30% of attacks are followed by another attack within seven days. That proportion corroborates our July observation of three waves over five days. Statistically, the first attack event observed is often not the last.

6. Five conclusions the data points to for defense planning

1. Do not plan capacity around averages.
A distribution with a mean of 712 and a median of 390 tells us that annual risk is concentrated in a handful of events. Capacity planning should be benchmarked against the monthly maximum, not the annual average.

2. Do not plan on the historical maximum alone.
Using the historical maximum as the benchmark risks allocating resources to the wrong protection layer when the attack profile shifts. The sensible approach is to take both the monthly maximum and the event count into account, and to review the relative movement of the two on a regular basis.

3. Treat automation as a prerequisite, not a bonus.
Ninety percent of attacks end within ten minutes; the largest event occurred at 20:45; the whole event was handled with no human intervention. Put those three facts together and the conclusion is that defenses must already be online before an attack begins, rather than being activated after it starts.

4. Provision the two layers separately.
The network layer and the application layer showed no clear coordination during this observation period. Holding one layer will not make the attacker stop.

5. Alerting matters as much as blocking capacity.
Sustained attacks will not interrupt service, but they will exhaust operations capacity. The design of alert aggregation and event triage determines whether a team can get through a month with 40 events.

FAQ

Appendix: Methodology and data limitations

The data in this article comes from SkyCloud's actual observation records in live network environments. It is neither simulated nor estimated. All data has been de-identified and contains no customer names, asset addresses or any identifiable information.

Metric definitions:
L4 peak refers to the highest instantaneous traffic (Gbps) in a single event within the statistical period; L7 CC peak refers to the highest number of application-layer connections (QPS) in a single event, counted on a connection basis, which differs from the RPS basis used by some vendors; event density refers to the number of discrete attack events observed in a month and is an interval estimate; concurrent activity across the two layers is determined by both layer peaks falling on the same calendar day.

Statistical method:
Monthly statistics are produced on a rolling window of approximately 30 days rather than calendar months, and events spanning two months have been corrected manually. Quarterly averages are the arithmetic mean of each month's peak, not the average of all events within that quarter.

Data limitations:
The analysis here is built on absolute peaks and does not incorporate the number of protected assets, normal traffic baselines or average monthly request volumes. It can therefore answer "how large the attack was" but not "how much headroom remains before the absorption limit". Only one event during the observation period has a complete vector classification record; the remaining events have only quantitative traffic and connection figures. Attack duration is not included in our platform's statistics, and the duration distributions cited in this article are external data. In addition, because these statistics are peak-based, low-rate, long-duration attack profiles, if present, would not appear in this data set; the identification of a quiet period only means that no event above the threshold was observed.

External references:
The growth rate of global attack scale, the attack size distribution, the duration distribution and the proportion of repeat attacks within seven days are cited from Corero Network Security's 2026 Threat Intelligence Report. The largest publicly disclosed single attack peak of 2025, the total attack growth rate and the hyper-volumetric attack growth rate are cited from Cloudflare's 2025 Q4 DDoS Threat Report. The statistical basis and observation scope of the external data both differ from our platform's, so it is used only as a directional reference and is not combined with our platform's data in any calculation.

That is the full year of observation for 2025. If you are assessing whether your own environment's protection is sized to absorb attacks at this scale, or would like the complete annual threat intelligence report, get in touch with us.