What is Ransom DDoS (RDDoS) | How to Protect Your Infrastructure

Ransom DDoS (RDDoS) is an extortion campaign in which threat actors threaten to execute — or briefly demonstrate — distributed denial-of-service attacks against an organization, demanding payment (usually in cryptocurrency) to cease or not initiate the attack.

In some cases, RDDoS occurs as extortion focused exclusively on availability — without internal compromise, data access, or ransomware. In more complex campaigns, it may be combined with ransomware, data exfiltration, leak threats, and application abuse. Not every RDDoS involves internal compromise; not every ransomware involves DDoS; not every extortion with exfiltrated data involves ransomware.

What is Ransom DDoS (RDDoS)?

The typical cycle of a DDoS extortion campaign follows a recognizable pattern. In the reconnaissance phase, the threat actor identifies targets with high online availability dependency — e-commerce, financial services, gaming platforms, cryptocurrency exchanges — and gathers information about the target’s technical infrastructure.

In the demonstration phase (optional, but common), a brief DDoS attack is executed — illustratively, ranging from a few minutes to several tens of minutes — sufficient to cause perceptible degradation but not necessarily to completely bring down the service. The objective is to create urgency and indicate the threat has some operational substance.

In the demand phase, the actor sends communication — usually email — demanding cryptocurrency payment with a defined deadline. The message frequently attributes the campaign to known APT groups (such as Fancy Bear or Lazarus Group) to inflate the perception of sophistication — which, in isolation, is not evidence of genuine capability.

In the decision phase, the organization must respond in a coordinated way, without impulsiveness. The nature and extent of the response depend on the incident profile, jurisdiction, contracts, sector regulation, and risk assessment.

In the execution or abandonment phase, predominantly opportunistic groups may abandon if the target demonstrates active protection or ignores the demand. Groups with greater operational capability or motivation beyond financial gain may execute the attack regardless of payment.

How does a Ransom DDoS campaign work?

HTTP Flood and Layer 7 API abuse

Modern RDDoS attacks frequently operate at the application layer (L7) rather than the network layer (L3/L4), making them harder to detect by exclusively volumetric monitoring systems. Automated tools, headless browsers, and scripts are used to send syntactically valid HTTP requests that exhaust the application’s business logic without generating simple bandwidth anomalies.

An HTTP Flood directed at critical API endpoints — such as authentication, payment processing, or report generation — can impact a service with considerably lower traffic volume than a volumetric L3/L4 attack, because the computational cost per request is higher. Threat actors who understand the target’s internal API structure can concentrate the attack on especially costly endpoints, maximizing impact with minimal traffic volume.

QUIC Flood — vectors over UDP

The emergence of HTTP/3 over the QUIC protocol created an additional attack surface in RDDoS campaigns. QUIC uses UDP as encapsulation and integrates TLS 1.3. Security devices that do not terminate QUIC can apply L3/L4 controls and observe flow metadata, but generally cannot fully inspect HTTP/3 requests, headers, and application logic without TLS termination. Controls possible without termination include UDP filtering, rate limiting, IP/port policies, flow analysis, and behavioral detection.

On QUIC amplification: RFC 9000 defines address validation mechanisms, including the Retry packet. Before address validation, QUIC servers must apply an anti-amplification limit — as a general rule, not sending more than three times the bytes received before validating the client’s address. These controls reduce exposure to spoofing and reflection, but do not eliminate attacks from botnets with real IPs or pressure on CPU and user-space resources.

Low-and-slow attacks transported over QUIC may limit Layer 7 visibility for tools that do not terminate QUIC/TLS. Even so, network signals such as flow duration, packet rate, volume, connection behavior, and pressure on UDP/443 can still be monitored.

RDDoS and multiple extortion: when ransomware and exfiltration are involved

The terminology “double,” “triple,” and “quadruple extortion” varies across threat intelligence reports and is not uniformly standardized in the industry. The terms are used here to describe the progressive combination of pressures — not as a definitive or universal taxonomy.

Ransomware and unavailability as additional pressure

