Whack-A-Mole // a Serial Carpetbombing - Attack

During our DDoS-Assessments we see a lot of different behaviors on attacked systems/protections; some react without any delay, some have a short gap of 10-60 seconds when attacking an IP with enough volume to saturate the uplink.

In the screenshot below you see this behavior during a THOR-attack ( see this german article on that specific attackmode).

10 GB/s hits a 1 GB connection, protected by a hybrid anti-ddos-solution with an appliance for detection/bgp-rerouting and a scrubbingcenter that washes the attacking traffic successfully after 15 seconds.

This behavior might be sufficiant for most cases as a protection against usual botnet attacks where a short hickup might get mostly unnotized.

We tested this delay-behavior and found out

• if we changed the attacking methds/vectors like TCP<->UDP, changed ports and payloads, but kept the attacked IP the same, no delay was discovered
• if we change the attacked IP, then again we have this delay in protection, varying from 10 - 60 seconds on this particular test, but we have seen up to 180 seconds with other clients and setups

But ...

Having carpetbombing in mind and also available as testmethod, a new attack came into mind: not attacking all IPs, lets say from a /24 simultaneously (parallel), but one after another (serial), always selecting a new random IP after the mitigation kicks in.

The workflow for the attack is as follows:

• 10 select a CIDR to attack; /27/26 might be sufficient, but the bigger, the better
• 20 select a random IP from this CIDR, attack
• 30 wait for the target to be unreachable, start monitoring (see sleep(10) in the chart)
• 40 wait for the mitigation to kick in
• 50 if monitoring detects the target is back online
• GOTO 20

For a given /24, his method would give a significant downtime. Lets say we have a mitigation-delay of 30 seconds for each attacked IP we'd have a downtime of 2hrs+ (naive approach)

Initial Release: Oktober 2021, under embargo
Embargo Until: Jun 2023