Multi-Vector DDoS

A single-vector attack tests one defence. A multi-vector campaign tests the connections between them, which is a much weaker part of most architectures.

The distinction matters because the second is not simply the first repeated. When the vector changes, the defender’s previous decision — the threshold that was tightened, the source range that was blocked, the diversion that was triggered — is now either irrelevant or actively harmful, and someone has to notice and undo it.

At a glance

Appliance	Combination	What the attacker gains	What it defeats
Volumetric plus application-layer	The flood occupies attention and capacity while the quiet attack works	Teams that treat the largest number as the incident
Sequential vector changes	Each change costs the defender another decision cycle	Response processes that are rebuilt per vector
Volumetric plus state exhaustion	Two different resources under pressure at once	Designs where one device owns both bandwidth and session tables
Pulsed, alternating vectors	Detection never settles on a stable classification	Diversion-based responses with a slow engagement window

None of these requires more capacity than a single-vector attack. All of them require the defender to make more decisions, faster, which is the resource actually being attacked.

Why the seam is the target

Defences are built per layer, because that is how the problem decomposes. Something handles volume, something handles connection state, something handles requests. Each may be sized correctly on its own.

The seams between them are where nothing is sized at all. Three specific weaknesses recur.

Shared budgets. A single appliance running two countermeasures at once is dividing one processing budget between them. A device that sustains its rated packet rate against a pure volumetric flood may sustain considerably less with application-layer inspection also active, and that combined figure appears on no datasheet.

Sequential attention. A team responds to the largest number on the dashboard. While the volumetric component is being handled, the application-layer component is running against a backend that nobody is watching, and its damage does not register as a spike.

Handover gaps. Where two products cover different layers, the boundary between them is usually a human. Vector changes cross that boundary faster than a person can act on it.

The patterns worth knowing

Volumetric cover for an application-layer attack. The flood is loud and, in itself, often survivable. Its function is to occupy the response while a low-volume request flood exhausts a database. Teams that measure success by bandwidth returning to normal declare victory while the actual damage continues. This is a close relative of the attention and capacity argument, applied within availability rather than beyond it.

Sequential rotation. SYN flood, then UDP amplification, then HTTP flood, each lasting a few minutes. No single vector needs to succeed. Each one costs the defender a full decision cycle, and the cycles accumulate into an outage.

Simultaneous pressure on two resources. Bandwidth and session tables under load at the same time. Common because it is easy to generate and effective because most designs assume the two ceilings are reached independently.

Pulsed alternation. Short bursts, different vector each time, none lasting long enough for a classification to settle or a diversion to engage. This defeats out-of-path, on-demand designs more thoroughly than any amount of volume, because the response window never closes.

What a defence needs

Not more capacity. Four properties, none of which is a capacity number.

Simultaneous coverage. Countermeasures at different layers running together rather than selected by an operator. Whether one product or two provide it matters less than whether a vector change requires a human decision.

A measured concurrent capacity figure. Ask for capacity with multiple countermeasures active, not the single-vector maximum. If the answer does not exist, that is the answer, and the test lab can produce it.

A response that does not restart per vector. The runbook should escalate on impact rather than on vector identity, so a change of technique does not reset the process to step one.

Post-vector vigilance. After the first component is contained, keep looking. The escalation matrix should treat a vector change as a trigger, not as a resolution.

Testing it honestly

Single-vector tests are easier to run, easier to score, and systematically optimistic.

Run the combined scenario: a volumetric flood at your circuit’s small-frame packet rate, with an application-layer flood against a genuinely expensive endpoint at the same time, with legitimate traffic measured throughout. Record what the combined figure does to the single-vector one.

Then run the rotation: change vector every few minutes without warning the team, and measure how long each change costs before impact stabilises. That number — decision latency per vector change — is the one multi-vector campaigns are actually attacking, and almost nobody has measured it.

Both scenarios, with their measurement discipline, are in the test lab guide; the legal groundwork for generating any of this is in authorised testing.