In some campaigns, the threat actor infiltrates the organization’s network, encrypts internal data, and demands ransom for the decryption key. DDoS may be added as parallel pressure: if the victim delays payment or attempts to recover data independently, the unavailability of external services increases the operational cost of resistance. These are two distinct threats with different access vectors — the presence of one does not automatically imply the other.

Data exfiltration and leak threats

In other campaigns, before encrypting or destroying data, the actor exfiltrates it. The demand includes a threat to publish data on criminal forums or sell it to third parties. For organizations subject to GDPR or other privacy regulations, this substantially raises the potential regulatory impact — but the specific obligations depend on the circumstances of the incident, as detailed in the governance section.

Pressure on customers, partners, and third parties

In broader campaigns, the actor may directly contact the organization’s customers, partners, suppliers, or shareholders, informing them about the incident and creating external reputational and regulatory pressure. DDoS-for-hire services (booters or stressers) can reduce the barrier to entry for opportunistic extortionists — these services may abuse botnets, compromised devices, exposed servers, or improperly used infrastructure. The use of a third-party service does not prove authorship or the group’s own technical capability.

Technical vectors used in RDDoS campaigns

The most frequent vectors in DDoS extortion campaigns include:

• Volumetric L3/L4: UDP, ICMP, SYN floods, and DNS amplification — exhaust network capacity or packet processing.
• HTTP Flood L7: valid requests that exhaust CPU, database, or business logic.
• API abuse: exploitation of costly endpoints, authentication, webhooks, or integrations.
• QUIC Flood: floods over UDP/443, pressure on CPU and user-space state.
• Low and Slow: low-rate attacks that keep connections open or exhaust workers.
• SYN Flood: exhaustion of TCP connection queues.

Sophisticated campaigns frequently combine multiple vectors to complicate selective mitigation.

How to evaluate the credibility of an RDDoS threat

Evaluating the credibility of a threat requires evidence-based analysis — not reliance on claims. The presence of an isolated signal does not prove genuine capability nor confirm a bluff; it must be interpreted in conjunction with all other available information.

Attribution of an RDDoS to a specific group is uncertain even for specialized teams. A demonstration attack may be executed with DDoS-for-hire services. APT impersonation is a common tactic of opportunistic extortionists.

Mitigation architectures: scrubbing, always-on, and edge

The choice of protection architecture has a direct impact on response capacity during an RDDoS, especially given the element of surprise inherent in extortion campaigns.

On-demand scrubbing

In the on-demand scrubbing model, traffic is diverted to a cleaning center after attack detection. The time between detection, activation, and the start of effective mitigation depends on automation, BGP route propagation, topology, providers, and pre-provisioning — and can vary from seconds to longer periods. During that interval, the attack may cause unavailability.

Some scrubbing centers operate predominantly at L3/L4. Others include reverse proxy, WAF, API protection, and L7 controls. Coverage must be validated per protocol, flow, product, and specific architecture.

Always-on scrubbing

In the always-on scrubbing model, traffic may already pass through the mitigation network or have pre-provisioned routes and tunnels, reducing convergence time. Detection and the start of mitigation tend to be faster, but performance depends on configuration, automation, and the nature of the attack.

Distributed edge protection

In the distributed edge model, traffic can be inspected and filtered at edge data centers before reaching the origin server. A distributed always-on architecture can reduce reaction time and apply controls before traffic reaches the origin. Its performance depends on geographic coverage, capacity, configuration, mitigation policies, the nature of the attack, and application integration.

Hybrid models

Organizations with high maturity levels frequently combine elements of the above models, adapting the architecture to the risk profile and impact tolerance. The organization should test its mitigation process in controlled exercises to understand real behavior under attack.

For more details on the differences between centralized scrubbing and its alternatives, see the specific article on mitigation architectures.

Governance, payment, and legal risk

Why authorities discourage payment

Security authorities frequently discourage payments because:

• they do not guarantee the attack stops;
• they may encourage new extortion demands, including from other groups;
• they may generate legal, financial, and reputational risks;
• they confirm to the actor that the organization is receptive to yielding.

The decision on communication, negotiation, or payment requires formal evaluation with executive leadership, legal, privacy, incident response, cyber insurance — where applicable — and competent authorities. Organizations must not respond impulsively to the attacker or make decisions without coordination.

