Pulse Wave Attacks

Most attacks try to exceed a capacity. A pulse wave tries to exceed a reaction time, which is a smaller and more reliably available number.

The pattern is simple: a burst at high rate for a short period, a quiet gap, another burst. No individual burst needs to last long enough for anything to complete a response, and the gaps are long enough that automatic mitigation stands down between them.

At a glance

Appliance	Defence	Behaviour under a sustained flood	Behaviour under a pulse wave
Inline, always-on	Acts immediately	Acts immediately; the pulse offers no advantage
Inline, on-demand	Acts within a detection interval	Engages late in each burst, stands down between them
Out-of-path, on-demand	Diverts, then cleans	May never complete a diversion before the burst ends
Upstream request by phone	Slow but effective	Useless; the burst is over before the call connects

Only the first row is unaffected. Every other design is being measured on an interval the attacker chose after observing it.

What it exhausts

Not one resource but a sequence of them, briefly.

Each burst does whatever a short high-rate flood does: fills queues, drops legitimate packets, saturates a link or a lookup budget. Then it stops, so nothing reaches the sustained state that most detection is tuned to notice.

The resource genuinely being exhausted is response capacity: the detection interval, the diversion time, the operator’s attention, and in some designs an upstream allowance that is consumed on engagement rather than on volume.

How it differs from similar attacks

A sustained flood is a contest of capacity, and the defender either has enough or does not.

A pulse wave is a contest of latency. The relevant figure is not how much traffic the defence can absorb but how long it takes to start absorbing, and that figure is a property of the architecture rather than of the equipment’s rating. The two axes are separated in inline or out-of-path, and this attack is the reason the distinction is worth drawing carefully.

It is also close kin to multi-vector campaigns. Pulsing attacks the timing; changing vector between pulses attacks the classification. Combined, they leave a response process restarting continuously.

Observable telemetry

• A square-wave shape in packet rate or bit rate: rapid rise, plateau, rapid fall, repeat.
• Mitigation engaging and standing down repeatedly, visible in the device’s own event log.
• Legitimate traffic dropping during bursts and not fully recovering between them, because clients are retrying.
• Averaged graphs looking almost normal, which is the reason this is missed. A five-minute average of thirty-second bursts shows a modest elevation.
• Flow-based detection reporting nothing, where the export interval exceeds the burst.

The first thing to do when a pulse wave is suspected is look at the raw resolution. Anything averaged conceals the pattern that names the attack.

Common false positives

Scheduled batch traffic. Backups, replication and reporting jobs produce genuine square waves, and an estate that has never characterised them may mistake them for an attack.

Application retry cycles. A failing dependency can produce synchronised bursts of client retries that look identical from the network.

Both are reasons to characterise your own periodic traffic before tuning anything to react to bursts.

Mitigation by layer

Always-on enforcement is the structural answer. If mitigation never stands down, burst timing buys nothing. This is the one case where the everyday cost of always-on is straightforwardly worth paying, and the decision belongs in the architecture rather than in the runbook.

Shorten the loop rather than widening the pipe. Faster detection, pre-armed diversion, and automatic engagement for clear signatures. The reasoning about what may be automated is in how much automation, and pulse waves push the line toward more.

Add hysteresis and a hold period. Mitigation that stays engaged for a defined period after traffic normalises stops the stand-down between bursts. This single setting converts many pulse waves into a sustained-mitigation case, and it is frequently left at a default measured in seconds.

Increase telemetry resolution on the internet-facing path, at least during investigation, so the pattern is visible at all.

Operational pitfalls

Declaring the incident over during a gap. The commonest mistake, and the one that produces a sequence of separate incident tickets for what was one campaign.

Tuning thresholds down after each burst. Each adjustment is reasonable and the accumulation is not, and by the fourth burst the estate is refusing its own users.

Trusting averaged dashboards. They are the reason the attack is described as invisible when it is merely under-sampled.

Safe validation

Generate bursts at your circuit’s small-frame packet rate, thirty seconds on and ninety seconds off, and measure two things that no sustained test produces: time from burst start to enforcement, and whether enforcement stands down before the next burst.

Then set the hold period from the measured gap and run it again. The difference between those two runs is the value of one configuration setting, and it is usually larger than the difference between two products.

The scenario belongs in the standard set in the test lab guide; the legal groundwork is in authorised testing.