Multi-Vector Attacks and Carpet Bombing

The DDoS landscape of the early 2010s was dominated by single-vector attacks: a sustained flood of a single traffic type directed at a single target IP. Defenses matured in response, scrubbing centers, BGP-based traffic diversion, CDN interposition, and rate-limiting infrastructure became standard for large organizations. Single-vector attacks against well-provisioned targets became less effective.

The response was multi-vector campaigns: simultaneous deployment of multiple attack types against the same target, or coordinated attacks against different components of the target's infrastructure. A scrubbing center that blocks UDP amplification traffic does not automatically block HTTP floods that arrive on the same target. A CDN that absorbs HTTP floods does not protect backend infrastructure from direct attacks. Multi-vector campaigns exploit the operational reality that mitigating one attack type at a time, while another continues, requires more resources and faster response than single-vector campaigns.

The Operational Logic of Multi-Vector Attacks

A defender responding to an attack must characterize the attack traffic, deploy appropriate countermeasures, verify their effectiveness, and iterate. Each step takes time. Each mitigation deployed for one vector may have side effects on another vector's mitigation. Coordinating responses across different infrastructure layers (network, transport, application) involves different teams, different tools, and different decision loops.

A well-designed multi-vector campaign exploits this response complexity. The objectives:

Exhaust mitigation capacity: each attack vector consumes some fraction of the defender's mitigation capacity, scrubbing bandwidth, analyst time, configuration change bandwidth. Multiple simultaneous vectors exhaust this capacity faster than any single vector, potentially overwhelming the defender's ability to respond to all of them.

Force trade-offs: countermeasures for one vector may conflict with countermeasures for another. Blocking UDP traffic broadly addresses amplification floods but may break legitimate UDP-based services. Requiring JavaScript challenges addresses application-layer floods but breaks API clients and non-browser traffic. When multiple vectors are active simultaneously, the defender must choose which countermeasures to deploy and accept the cost of those that cannot be deployed without collateral damage.

Find the undefended layer: an organization may have excellent volumetric scrubbing but no application-layer protection. A multi-vector attack that saturates the scrubbing center's attention with a volumetric component while sending application-layer attack traffic that the scrubbing center passes through exposes the under-defended layer.

Create noise: a large volumetric component creates noise in traffic analysis that may obscure the more surgical application-layer component. If the defender is focused on the visible, high-volume traffic, they may not notice the low-volume component that is actually causing the service degradation.

Attack Vector Combinations

The most commonly documented multi-vector attack combinations reflect the availability of different attack primitives and the specific defenses they are designed to challenge.

Volumetric + application layer: a UDP amplification or botnet flood directed at the target's network perimeter, combined with HTTP GET/POST floods against the application. The network-layer component consumes mitigation bandwidth and may trigger upstream filtering that introduces false positive drops of legitimate traffic. The application-layer component targets the resources the network-layer component does not, application CPU, database connections, session state.

SYN flood + HTTP flood: a SYN flood against the web server consumes TCP connection state and may trigger SYN cookie mode (with associated TCP option degradation), while an HTTP flood from separately managed infrastructure attempts to exhaust application processing resources. The SYN flood may be directional, appearing from a different source distribution than the HTTP flood, making filtering rules more complex.

DNS attack + direct attack: targeting the target's DNS infrastructure reduces the reachability of the service, while simultaneously attacking the service directly for users who have cached DNS results or are using direct IPs. This was the pattern of the Dyn attack in 2016, extended to also attack other Dyn customers (since the DNS infrastructure was shared).

Infrastructure targeting: rather than attacking the application directly, attacking the underlying infrastructure: the target's upstream ISP (via BGP prefix hijacking or direct flood of the ISP's infrastructure), the target's DNS provider, the target's CDN origin (if the CDN IP can be discovered), or the target's authentication infrastructure (identity provider, LDAP server). None of these are the application itself, but breaking any of them makes the application unavailable.

Carpet Bombing

Carpet bombing is a volumetric attack technique that distributes traffic across a wide range of target IP addresses simultaneously, rather than concentrating it at a single destination. The attack targets an entire subnet or autonomous system rather than a specific host or service.

The motivation for distributing traffic broadly is to defeat per-destination traffic diversion. BGP-based DDoS mitigation works by diverting traffic to a specific destination prefix to a scrubbing center. The scrubbing center filters the diverted traffic and returns clean traffic to the origin. This approach requires identifying which destination prefixes are under attack.

When attack traffic is spread across thousands of destinations simultaneously, a /16 or /8 subnet, no individual destination appears to be under attack. The traffic volume per destination is small, below the threshold that would trigger diversion. But the aggregate traffic saturates the target's upstream links, which must carry the sum of all destination-directed traffic.

From the perspective of the upstream provider's traffic analysis, no individual prefix shows anomalous volumes. The anomaly is in the aggregate inbound volume on the AS's peering links, which is harder to characterize and attribute to specific destinations.

The carpet bombing technique became prominent in approximately 2018–2019, associated with volumetric attacks that were difficult to mitigate using standard per-prefix diversion approaches. Akamai, Cloudflare, and other mitigation providers documented adapting their detection to look at per-AS aggregate traffic patterns rather than only per-prefix patterns.

Technical Mechanics

The simplest carpet bomb sends equal volumes to each destination in the target subnet. More sophisticated variants adjust per-destination traffic to stay below per-prefix detection thresholds while exceeding the aggregate link capacity. If a provider's detection threshold for per-prefix diversion is 10 Gbps, and the provider's peering link capacity is 200 Gbps, sending 8 Gbps to each of 25 subnets exhausts the link without triggering per-prefix diversion.

