Ransom DDoS: what to do about an extortion email

What a ransom DDoS attack is

A ransom DDoS attack — RDoS, also called DDoS extortion — inverts the usual order of events. Instead of taking your site down and waiting for you to notice, the attacker emails first: transfer a sum in cryptocurrency by a stated deadline, or the flood begins. Some senders schedule a short burst of traffic as proof they can follow through. Many attach nothing but the threat.

The model works because the economics are absurdly one-sided. Sending ten thousand threatening emails costs nothing. Renting enough attack capacity to knock over one unprotected website costs a few dollars an hour. If a single recipient in a thousand pays, the campaign turns a profit — whether or not a single packet is ever sent.

That is worth internalizing before you read the message again: you are almost certainly not being singled out. You are on a list.

Anatomy of the ransom note

Ransom notes are strikingly similar across campaigns, because they are copied from one another. The structure is nearly always the same.

Bluff or credible: how to tell

Only two things in the email can actually be checked — whether an announced demo attack happens, and whether it does what the sender claimed. Everything else is text anyone can type.

Signals of a bulk bluff:

• It arrived at a generic mailbox (info@, contact@, abuse@) or an address scraped from WHOIS records.
• No demo attack was announced — or one was, and the window passed with nothing in your graphs.
• The message never names your company, your domain or anything specific about your application.
• The same wallet address appears in public reports from unrelated recipients.
• The named group is defunct, or was never a DDoS operator to begin with.

Signals worth taking seriously:

• A measurable traffic anomaly at the exact announced time, visible in your own logs.
• The demand references genuine specifics: a hostname, an API path, a recent launch.
• The demo traffic targeted something expensive — checkout, login, search — rather than your homepage. That is a fingerprint of Layer 7 targeting, and it means somebody looked at your site.
• Your origin IP address is publicly discoverable, so the attacker does not need to get through a filter at all.

Treat "bluff" as a probability, never a verdict. The distinction matters far less than it feels like it should, because the response is identical either way — and it is the same response that protects you from the much more common attack that arrives with no warning email whatsoever.

Why paying is the wrong move

This is not a moral argument. It is an operational one.

1. Nothing is delivered. You are not buying a decryption key, as in a ransomware case — there is no artifact to hand over. You are buying a promise from an anonymous party that something will not happen.
2. You become a repeat target. Payment proves the domain is monetizable. Lists of victims who paid circulate, and follow-up demands from the same or different actors are a well-documented pattern.
3. You fund the next campaign. The money buys botnet capacity that gets pointed at the next recipient on the list.
4. You may create legal exposure. Payments to sanctioned entities carry real consequences in the EU, UK and US, and you cannot know who is behind the wallet. Public guidance from CISA and the UK NCSC is consistent: do not pay.

Note also how the demand is priced. It is set deliberately below what a day of downtime would plausibly cost you, so that paying looks like the rational choice on a spreadsheet. The number is a sales tactic, and it tells you nothing about the sender's actual capability.

The checklist to run before the deadline

The deadline is not a countdown to panic. It is a project plan with a due date, and every item on it has standalone value.

1. Put always-on filtering in front of your origin. This is the single highest-value action and the one with the shortest lead time. Edge mitigation that is already carrying your traffic has no activation window for an attacker to exploit — see what DDoS mitigation is for why always-on beats on-demand. Itnetic's DDoS protection goes live with two DNS record changes, typically inside five minutes, and the free Starter plan means budget approval is not on your critical path today.

2. Lock the origin down. Filtering at the edge is worthless if your server's real IP address still answers the internet directly — attackers check for exactly this. Firewall the origin to accept connections only from your mitigation network, and work through the leak checklist in how to hide your origin IP address. Do this in the same session as step 1; the two are one change, not two.

3. Cache aggressively. Every cache hit at the edge is a request your origin never sees. Raise TTLs on static assets, and cache HTML for anonymous visitors wherever your application allows it — this converts a large slice of any flood into traffic that never reaches you.

4. Rate-limit the expensive endpoints. Login, search, checkout, password reset, and any API path that runs a database query. These are what an application-layer flood aims at, precisely because a few thousand requests per second there is cheaper to send than it is to serve.

5. Confirm you can see what is happening. Turn on attack alerting and make sure you have per-request visibility before you need it — status, path, client fingerprint, verdict. Mid-incident is a bad time to discover your logs are sampled. That is what request logs and analytics are for.

6. Preserve evidence and prepare the humans. Keep the original email with full headers intact, screenshot any demo-attack traffic graphs, and note timestamps in UTC. Brief support on what to say, and decide in advance who makes the call to publish a status update. Do not reply to the sender, and do not negotiate — engagement is itself a signal that the address is live and the recipient is worried.

If the attack actually starts

Work the incident, not the email. The step-by-step sequence — confirming it is an attack rather than a traffic spike, identifying the targeted endpoint, tightening filtering, and communicating while it runs — is covered in how to stop a DDoS attack.

One addition specific to extortion cases: keep the ransom note out of the incident channel where responders are working. Deadlines create pressure to make bad decisions quickly, and the technical work does not change because a clock is running.

Report it

Reporting costs you almost nothing and is genuinely useful, because wallet addresses and note templates get correlated across victims — that is how bulk campaigns get identified as bulk campaigns. In the EU, report through your national police cybercrime unit or via Europol; in the Czech Republic, through the Police of the Czech Republic. Include the full email headers, the wallet address, and your traffic evidence.

Being the victim of a DDoS attack carries no liability of its own. Launching one is a criminal offence across the EU under Directive 2013/40/EU and in the US under the Computer Fraud and Abuse Act.

Where Itnetic fits

The uncomfortable truth about extortion emails is that they are a deadline problem, not a security problem. The defense you need is the one you should already have had — and if you do not have it, you have hours to get it.

That is the case Itnetic is built for. Protection is enabled by changing two DNS records, so there is no procurement cycle, no hardware and no agent to install; most customers are filtering traffic within five minutes. Mitigation runs always-on at every edge PoP rather than activating on a threshold, so there is no diversion window for an attacker to time an attack against. Real visitors pass without CAPTCHAs, every blocked request is logged for the post-incident write-up, and attack traffic is never metered against your bandwidth quota — being attacked should not produce an invoice. The Starter plan is free, which matters when the deadline is tomorrow and your budget approval is not.

If the email is a bluff, you have closed a real gap for nothing. If it is not, you have closed it in time.