News & events
Attackers Use DDoS Pulses to Pin Down Multiple Targets

Over the last few months, Imperva Incapsula has witnessed the emergence of a new assault pattern, which we have come to call a “pulse wave” DDoS attack.

Comprised of a series of short-lived bursts occurring in clockwork-like succession (Fig. 1), pulse wave assaults accounted for some of the most ferocious DDoS attacks we mitigated in the second quarter of 2017. In the most extreme cases, they lasted for days at a time and scaled as high as 350 gigabits per second (Gbps).

Following a review, we believe these represent a new attack tactic, designed to double the botnet’s output and exploit soft spots in “appliance first cloud second” hybrid mitigation solutions.

The following is a summary of our pulse wave attack analysis, described at further length in a whitepaper.

Two Birds with One Pulse

A DDoS attack typically takes on a wave form, with a gradual ramp-up leading to a peak, followed by either an abrupt drop or a slow descent. When repeated, the pattern resembles a triangle, or sawtooth waveform (Fig. 2).


The incline of such DDoS waves marks the time it takes the offenders to mobilize their botnets. Its existence speaks to the intricacy of rallying up these geographically dispersed networks—comprised of tens of thousands of disparate devices.

For pulse wave attacks, a lack of a gradual incline was the first thing that caught our attention. It wasn’t the first time we’ve seen attacks ramp up quickly. However, never before have we seen attacks of this magnitude peak with such immediacy, then be repeated with such precision.

Whoever was on the other end of these assaults, they were able to mobilize a 300Gbps botnet within a matter of seconds. This, coupled with the accurate persistence in which the pulses reoccurred, painted a picture of very skilled bad actors exhibiting a high measure of control over their attack resources.

Still a bigger question remained: Why were they doing this? What could be gained by chopping the attack traffic?

The logical answer to these questions occurred when we started thinking about what happens during the gaps between pulses.

We realized it makes no sense to assume that the botnet shuts down during those brief “quiet times.” Instead, the gaps are simply a sign of offenders switching targets on-the-fly, leveraging a high degree of control over their resources.

This also explained how the attack could instantly reach its peak. It was a result of the botnet switching targets on-the-fly, while working at full capacity.

Clearly, the people operating these botnets have figured out the rule of thumb for DDoS attacks: moments to go down, hours to recover. Knowing that—and having access to an instantly responsive botnet—they did the smart thing by hitting two birds with one stone.

Jamming ‘Appliance First’ Hybrids

The idea of bad actors doubling up attack output is a cause for concern for all online organizations. As it happens, the pulse-like nature of the assaults can be particularly harmful to solutions having an ‘appliance first, cloud second’ hybrid approach to DDoS mitigation.

As the name implies, the idea behind such setups is to make the on-premises appliance a first line of defense against DDoS attacks and use the cloud as an on-demand backup option, for extra scalability.


This topology is generally suitable for dealing with DDoS assaults that build up over time. However, it runs into issues when used to mitigate attacks that peak quickly, since a proper failover to the cloud takes (at least) several minutes to complete.

A pulse wave attack, having no ramp-up time, represents a worst case scenario for any network defended by such hybrids. As soon as the first pulse hits, it immediately congests the traffic pipe—cutting off the network’s ability to communicate with the outside world. This not only results in a denial of service, but also prevents the mitigation appliance from activating the cloud scrubbing platform.

For the pulse duration, the entire network shuts down completely. By the time it recovers, another pulse shuts it down again, ad nauseam. If at some point the cloud is reconfigured to automatically activate itself at the sign of trouble, the scrubbing process is still significantly delayed because of the verification process.

Additionally, the lack of communication prohibits the appliance from providing information required to create an attack signature. Even if the cloud does eventually come online, it still has to resample the traffic from scratch before initiating the filtering process.

This all adds up to several mitigation process delays—minutes wasted at a time when every second counts.