The distribution can be achieved through botnet coordination (instruct bots to distribute their traffic across a target range) or through amplification techniques (craft spoofed requests with destination IPs distributed across the target range, relying on the amplification reflectors to send response traffic to those destinations).

The latter is more difficult because amplification attacks require spoofing the source address of the requests, not the destination. But for UDP services where the client specifies the target address in the request (less common), or for attacks against routed infrastructure where traffic crosses the target subnet regardless of specific destination, distribution across a prefix is achievable.

Detection and Response

Per-destination traffic analysis misses carpet bombing by design. Effective detection requires monitoring aggregate inbound volume at the AS peering or transit level, tracking it against historical baselines, and triggering on unexpected aggregate increases even when no individual prefix is anomalous.

When detected, the mitigation challenge is that per-prefix diversion does not help, there is no single prefix to divert. Broader prefix diversion covers more of the attack traffic but also diverts more legitimate traffic, increasing the cost of false positives. AS-wide BGP community announcements to upstream providers requesting traffic scrubbing are operationally complex to deploy and require provider support.

Pulse Wave Attacks

A pulse wave attack sends traffic in sharp bursts rather than sustained flows. The pattern is: high-volume burst for a short period (seconds to a few minutes), complete silence or low traffic, repeat.

The operational impact targets the response latency of mitigation infrastructure. Automated DDoS mitigation typically operates on a detect-divert-scrub-return loop. Detection requires collecting enough traffic data to characterize an anomaly, which takes time. Diversion requires BGP propagation, which takes seconds to minutes to converge. Once diversion is active, returning to normal routing when the attack stops also takes time.

A pulse wave calibrated to be shorter than the detection-to-mitigation cycle achieves impact during the burst and ends before mitigation is fully deployed. By the time the mitigation is in place and traffic is being scrubbed, the burst has stopped and legitimate traffic is now being misdirected to the scrubbing center unnecessarily. The next burst begins before or during the time the operator takes to disable mitigation.

If the operator leaves mitigation in place continuously, legitimate traffic takes the penalty (increased latency from scrubbing path traversal) permanently. If the operator turns mitigation off between pulses, each new pulse inflicts damage before mitigation can be reactivated.

The pulse wave technique also stresses on-call response capacity. A sustained attack is handled once, triaged, and left under automated control. A pulse wave attack that turns on and off every few minutes requires repeated human intervention and decision-making, generating operational fatigue over hours.

Pulse Wave Against Rate Limiting

Rate-based mitigation (network ACLs, WAF rate limiting rules, application-level rate limiters) operates on windowed traffic measurements. A rate limiter that triggers when more than n requests per second are observed during a 5-second window does not activate if bursts are shorter than 5 seconds or calibrated to stay just below n requests per second.

Pulse waves can be calibrated to exploit the window size of rate-based detection. Traffic that exceeds the rate limit within a short burst but falls below it when averaged over the detection window evades triggering. This requires knowing or estimating the detection window, which is often inferrable from response behavior.

Infrastructure-Level Attacks in Multi-Vector Context

Multi-vector campaigns increasingly target the infrastructure that an application depends on rather than the application itself. The target's origin server may be defended by a CDN that absorbs application-layer attacks, but the CDN cannot protect the DNS infrastructure that resolves the application's domain, or the BGP routing that determines how traffic reaches the CDN.

BGP hijacking as DoS: an attacker who announces a more-specific prefix for the target's IP block causes routing tables worldwide to prefer the attacker's announcement, directing traffic to the attacker's network rather than the target's. The target's service is unreachable, not because it is overloaded but because packets never reach it. This is a denial of service effect achieved through routing manipulation rather than traffic flooding. Recovery requires the legitimate operator to out-advertise the hijack with their own more-specific announcement, which propagates globally through BGP and takes minutes.

Certificate authority and OCSP: applications that rely on TLS for transport security have a dependency on certificate validity checking (OCSP). An attack against an OCSP responder that causes it to be slow or unavailable may cause certificate validation failures in clients configured with strict OCSP checking, making the application unreachable to those clients without any attack on the application itself.

Authentication infrastructure: applications that use federated identity (OAuth providers, SAML identity providers, LDAP) have a dependency on authentication infrastructure. An attack that makes the identity provider unavailable prevents users from logging in regardless of the application's own availability.

These infrastructure dependencies are rarely protected with the same rigor as the primary application because they are not the target's own infrastructure and they fail infrequently under normal conditions. Multi-vector campaigns that include infrastructure targeting exploit this protection asymmetry.

The Defender's Response Framework

Responding to a multi-vector campaign requires organizational and technical preparation that single-vector response does not. The technical controls for each vector, volumetric scrubbing, protocol mitigation, application-layer inspection, must be independently deployable and individually adjustable without affecting the others. The organization must be able to characterize each attack component separately, deploy countermeasures for each in parallel, and adjust countermeasures as the attacker shifts tactics.

This requires a tiered mitigation architecture: upstream bandwidth controls at the transit/peering layer, protocol mitigation at the edge, application-layer filtering at the load balancer or WAF, and application-level rate limiting inside the application. Each tier handles the attack traffic appropriate to its layer. Traffic that passes through the upstream layer is handled at the edge layer, and so on.

The operational challenge is that each tier is typically operated by a different team using different tooling with different access and change management requirements. Coordinating changes across tiers under attack conditions, while the attack is actively evolving, is the core difficulty of multi-vector incident response.

Pre-approved playbooks for common attack patterns, pre-established communication channels across response teams, and pre-tested automation for deploying common countermeasures all reduce the response latency that attackers are designed to exploit.