What Is a Carpet Bomb DDoS Attack?

A carpet bombing DDoS attack floods hundreds or thousands of IP addresses inside a target network at the same time instead of hammering one host. Each address receives a small, unremarkable slice of traffic, so per-host alarms stay quiet while the combined load fills the shared uplink. Carpet bombing DDoS is a network-layer technique built to defeat threshold-based detection and to make null routing worse than useless. This guide covers how the attack is assembled, which vectors carry it, the warning signs most monitoring misses, and the defences that actually hold. The dangerous part is what your dashboards will show you during one: nothing unusual.

Key Takeaways

• Carpet bombing DDoS spreads a single flood across an entire IP range or subnet rather than concentrating it on one destination address.
• Per-host detection thresholds are the intended victim of the technique, because every individual IP stays below its alarm value.
• The aggregate traffic still exceeds shared uplink capacity, so service degrades across every host in the range at once.
• Null routing a hit address does not help, since the attacker is already hitting most of the block and blackholing finishes the outage.
• Detection requires aggregating traffic by prefix, correlating many simultaneous low-rate flows, and alarming on the CIDR block as a unit.
• Effective mitigation combines always-on distributed capacity, prefix-level detection, granular filtering rules, and rate controls at the edge.
• The technique is now routine at the top end of the threat landscape, including the largest volumetric flood ever publicly recorded.

What Separates Carpet Bombing From a Standard DDoS Flood

Carpet bombing spreads one flood across a whole address range, while a standard volumetric attack concentrates everything on a single destination IP. The traffic totals can be identical. Only the targeting changes, and that one change breaks most detection logic.

Threshold-based detection assumes an attack looks like a spike on one host. Carpet bombing removes the spike. Split 220 Mbps of junk traffic across eleven addresses and each host sees roughly 20 Mbps, comfortably under a 25 Mbps alarm value. The aggregate still exceeds a 200 Mbps uplink, so customers lose service while every host counter reports normal conditions. Tata Communications uses exactly this arithmetic to describe the pattern as low and wide rather than tall and narrow.

Closing that blind spot takes more than tuning an existing alarm. It takes DDoS Mitigation built to baseline and filter at the prefix level in the first place, which is the approach the rest of this guide works through.

NETSCOUT’s ASERT team recorded adversaries aiming floods at entire CIDR blocks rather than individual addresses from 2016 onward, and named the pattern carpet bombing, spread spectrum, or subnet DDoS. Early campaigns concentrated on networks in Turkey, France, Italy, and South Africa before the method spread worldwide. Corero reported a documented case in which a South African internet service provider was knocked offline for a full day by one of these attacks.

Most teams assume a bigger attack is easier to see. Carpet bombing inverts that. The larger your address space, the thinner an attacker can spread and the quieter the flood looks from the inside. A /22 gives four times the hiding room of a /24 at the same total volume, which is why service providers and hosting platforms feel this technique first.

Carpet bombing sits inside the wider volumetric family, and the bandwidth exhaustion mechanics described in our Volumetric DDoS Attack Guide apply here without modification. What changes is where the pressure lands. Knowing the shape of the traffic matters less than knowing how it gets built, and that starts well before the first packet arrives.

How a Carpet Bombing DDoS Attack Works

The attack is assembled in five stages: enumerate the target range, task a distributed source pool, divide the flood across every reachable host, stay under per-IP thresholds, and let the aggregate saturate shared capacity.

1. Enumerate the range. The attacker resolves the target organisation to its announced prefixes and identifies live hosts inside the block.
2. Task the source pool. A botnet or a rented service receives one target list covering the whole range rather than a single address.
3. Divide the flood. Each destination gets a modest flow, frequently with randomised source ports, destination ports and packet sizes.
4. Stay under the alarms. Per-host counters never reach their trigger values, so no host-level alert is generated anywhere.
5. Saturate the shared path. Aggregated traffic fills the edge router, the transit link or the peering capacity that every host depends on.

Scale comes from the source side. Cloudflare attributes its recent record-setting floods to the Aisuru botnet, which researchers estimate spans one to four million compromised hosts, largely consumer routers and cameras. A pool that size can hand a trivial share of its output to each destination and still overwhelm a regional network. The way those pools are built and commanded is covered in our Botnet DDoS Attack explainer.

