How it works
Volumetric, state-exhaustion and application-layer methods are combined or rotated within one campaign. Traffic may also arrive in deliberate bursts rather than continuously, exploiting the delay in detection, scrubbing activation and autoscaling.
Single-vector defence fails predictably
Most defensive tooling is organised by layer. Transit providers and scrubbing services handle volume, load balancers and firewalls handle connection state, and application controls handle request abuse. Each is competent within its own scope.
A multi-vector campaign is built specifically around the seams between them. Traffic that is unremarkable at any single layer can be damaging in combination, and — more importantly — the teams watching each layer may each conclude that their own component is healthy. The service is failing while three dashboards show green, which is a diagnostic problem as much as a capacity one.
The rotation is often deliberate rather than incidental. An attacker who observes one vector being mitigated switches to another, using the defender's own response as feedback. What appears to be several separate incidents is frequently one campaign adapting.
Pulse-wave: attacking the response time
Pulse-wave attacks add a timing dimension. Rather than sustaining a flood, the attacker delivers short bursts at very high intensity, separated by quiet intervals.
This targets the latency in the defence rather than its capacity. Reactive scrubbing takes time to detect an attack, divert traffic and begin filtering — often a few minutes. A burst that ends before diversion completes has already done its damage, and the quiet interval lets mitigation stand down before the next one begins. Autoscaling suffers the same way, adding capacity as the burst ends and removing it just before the next.
The result is a service that fails repeatedly while every automated system reports having handled the event correctly. Availability metrics averaged over an hour may look acceptable while users experienced several complete outages.
The countermeasure is always-on mitigation. If traffic is inspected continuously, there is no activation delay to exploit and the first burst is filtered like any other. This is the clearest case in DDoS defence where reactive architecture is not a cheaper version of the same protection but a materially different one.
Detection requires correlation, not more alerts
The failure mode in a multi-vector incident is rarely missing data; it is data spread across systems that no one is viewing together.
What makes the difference in practice:
- A single timeline showing circuit utilisation, connection table occupancy and application error rate together, so the sequence between tiers is visible.
- Short measurement intervals. Five-minute averages hide pulse-wave bursts almost completely; sub-minute resolution is required to see them at all.
- Alerting on service outcome — completed requests, successful connections — rather than only on resource metrics, so an attack is detected even when no single resource looks saturated.
- Retention of full detail through the incident. Detail is what an upstream provider needs to filter precisely, and it is usually the first thing lost to aggregation.
- Explicit tracking of vector changes during an incident, so a shift is recognised as adaptation rather than treated as a new unrelated event.
Operational posture
Prefer always-on mitigation for anything whose availability genuinely matters. Reactive diversion is cheaper and is adequate against sustained single-vector floods, but it is structurally unable to handle bursts.
Avoid mitigation designs that depend on changing routing during an incident. Withdrawing and re-announcing prefixes introduces convergence delay every time, and a bursty attack will trigger that cycle repeatedly. Route changes made under pressure are a recurring cause of self-inflicted outages.
Agree escalation with upstream providers before an incident: who is called, what evidence they need, what they are authorised to do without further approval, and how long activation takes. Establishing this during an attack costs the exact minutes that matter most.
Rehearse against combined vectors. A runbook validated only against a single steady flood tends to fail at the moment the vector changes, because that is the case it was never tested on.
Cost asymmetry and why campaigns persist
Multi-vector campaigns tend to run longer than single-vector floods, and the reason is economic rather than technical. Rotating vectors costs an attacker very little — the same botnet that emits a volumetric flood can generate handshakes or application requests with a configuration change — while each rotation may require the defender to involve a different team, a different vendor, or a different escalation path.
That asymmetry is worth naming explicitly when planning. Defences that depend on a human deciding which vendor to call, or on approval to activate a paid mitigation tier, convert an attacker's cheap change into an expensive one for you. Pre-authorising those decisions in advance — with clear thresholds, and standing approval to act on them — removes the delay the campaign is designed to exploit.
It also explains why extortion-linked campaigns favour this pattern. Repeated, adaptive disruption demonstrates persistence in a way a single large flood does not, and persistence is the leverage being sold.
Distinguishing an attack from a traffic event
Not every simultaneous failure is an attack, and treating a legitimate demand spike as one leads to blocking real users at the worst possible moment. Genuine surges — a product launch, a news mention, a partner integration going live — can also degrade several tiers at once.
Signals that usually separate the two:
- Geographic and network distribution. A demand spike broadly resembles your existing user mix; an attack rarely does.
- Request composition. Real users fetch pages and their assets in recognisable sequences; attack traffic tends to hit a narrow set of endpoints with no supporting requests.
- Client characteristics. Sudden uniformity in user agent, TLS fingerprint or header ordering across a large source set indicates automation.
- Behaviour under mitigation. Legitimate traffic degrades gracefully and retries sensibly; attack traffic frequently changes shape the moment a control is applied.
- Correlation with something real. If nothing in the business explains a fivefold rise, that absence is itself evidence.
Also known as
What defenders may observe
- Protocol mix and traffic shape change during the incident
- Multiple infrastructure tiers degrade at different times
- Mitigating one vector reveals another already in progress
- Near-vertical bursts separated by regular quiet intervals
- Services recover briefly and then fail again on a repeating cycle
Prevention and mitigation
- Operate always-on rather than reactive mitigation
- Correlate telemetry across network, transport and application in one view
- Avoid mitigation designs that depend on withdrawing and re-announcing routes
- Pre-agree escalation paths and thresholds with upstream providers
- Rehearse the runbook against combined vectors rather than a single flood
Initial response priorities
- Shift mitigation upstream before the circuit saturates.
- Compare packet rates, flags and source distribution with the baseline.
- Rate-limit or filter the affected service without blocking known-good traffic.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.