Unlike a single-vector flood, a multi-vector attack does not hand a defender one thing to tune against. It strikes several tiers at once, so a control calibrated for one vector can be walked around by another, which is why a DDoS test built to be realistic reproduces the combination rather than one clean vector at a time.
What layering buys the attacker
A multi-vector campaign combines attack classes that break a defense in different places. A volumetric reflection flood aims to saturate the link. A protocol attack aims to exhaust a finite state table, conntrack or a SYN backlog, at a packet rate the link never notices. An application-layer flood aims to burn backend CPU with requests that are individually valid. Each targets a different tier, so no single control sits in front of all three.
The vectors can arrive simultaneously or in quick succession, and the difference matters. Sequenced, they probe: the attacker sends one class, watches which control engages, then pivots to the class that control does not cover. Simultaneous, they compound: the volumetric flood consumes the scrubbing budget while the L7 flood works the origin the scrubber was meant to protect. The realistic adversary model, the one worth testing against, is closer to the simultaneous case, because that is how motivated attackers operate and how operators report the largest campaigns are shaped.
The shape of a layered campaign
Layering changes the geometry of the traffic, not just its class mix. Two documented patterns show why.
A pulse-wave campaign delivers its volume in short, repeated bursts rather than one sustained flood. Each burst pins mitigation into a re-engage cycle: the scrubber ramps up, the pulse stops, the scrubber stands down, and the next pulse lands against defenses that have already relaxed. Ride a steady application-layer flood underneath the pulses and the operator's attention stays locked on the loud, intermittent volumetric layer while the quiet L7 layer works the origin without a break.
Carpet-bombing spreads the load across an entire address range instead of one destination IP. No single host sees enough traffic to trip a per-IP detection threshold or a per-IP rate limit, yet the aggregate still saturates the upstream link or fills a shared state table that every one of those hosts sits behind. It is a volumetric or protocol attack arranged specifically to stay under the thresholds a per-target defense keys on, which is exactly the seam a multi-vector campaign is built to work.
Why it matters under attack
Testing each vector in isolation misses the interaction, and the interaction is where defenses fail. A WAF spending CPU inspecting an L7 flood has less headroom for everything else. A scrubbing rule tuned for volumetric traffic does nothing for a slow-POST attack riding underneath it. Conntrack saturating under a protocol flood drops the very connections that mitigating the volumetric flood was meant to preserve. The failure is rarely the vector a defense is strongest against; it is the second or third vector that lands while the first is consuming attention and resource.
There is a detection problem too. Layered vectors muddy the signal each detector keys on: a volumetric spike masks a low-and-slow L7 climb, and an operator watching bandwidth graphs may mitigate the loud vector while the quiet one does the real damage.
What a DDoS test measures
A realistic test runs vectors concurrently and measures how the defenses behave together, not one at a time. It looks for the tier that fails first under combined pressure, the layer of first failure, and whether mitigating the loudest vector starves the resources needed to handle the others.
It also measures whether the controls interfere with one another: does engaging volumetric scrubbing add latency the application tier cannot absorb while it is also under an L7 flood? Whether vectors are run simultaneously or in sequence changes what the test can find at all, and that methodological choice is worked through in Multi-Vector DDoS Testing.