Legal and regulatory risks

Exposure under sanctions regimes: for organizations with exposure to the United States, transactions involving sanctioned persons, entities, or wallets may generate significant risks under regimes administered by OFAC (Office of Foreign Assets Control). Evaluating this risk requires specialized legal advice considering the jurisdiction, contracts, and characteristics of the incident.

GDPR: the EU General Data Protection Regulation requires notification to the relevant supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of a personal data breach. An isolated DDoS attack does not in itself imply a personal data breach. If there is evidence of unauthorized access, exfiltration, or other applicable impact on personal data, legal and privacy teams must be engaged immediately.

Other jurisdictions: regulatory obligations vary by jurisdiction and sector. The organization’s legal team and privacy counsel must be engaged to assess applicable obligations.

Initial incident response playbook for RDDoS

The timeline below is an initial prioritization model. Activities may occur in parallel and must be adapted to the impact, jurisdiction, contracts, regulated sector, operational maturity, and nature of the incident.

Immediate priorities (T+0)

• Preserve all evidence before any other action.
• Verify whether an attack is underway: analyze logs, alerts, user reports, and network dashboards.
• Confirm coverage and status of active DDoS protection.
• Engage SOC, NOC, SRE, network, and product teams according to the scope of impact.
• Check for indicators of intrusion and possible exfiltration — a DDoS attack may be a distraction vector.
• Elevate monitoring and telemetry on critical services.
• Document all decisions and the incident timeline.

Immediate technical containment

• Activate or escalate DDoS protection with the provider or mitigation service.
• Apply rate limiting, geoblocking, or WAF rules where applicable and pre-tested.
• Protect critical endpoints and services that may be targets of parallel abuse.
• Verify connectivity status with upstreams and transit providers.

Governance and legal

• Engage executive leadership for alignment and authorization of decisions.
• Engage legal, privacy, and compliance as early as possible.
• Assess cyber insurance coverage where applicable.
• Evaluate regulatory and contractual obligations specific to the sector and jurisdiction.
• Assess international exposure and sanctions risks as applicable.
• Define responsibilities for internal communication, communication with customers and partners, and communication with authorities.

Communication with the attacker

• Do not respond impulsively to the threat actor.
• Do not negotiate or authorize payment without formal coordination with legal and leadership.
• Preserve the original message and its metadata unchanged.
• Follow legal counsel and competent authority guidance before any action.

Evidence and forensic analysis

Demand email: headers and metadata can assist investigation of campaigns and infrastructure. Elements to preserve and analyze include: Received chain, message identifiers, timestamps, domains, potentially compromised accounts, intermediary services, attachments, links, and mentioned wallet addresses. Headers must not be interpreted in isolation as definitive proof of the attacker’s real origin, but are evidence that authorities can use in the investigation.

Cryptocurrency addresses: must be preserved as evidence and shared with authorities, legal, and authorized specialists. Public tools and commercial blockchain analytics platforms can help correlate indicators, but attribution requires caution and multiple sources of evidence.

Traffic capture: if possible and without operational impact, preserve samples of the attack traffic for subsequent analysis.

Authority reporting

Reporting channels depend on jurisdiction, sector, and impact. Depending on the circumstances, it may be appropriate to evaluate reporting to:

• US: FBI IC3 — accepts reports from international companies with US impact.
• EU: Europol EC3 (Cybercrime Centre) for European organizations.
• UK: NCSC (National Cyber Security Centre).
• Sector regulators — in sectors such as financial, health, and energy, where applicable.
• Affected contractual partners — as required by contract.

Post-incident communication

Premature public communication during the crisis can amplify the reputational impact and signal to the actor that the pressure is working. After resolution, post-incident transparency with customers and partners is generally valued and may be mandatory depending on the sector and applicable regulation.

Most targeted sectors

RDDoS and multiple extortion: comparison

Common mistakes and guidance

Keeping the demand secret to avoid public exposure: reporting to authorities is operationally useful and may be legally mandatory in regulated sectors. Confidentiality of reporting is generally preserved during active investigation.