Academic measurement backs up the shape. Researchers who analysed captured carpet bombing traffic found that roughly 73 percent of the time the data rate reaching each victim IP was too low to trip host-side detection thresholds, and that a single campaign covered between 200 and 600 Class C segments.

“The aggregate attack traffic can exceed 100 Gbps”

That volume has to arrive as something. The vector mix is where carpet bombing gets its efficiency.

The Attack Vectors That Carry Most Carpet Bombing Traffic

Carpet bombing is a targeting method, not a protocol, so it rides on the vectors that already scale well: UDP floods, reflection and amplification, TCP reflection, and connection-state attacks such as SYN floods.

The choice is driven by two needs. The vector has to produce volume cheaply, and it has to look plausible at low per-host rates. UDP suits both. Reflection suits both even better, because the source addresses belong to legitimate third-party services rather than the botnet itself.

The largest publicly documented example is instructive. Cloudflare reported a flood peaking at 29.7 Tbps and 14.1 billion packets per second that lasted 69 seconds and was described as UDP carpet bombing, aimed at an average of 15,000 destination ports every second with randomised packet attributes. Two details matter more than the headline number: the duration was shorter than most human escalation paths, and the randomisation was designed to defeat static filters.

TCP-based floods have been the single most used vector family across the wider DDoS landscape for years, and NETSCOUT put them at roughly 46 percent of all attacks in its 1H 2022 measurement. Spread thinly across a range, a SYN flood becomes particularly awkward, because the pressure shows up as connection state rather than bandwidth. The defensive primitive for that case is well documented in How SYN Cookies Work, and it applies per host even when the attack is aimed at the prefix. Knowing the vector is only half the problem. The other half is noticing anything at all.

Signs of Carpet Bombing DDoS Your Monitoring Probably Misses

The reliable signals are all relational: many destination addresses becoming active at once, a rising prefix total with flat per-host graphs, and customer complaints that arrive without a matching host alert.

Read these together rather than individually. Any one of them has an innocent explanation. Arriving at the same time, they describe a flood that your per-IP tooling has been built not to notice, the same pattern-over-symptom logic covered in our broader guide to the signs of a DDoS attack.

.

• Uplink or transit utilisation climbs steadily while no single host counter moves out of its normal band.
• The count of distinct destination IPs receiving traffic inside one prefix jumps far above its usual value.
• Destination ports look randomised across a very wide spread rather than clustering on real services.
• Packet rate rises faster than bit rate, which points at small packets and stateless vectors.
• Support tickets arrive from several unrelated services that happen to share a prefix or an edge router.
• Flow records show many short-lived, low-byte flows from a large and geographically scattered source set.

You might be thinking that request-level controls should catch this. They will not, at least not alone. Rate limiting works on the assumption that a single source or a single destination is behaving abnormally, and carpet bombing is engineered so that neither is. It remains valuable once traffic has been narrowed, which is a very different job from finding the attack in the first place. Worse, the two reflexes most teams reach for next make the situation actively worse.

Why Per-IP Thresholds and Null Routing Fail Against It

Per-IP thresholds fail because the attacker chose the traffic level specifically to sit below them. Null routing fails because dropping every address under attack means dropping most of your own network.

The first failure is a design assumption, not a bug. Threshold detection encodes the belief that an attack concentrates. When that belief stops holding, the detector does not produce a wrong answer; it produces no answer, which is harder to notice and harder to argue with during an incident review.

The second failure is sharper. Blackhole Routing is a legitimate and widely deployed tool, and against a single-target flood it protects the rest of the network by sacrificing one address. Applied to a carpet bombing attack, the arithmetic reverses. If the attacker is hitting 200 hosts in a /24, null routing the affected addresses removes 200 services from the internet. You have completed the outage on the attacker’s behalf, faster and more thoroughly than the flood would have managed on its own.

Yes, blackholing still has a place. It belongs at the far end of the escalation path, scoped as tightly as possible, and only when the alternative is losing the entire uplink. Treating it as a first response to a spread attack is the single most common self-inflicted wound in this category.

That framing is useful because it sets the objective. Availability is what you are defending, so any response that trades availability for quiet is not a mitigation. See also the joint guidance from CISA, the FBI, and MS-ISAC for the wider incident response structure. The alternative to blunt tools is better resolution, which starts with how you count traffic.

How to Detect Carpet Bombing DDoS at the Prefix Level

