When nearly every legitimate packet arriving at a network already carries the ACK flag, a flood of forged ACKs is the hardest one to sort by its looks. That is an ACK flood, and finding the point where a path finally tells the two apart is one of the jobs a DDoS test is built for. The attacker sends TCP segments with ACK set that belong to no connection, usually from spoofed sources, and leaves every device that tracks state to discover the mismatch one lookup at a time.
How an ACK flood works
It is a protocol attack: small segments, sized in packets per second, aimed at the boxes that keep connection state rather than at the link. What sets the ACK apart from the other flag floods is how ordinary it is. After the opening SYN, every TCP segment in both directions carries ACK: each request, each upload, each keepalive. A filter that drops on the flag drops the business.
Botnets ship it as a stock option. The Mirai source code, published in 2016, includes an ACK flood that pads each segment with 512 bytes of random payload by default. It also includes a variant called STOMP, which completes a real handshake first and then floods segments inside that connection using the sequence numbers it has learned. Stateful filtering has nothing to say about STOMP, because those segments belong to a connection that genuinely exists.
Why it matters under attack
Three places in a path meet an ACK flood differently.
The stateful firewall
On a stateful firewall or load balancer, a forged ACK costs a lookup and a miss. The table itself is only at risk where loose pickup lets an ACK create an entry, a case the PSH-ACK flood page covers. For a plain ACK flood against strict tracking, it is a CPU race.
The SYN-cookie check
This is the trap specific to the ACK. A host or SYN proxy defending itself with SYN cookies has to treat any ACK it cannot match as a possible cookie reply, and test it by recomputing a keyed hash. The Linux kernel does this for every unmatched ACK to a listener that has issued cookies in the last two minutes, and netfilter's SYNPROXY recipe sends every out-of-state ACK to the same check by design.
So pair a SYN flood, which switches cookies on, with an ACK flood against the same port. The defence that made the SYN flood cheap now charges a hash for every forged ACK. Every check fails and nothing is admitted, but the CPU is gone.
The inbound-only scrubber
Cloud scrubbing often sees only half of each conversation: traffic is diverted in through the scrubber, and the origin's replies go straight back to the internet. Without the server's SYN-ACK, the scrubber cannot keep a true connection table. What it can do is remember which source addresses and ports sent a SYN on the way in, and distrust ACKs from tuples that never did.
That works until the moment of diversion. A session opened before traffic was swung into the scrubber had its SYN seen by nobody. A strict version of that filter cuts every long-lived connection at cutover; a lenient one lets the flood through while it learns.
What a DDoS test measures
A test records the forged-ACK rate each stateful tier absorbs before CPU saturates and real sessions begin to stall, per device, because the load balancer and the host firewall rarely give out at the same rate.
It then runs the combination deliberately: a SYN flood to switch cookies on, then an ACK flood at the same listener, comparing host CPU against the ACK flood alone. A large gap means the cookie check is where the budget goes, and the fix is stateless filtering upstream, not more cookies.
If mitigation is on-demand, it also measures the cutover from the user's side: whether long-lived connections such as WebSockets, database links and streaming sessions survive the swing into scrubbing, and for how long a learning ACK filter lets the flood through. What that means for where the scrubbing sits, and whether it is in the path at all before the attack starts, is worked through in Is Your Protection Actually in the Path?