Negotiating with the threat actor without coordination: any direct communication must be preceded by legal guidance and leadership alignment. Negotiating without coordination may confirm to the actor that the organization is considering yielding and increase pressure.

Activating DDoS protection only after receiving the demand: the interval between the demand and the attack may be short — insufficient to implement, test, and validate protection from scratch. Proactive protection must be in place before incidents occur.

Assuming APT impersonation indicates equivalent capability: most RDDoS groups are opportunists who attribute campaigns to APTs to inflate credibility. Evaluate the threat by observed technical evidence, not by the name in the message.

Paying without legal and risk assessment: the decision to pay or not must be made with specialized legal counsel, evaluating criminal, regulatory, compliance, and sanctions risks, as well as the operational and reputational impact of both options.

Frequently asked questions

Is RDDoS different from ransomware extortion? Yes, in the primary vector. Ransomware requires internal infiltration and encrypts data — the damage is internal and direct. RDDoS, in its isolated form, threatens availability through an external network attack, without necessarily accessing internal systems. In multiple extortion campaigns, the two may be combined — but the presence of one does not automatically imply the other.

Is every DDoS attack during an extortion an RDDoS? Not necessarily. The defining characteristic of RDDoS is the explicit payment demand as a condition for ceasing or not initiating the attack. A DDoS attack without a demand may have ideological, competitive, or other motivations — and must be investigated independently.

What are the specific regulatory risks under GDPR? An isolated DDoS attack does not in itself imply a personal data breach or automatic notification obligation. If the incident involved unauthorized access, exfiltration, or unavailability of systems handling personal data, the organization must immediately engage legal and privacy counsel to assess applicable obligations. Under the GDPR, notification to the supervisory authority must occur without undue delay and, where feasible, within 72 hours of becoming aware of the breach.

How do email headers help in the investigation? Email headers and metadata can assist investigation of campaigns and infrastructure — including the Received chain, timestamps, domains, message identifiers, and intermediary services. They must not be interpreted in isolation as definitive proof of the threat actor’s real origin, but are evidence that authorities can use in the investigation.

Do RDDoS groups generally attack even without receiving payment? It depends on the operational profile. Groups with a predominantly opportunistic profile may abandon when faced with active protection or no response. Groups with greater operational capability, ideological motivation, or integration with other campaigns may execute the attack regardless of payment. Prior technical preparation is the variable with the greatest impact on resilience, regardless of group type.

How does QUIC Flood affect RDDoS campaigns? QUIC Flood represents a vector that can reduce Layer 7 visibility for devices that do not terminate QUIC/TLS. In campaigns with demonstration attacks, the use of QUIC may be employed to assess the target’s defensive coverage. Monitoring of flow metadata, pressure on UDP/443, CPU, and connection duration can assist detection even without content inspection.

Official references and guidance

• CISA StopRansomware — guides and alerts on cyber extortion
• OFAC Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments — guidance on sanctions risks
• FBI IC3 — Internet Crime Complaint Center
• Europol EC3 — European Cybercrime Centre
• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9001 — Using TLS to Secure QUIC

How to implement on Azion

Azion’s distributed architecture can help apply mitigation controls at the edge, reducing the origin’s exposure to malicious traffic. The effective coverage and behavior depend on the contracted products, published protocols, configured policies, and application architecture.

1. DDoS Protection integrated into the edge: Azion’s DDoS protection operates in the edge infrastructure and can help mitigate volumetric and application attacks, including HTTP Flood on APIs, QUIC Flood, and low and slow attacks, as per the products and configurations used.
2. QUIC and HTTP/3 termination at the edge: when QUIC and HTTP/3 traffic is terminated at the edge, Layer 7 controls can be applied after TLS termination, including security policies, rate limiting, and API protection, according to the environment configuration.
3. Observability and incident response: logs, metrics, and observability resources can support incident investigation and adjustment of mitigation policies, according to the products and configurations used.
4. Network Shield and L3/L4 filtering: filters malformed packets, anomalous patterns, and volumetric vectors at Layers 3 and 4, reducing exposure before any application processing.

Learn more in the Azion DDoS Protection documentation.