Detect it by aggregating flow data per announced prefix, alarming on the block as a unit, and correlating the number of simultaneously active destination addresses rather than the volume reaching any one of them.

Practically, that means three changes to most monitoring setups. Baseline every prefix you announce, not just critical hosts. Add a distinct-destination-count metric alongside bits and packets per second. Then set an aggregate threshold tied to real uplink capacity rather than to a host-level assumption inherited from an appliance default.

# Wrong question: which host is under attack?
nfdump -R /flows -s dstip/bytes 'dst ip 203.0.113.42'

# Right question: what is the whole prefix receiving?
nfdump -R /flows -s dstip/bytes -A proto,dstport 'net 203.0.113.0/24'

# ExaBGP flow specification: drop one abused vector across the range
flow route carpet-ntp-123 {
    match {
        destination 203.0.113.0/24;
        protocol udp;
        source-port 123;
        packet-length 468;
    }
    then { discard; }
}

The second half of that snippet is the mitigation primitive. A flow specification rule matches on protocol, prefix, ports and packet length together, so it can drop one abused vector across an entire range while leaving legitimate traffic to the same hosts untouched. That granularity is the direct answer to a spread attack.

The standard behind that capability is published as RFC 8955, and the operational detail of building and propagating those rules is covered in BGP FlowSpec. Rules only help if they can be pushed while the attack is running, which is a rehearsal problem more than a technology problem.

Carpet Bombing DDoS Mitigation That Holds Under Load

Mitigation holds when capacity is distributed, detection is prefix-aware, filtering is granular, and none of it waits for a human. Any stack missing one of those four fails in a predictable way.

Distributed capacity comes first because it changes the arithmetic before any decision is made. When traffic for a prefix is drawn to many points of presence rather than one entry point, a flood that would saturate a single uplink is divided across the footprint that absorbs it. An Anycast Network does this by routing, without a detection step, which is why it keeps working during the first seconds of a short attack.

Below the routing layer, filtering has to happen at layers three and four, because that is where the traffic lives. Application-aware controls have nothing to inspect in a stream of malformed UDP datagrams aimed at closed ports. Transport-layer protection such as L4 Shield handles the packet-level filtering, state protection and vector-specific drops that this attack class demands, and it does so for the whole protected range rather than one address at a time.

Speed matters as much as capability. Cloudflare reported that most network-layer attacks in its recent measurements ended in under ten minutes, and the record carpet bombing flood lasted 69 seconds. Any control that depends on someone reading an alert, opening a ticket, and phoning a provider is not a control; it is a post-incident report.

Building a Carpet Bombing Response Plan Before You Need It

A workable plan answers four questions in advance: who can trigger mitigation, what gets diverted, which filters are pre-approved, and what the aggregate threshold actually is.

1. Document every prefix you announce, the services inside each one, and the real capacity of the path in front of it.
2. Set and record prefix-level alarm values derived from uplink capacity, then test that they fire in a controlled exercise.
3. Pre-authorise automatic diversion and filtering so mitigation starts without waiting for approval during business hours.
4. Agree filter templates with your transit providers in advance, including the vectors you expect and the ranges they apply to.
5. Define an explicit escalation point for blackholing, with the scope and the sign-off it requires, so it is never a reflex.
6. Run a tabletop exercise that assumes no host alert fires, because that is the condition you will be operating under.

You might be thinking this is a service provider problem rather than an enterprise one. It was, until hosting a handful of public services behind a small block became the norm. If your applications share an edge with anything else, you inherit the exposure of the whole range. Once the flood is filtered and clean traffic returns, a Rate Limit policy at the edge keeps the recovery period from turning into a second outage as retries stack up. Plan for that phase too, because the recovery is where most of the customer-visible damage is usually decided.

Final Thought on Carpet Bombing DDoS

Carpet bombing is not a bigger flood. It is the same flood, arranged so that the tools most networks rely on report nothing. That makes it a measurement problem before it is a capacity problem, and it explains why organisations with plenty of bandwidth still lose service to it.

The fix is unglamorous and durable. Count traffic at the level the attacker operates on, which is the prefix. Keep capacity distributed so the first seconds are survivable without a decision. Keep filtering granular enough that you never have to choose between the attack and your own users. Networks that get those three right rarely need the blunt options, and they recover in minutes rather than hours.

Common Questions About Carpet Bombing DDoS