An extortion note is the only attack that arrives with a preview, a size and a date.
Most DDoS planning starts from a guess about what an attacker might do. A ransom DDoS removes most of the guessing. The sender has already shown you a sample, told you how big the next one will be, and named the day.
The history of these campaigns, and why paying buys nothing, is on the definition page. Whether to engage, who reports it and what the board hears belong in a DDoS tabletop exercise. What follows is the engineering half: what each part of the note lets you measure, and what you can still change before the date.
What is ransom DDoS testing?
Ransom DDoS testing is an authorised test built around the shape of an extortion campaign: a short demonstration attack, a threatened attack of a stated size, and a deadline measured in days. It measures whether the demonstration was detected, whether every address the attacker can reach has protection upstream of your circuit, and how many hours it takes to move each announced prefix onto scrubbing.
The output is a per-prefix answer with a time attached, not a pass mark. A criminal's involvement changes nothing about permission or safe ramps; both are in the complete guide to DDoS testing.
| Part of the note | What it gives away | What the test measures | Best measured |
|---|---|---|---|
| Demonstration | The attacker's vector, size and choice of target | Whether anything fired before the burst ended | Before any note, then again from the demo's own records |
| Claim | A threatened size and a named target | Your circuit's line rate, the scrubbing behind each prefix, every reachable address | Before any note |
| Deadline | The time you have | Hours to pre-divert each prefix, and what cannot be done in that time | Before any note, as a drill |
What does the demonstration attack tell you?
More than the sender intends. A demonstration is a live sample of the capability being sold to you, aimed at your real infrastructure, at a time the attacker chose.
It is the only sample you will get for free
Every other DDoS test you run uses traffic you designed. This one used traffic someone else designed, with their vector choices and their idea of where you are weak. Treat it as a test result you did not have to commission.
Your own graphs saw a clipped version
An interface counter on your edge router can never report more than the circuit's line rate. A 40 Gbps flood against a 10 Gbps circuit shows up on your own dashboards as a flat line at 10, the same picture a 12 Gbps flood would give.
So the true size of the demonstration lives upstream. Ask your transit provider, or the scrubbing provider if it saw the traffic, for their peak in bits and packets per second. Without it you cannot tell whether the claim in the note is a bluff or an understatement.
What it hit is the most useful line in the report
Check where the demonstration went. Traffic aimed at a hostname that resolves to your CDN tells you the attacker went through the front door. Traffic aimed straight at an address in your own range tells you they bypassed it, and that the origin is already known. How attackers find a hidden origin is covered in depth elsewhere; the demonstration tells you whether they already have.
A burst spread thinly across a whole prefix says something different again: the target is your network, not your application.
Did anything fire before it ended?
Write down the timeline from the provider's data and your own. When did the first packet arrive, when did any alert fire, and did any rule or diversion engage before the burst stopped?
A short demonstration can finish inside the window between detection and mitigation, and then the logs show nothing at all. That is not evidence of protection. It is evidence of a gap the size of the burst. The mechanics of that window for on-demand scrubbing are measured in the on-premise DDoS testing post; here the point is narrower. Flow collectors that export long-lived flows only on a long active timeout can report a ten-minute burst after it has already ended, which is a mean time to detect problem the demonstration exposes for free.
Keep the evidence before it ages out
Flow records, firewall logs and provider graphs all have retention limits, some of them measured in days. Export a copy of everything covering the demonstration window as soon as the note arrives, along with the note itself and its full headers. Law enforcement and your own later analysis both need the raw records, not a screenshot of a dashboard.
Does the test have to match the threatened size?
You do not need to. The threatened number decides which part of your defence is responsible, not how big your test has to be.
Two ceilings decide where the fight happens
The first ceiling is your circuit. Anything larger than its line rate is lost before it reaches a single device you own, so firewalls, load balancers and on-premise appliances are irrelevant above that line. The second ceiling is the capacity behind your prefix at the scrubbing centre, which is a per-customer allocation, not the provider's headline figure.
If the claim sits below your line rate, your own stack has to absorb it. If it sits above, only upstream filtering matters, and the question becomes whether that filtering is in place in time.
Inside the pipe, test the stack
Below line rate, the test is a conventional one: drive the likely vectors at your own edge, up to the circuit's capacity, and find the layer of first failure. A test that goes beyond your circuit only proves that a pipe of a known size fills.
Above the pipe, test the swing
Above line rate, the thing to test is the move onto scrubbing: how long it takes, whether every prefix moves, and whether clean traffic comes back. That is a routing exercise, and it can be run without generating a single packet of attack traffic.
The name in the note is rarely the whole target
A note usually names your brand or your main website. Campaigns often hit something else: whatever sits in the same address range and was never put behind a filter.
The target set is every address you announce
Whether or not anyone thinks of an address as a service, if it is in a prefix you announce, the flood can reach it.
A CDN protects a hostname, not an address
Putting your website behind a reverse proxy changes where the name resolves. It does nothing for the address the site used to answer on, which sits in your announced range and still reaches your circuit. Anything already recorded against that address in passive DNS, certificate logs or old mail headers still points at it.
The quiet addresses are the usual casualties
The test inventory should include the services nobody lists under "the website": the authoritative DNS servers that answer for every name you own, the mail exchanger where the next note will arrive, the remote-access gateway your responders need in order to work, and the router interfaces at your edge. Each sits in the same prefix and shares the same circuit.
Detection usually watches a list
On-demand protection is often triggered by thresholds on a list of protected addresses agreed in the contract. A flood that spreads thinly over every address in a /24, the carpet-bombing pattern, can stay under every per-address threshold while the circuit fills. The test is to compare the contract's list against the full announced range and see what is missing.
What can you change before the deadline?
Anything that only involves you can happen in hours. Anything that needs another organisation to update a record can take days. Find out which is which before a note ever arrives.
Turn on-demand into always-on for the window
If your network sits on on-demand scrubbing, the strongest move inside a deadline is to divert ahead of the attack and stay diverted until the risk has passed. That removes the detect-and-divert window from the equation, at the cost of running all traffic through the provider for a while. The general trade between the two postures is laid out in DDoS protection in the path; a ransom note is simply the case where that trade is easy to make.
Pre-diversion only works if the diversion has been built and tested. That is the part a test has to time.
The records that let someone else announce your prefix
For a scrubbing provider to attract your traffic, it has to announce your prefix to the internet, and the internet has to believe it. Four things need to exist before that happens:
- A letter of authorisation (LOA) that permits the provider to announce your prefix. Without it, the provider will not, and should not, announce anything.
- An IRR route object for the prefix with the provider's origin ASN. Transit networks build their customer filters from these records; without one, the provider's own upstreams may drop the announcement.
- An RPKI ROA that matches what the provider will announce. If you have ROAs that name only your own ASN, the provider's announcement is RPKI-invalid, and networks that validate will discard it. Some providers can originate with your ASN instead, which changes the record you need; find out which model yours uses.
- A return path for clean traffic, a tunnel or a cross-connect, tested at production volume. The tunnel overheads and MTU problems are a clean pipe topic and are measured in the on-premise post.
Only after all four does the announcement itself, and the BGP convergence that follows, become a matter of minutes.
maxLength is the quiet failure
A ROA also carries a maximum prefix length. Suppose you announce a /22 and your ROA allows nothing longer. When the provider announces the /24 inside it to win traffic by longest match, that /24 is invalid even if the origin ASN is correct. It is a one-line change in your RIR portal, and it does not take effect for the rest of the internet until validators have refreshed.
The /24 floor
Most networks drop IPv4 routes longer than a /24, and IPv6 routes longer than a /48. So the smallest unit you can move onto scrubbing is a /24. Everything that shares it goes too: the service under threat, the VPN, the mail server, the office NAT address.
If you already announce at /24, there is no more-specific left for the provider to win with. It announces the same /24, you withdraw yours, and the swing depends on path selection and convergence rather than on the longest match. That is slower and less predictable. The drill is where you find out how much.
DNS moves are gated by the old TTL
Moving a service behind a proxy by changing its DNS record takes effect only as resolvers' caches expire. A record published with a one-day TTL can keep sending clients to the old address for a day after the change. Lower the TTL first, wait out the old one, then move. And an attacker who already recorded the address will keep sending traffic there, whatever the record now says.
What will not fit in the window
A new scrubbing contract, a new transit circuit, renumbering out of a shared range, and your own ASN all take weeks. A ransom DDoS test run in quiet times should produce a short list of exactly these items, because a note will not give you time to start them.
What is safe to test once a note has arrived?
Carefully, and with fewer packets than you might think.
Tell the provider and the transit carrier first
Synthetic traffic that arrives during an extortion window looks exactly like the attack. Unannounced, it can trigger the provider's own mitigation, pollute the evidence, or send the incident team after a flood your own engineers started. Agree the window, the source addresses and an abort contact before anything is sent.
Prefer the diversion drill to a flood
The most valuable test inside the window is the swing itself: announce, confirm that traffic arrives through the provider and that clean traffic returns, then decide whether to stay diverted. It produces evidence and protection at the same time. A load test inside the window adds risk and answers a question the demonstration already partly answered. If you do send traffic, the non-disruptive testing rules apply as written.
Do not overwrite the evidence
Test traffic written into the same flow collectors and logs as the demonstration makes both harder to read. Tag the test, keep its sources distinct, and export the demonstration records before you start.
The date passing quietly is not the end
Many notes are never followed by an attack. Some are. Published reporting on the 2020 and 2021 waves describes groups returning to earlier targets months later. When to withdraw a pre-diversion is a risk decision for the people side of the exercise, but the engineering record should state what is still exposed if you do.
A ransom DDoS testing checklist
- List every address in every prefix you announce, and mark which ones sit on the provider's protected list.
- Record your circuit's line rate and the per-prefix scrubbing capacity in your contract.
- Confirm that your transit provider will share upstream peak bps and pps for an incident, and how fast.
- Check flow export timeouts and log retention against a burst measured in minutes.
- For each prefix, confirm the LOA, IRR route objects, ROAs and their maxLength match the announcement the provider will make.
- Test the return path at production volume.
- Run a timed diversion drill per prefix, from the decision to divert to clean traffic flowing.
- Note which prefixes are already announced at /24, and how the swing behaves there.
- Write down the fixes that take weeks, and start them now.
- After a real note: export the demonstration records first, then decide on pre-diversion, then test.
FAQ
What is ransom DDoS testing?
It is an authorised test shaped around an extortion campaign. It checks whether a short demonstration attack would be detected, whether every announced address has protection upstream of the circuit, and how long each prefix takes to move onto scrubbing before a stated deadline.
Should we run a DDoS test after receiving a ransom note?
Run a diversion drill, not a flood. Tell your scrubbing and transit providers first, export the demonstration's records, and use the window to move prefixes onto scrubbing ahead of the deadline. A large load test inside an active extortion window adds risk and muddies the evidence.
How big an attack should a ransom DDoS test simulate?
Up to your circuit's line rate, against your own stack. Above that, nothing you own is involved, so the test is whether traffic swings onto upstream scrubbing in time, which needs no attack traffic at all.
Does on-demand scrubbing protect against a ransom DDoS?
Only if the diversion is already built and the protected list matches your real address space. A short demonstration can finish before on-demand mitigation engages, and a flood spread across a whole prefix can stay under per-address thresholds. Pre-diverting for the duration of the threat closes both gaps.
Why does our own monitoring show a smaller attack than our provider reports?
Your interface counters cannot exceed the circuit's line rate. Any flood larger than the pipe appears on your graphs as a flat line at capacity, so the real size is only visible upstream.
The deadline is the attacker's schedule, not yours
The note frames everything around one date: theirs. Every useful number in a ransom DDoS test is measured on a different clock. How many hours it takes to move a prefix, how many days a missing ROA takes to fix, how many weeks a new circuit needs.
The specifics will keep moving: which providers validate RPKI, how many addresses your network announces, what the next campaign signs itself as. The method will not. Read the demonstration as data, test against your own ceilings rather than the attacker's claim, and time the swing before anyone sends a note.
A team that knows its own numbers can read a deadline calmly. A team that does not has to take the sender's word for how bad things will get.