Preface: This is a reupload and english translation of an article we released 2018 on the original version of the cybervandals-blog. Since then, short burst attacks are a staple in the attackers arsenal.

We have developed attack methods for our DDoS-attack-simulations that are rarely or not found In-The-Wild and that, according to the DRS-Score, are more likely to be observed at level 5 and above. This article deals with one such attack that we developed in 2015 and have repeatedly used successfully since then.


Bleeping-Computer reported about it almost a year ago (Pulse Wave - New DDoS Assault Pattern Discovered), that this attack method was spotted as part of a botnet attack, so we see no problem in publishing our own information about it.

THORS Hammer attack explained



Our automated stresstest platform had a feature called "Tsunami" from the beginning, in which the attack traffic hit the target in a large wave, just as would be expected in a real botnet attack: Ramp-Up-time == 0.

We have further developed this feature so that our stress test "botnet" can fire in coordinated time intervals, all at the same time, e.g., 10 seconds ON, then 30 seconds OFF, coordinated and orchestrated by the stress test master, which can time the ON/OFF command to the millisecond. We named the attack "Thor's Hammer" because the attack reminded us very much of "hammering away with heavy equipment."

The methodology is independent of the type of attack and works for volumetric attacks and Layer-7 attacks against various devices, appliances, and solutions.

Image courtesy of "Bleeping-Computers"



Here are a few examples of problems we encountered when using this attack method:

  • Hybrid solutions with on-premise appliances that automatically reroute to the scrubbing center (and back) could be brought into "flapping," i.e., frequent back-and-forth switching. Result: 50% packet loss. Mitigation: Switch to scrubbing center automatically, switch back manually.
  • Hybrid solutions with incorrectly configured feedback channels went offline with the first wave and were no longer able to send a quiet "Please Help!"
  • Load balancers/TLS offloaders went into a reboot cycle with every hammer blow, even when only 25% of the defined number of HTTPS sessions were used (here: 5k bots with advertised 20k parallel sessions).
  • Firewalls either went completely offline, to bypass, or were unresponsive with 100% CPU usage and had to be manually rebooted.

And if an attack did make it through to the actual server, the first wave made the CPUs glow, while the subsequent waves always hit just as the load time was recovering.

This attack method has been available (limited) through our stress test platform since 2016; below is a screenshot of probably the ugliest web UI in the world, which we are currently redesigning to make the stress test platform available to our customers as well.