A ransom DDoS (RDDoS) was first seen at scale in 2014 and 2015, when a group calling itself DD4BC, short for "DDoS for Bitcoin," emailed businesses a payment demand and a deadline and backed the threat with a live flood. It still matters because the tactic recurs in waves rather than fading, which is why a thorough DDoS test now treats extortion as a threat model in its own right, not just another traffic pattern. The floods themselves are ordinary volumetric, protocol, or application-layer attacks. What defines a ransom DDoS is the commercial coercion wrapped around them: the operator either launches an attack and demands payment to stop it, or sends a note threatening a crippling attack unless a cryptocurrency payment arrives before a stated deadline.
The coercion loop
The playbook is consistent across campaigns. A note names a price in Bitcoin, sets a deadline, and often includes a short demonstration burst, tens or hundreds of gigabits for half an hour, to prove the sender can follow through. The demonstration is the leverage: it turns an email that would otherwise read as a bluff into a credible threat, and it does so cheaply, because a brief burst costs the attacker almost nothing compared to a sustained campaign.
The names attached to the notes are usually borrowed. After DD4BC members were arrested in a 2016 Europol operation, later waves signed themselves "Armada Collective," "Fancy Bear," or "Lazarus Group," impersonating known threat actors to make the threat sound heavier than it was. That borrowing is a tell in itself. In one widely documented 2016 wave, the same "Armada Collective" note went to many companies at once, demanded payment, and was never followed by any attack at all; the whole campaign was a mass-mailed bluff that collected on fear alone.
The distinction from ransomware matters because the defenses are different. Ransomware encrypts or steals data and holds the copy hostage; a ransom DDoS touches no data and steals nothing. Its only leverage is downtime, the threat that a service will be unreachable. That means there is nothing to decrypt or recover after the fact, and the entire question is whether the service can stay up under the threatened load.
Why paying is not a control
The note is engineered to make paying feel like the fast, safe option, and it is neither. Payment funds the next campaign and buys no guarantee: nothing stops the same operator, or a different one reading the same news, from returning to a target that has shown it will pay. It also marks the victim on lists that extortionists share and revisit. The real 2020 wave that knocked the New Zealand stock exchange offline for several trading days made the point plainly: the organizations that weathered it were the ones whose mitigation held, not the ones weighing a payment.
The defensive question a note forces is uncomfortable but simple. If the threatened attack arrived at the stated deadline, would the stack hold? A team that cannot answer that with evidence is left choosing between paying a criminal and hoping, and both are worse than knowing.
What a DDoS test measures
Because the floods are ordinary, testing for a ransom DDoS is testing the resilience the note is betting against. A test drives the volumetric, protocol, and application-layer vectors the campaign is likely to use and answers the two questions the deadline raises: does mitigation engage fast enough, measured as time to mitigation, and can the layer of first failure absorb the threatened volume before users notice?
The value of that answer is that it converts an extortion deadline into a bounded, known risk instead of a panic decision made under a countdown. A verified result turns "we think we would survive" into a number, and a number is what removes the leverage the note depends on.
For how to measure that resilience under a realistic load rather than guessing at it, see DDoS Resilience Testing.