DDoS defences have spent years optimising for the wrong problem. While headlines chase record-breaking floods of traffic, a steady drumbeat of low-volume attacks keeps knocking services offline because they look almost normal.
The uncomfortable truth is that an attacker who keeps their traffic small, slow, and patient can take a service down more reliably than someone throwing 71 million requests per second at it.
High-Volume vs. Low-Volume DDoS: How They Differ
| High-Volume Attack | Low-Volume Attack | |
|---|---|---|
| Traffic level | Massive flood (often millions of RPS) | Modest stream; easily below daily peak |
| Detection | Obvious anomaly; straightforward to flag | Mimics slow users; rate-limits miss it |
| Resources needed | Large botnet or bandwidth purchase | Can run from one machine |
| Cost to launch | Significant; DDoS-as-a-service starts at ~$500 | Minimal; same price point, higher success rate |
| What it targets | Network bandwidth and infrastructure | Application resources: session tables, DB pools |
| Common tools | Botnets, amplification protocols | Slowloris, Tor's Hammer, THC-SSL |
| Why it wins | Volume overwhelms | Persistence and stealth |
The "Key facts" bullets are just restating facts—need to make this more of a comparison/decision table as required
Why the small stuff hurts more
The classic mental model of a DDoS attack is a firehose: so much traffic that the target collapses under the weight. That picture is wrong in two ways. First, attackers have learned that modest, well-shaped traffic is enough to starve an application of some specific resource, like database connections or session pools. Second, large floods are easy to detect, which makes mitigation straightforward, while a slow drip looks like a slightly annoyed user.
Low-volume attacks tend to target HTTP and HTTPS, and sometimes use slow TCP sessions aimed at any TCP-based service. Common tools include Slowloris, Tor's Hammer and THC-SSL. None of those require a botnet. They can be run from one machine, which is why DDoS-for-hire services love them: they are cheap, they work, and the customer gets a receipt.
The other uncomfortable stat: even with a DDoS protection solution in place, organisations can still face up to 75 percent exposure to DDoS. The protection covers what it sees, and what it does not see is where damage happens.
Why this matters
Most enterprise DDoS spend goes to capacity, big-pipe scrubbing, and a CDN that absorbs floods. That is the right spend for headline attacks, but it does not catch the patient ones. Application-layer attacks at modest volumes look like real users with bad manners, and most rate-limiting logic is too crude to tell the difference.
The cost numbers are bracing. Five percent of organisations hit by DDoS lost more than $1 million from a single incident, and LG Uplus reportedly suffered over $100 million in damages, compensation and upgrades from one attack. The economics favour the attacker every time.
What it means for you
Imagine running an online portal where users file claims, and a trickle of slow HTTPS requests starts consuming your session table. Legitimate users get random logouts, support tickets climb, and your monitoring dashboard shows nothing alarming because total traffic is below last Tuesday's peak. That is a textbook low-volume attack.
The fix is not more bandwidth. It is behavioural baselining, per-endpoint connection caps, and synthetic probes that constantly exercise the service so you notice when real traffic quietly degrades. You also need a DDoS posture assessment tool that runs non-disruptive, continuous checks against all known and unknown vectors, not just the loud ones.
Who should care
- SOC analysts:** most low-volume attacks look like application bugs, not DDoS, until you correlate them.
- SRE and platform teams:** capacity planning around big floods does not protect you from the small, slow kind.
- CISOs at SaaS and e-commerce firms:** customer-visible downtime from low-volume attacks drives churn harder than headline outages.
- Procurement:** a DDoS scrubbing contract is not a complete answer if it cannot see slow application-layer abuse.
- CTI teams:** track low-volume tooling and DDoS-for-hire pricing as leading indicators.
What to watch next
Watch the mix. Attackers increasingly combine low-volume vectors with larger floods in the same campaign, which defeats single-vector defences. Also watch for growth in slow-protocol abuse against HTTPS endpoints, where the cost per request to the attacker is lowest and the visibility for defenders is worst.
Bottom line
Stop measuring DDoS defence by gigabits per second. Measure it by how many attack shapes you can detect at any volume, including the quiet ones. If your protection only catches the flood, you are paying to block the attack you would have noticed anyway.
Key takeaways
- Low-volume DDoS attacks are cheaper, quieter and often more successful than headline floods.
- They target application and session resources, not raw bandwidth, so capacity alone does not stop them.
- Real defence needs continuous, non-disruptive testing against all vectors, including slow ones.
- Behavioural baselining and per-endpoint caps matter more than peak-throughput claims from vendors.
Frequently asked questions
Can a single laptop really take down a service with a low-volume attack?
Yes, when the attack targets a specific resource like a session table or database connection pool rather than bandwidth.
Do DDoS scrubbing services catch these attacks?
Often not. Most scrubbing is tuned for high-volume floods, and slow application-layer attacks can look like legitimate traffic.
Are slow attacks only used against web apps?
No. They can also target any TCP-based service by holding sessions open with very slow transfer rates.
How do I tell a low-volume attack from a buggy app?
Look for correlated symptoms across endpoints, rising error rates without traffic spikes, and patterns that line up with public DDoS-for-hire tooling.
Source: mazebolt.com