Ransom DDoS in iGaming: how sportsbooks
get hit and how to respond

Back to Blog

Why Sportsbooks Are the Top Target for Ransom DDoS

Ransom DDoS (RDDoS) campaigns are not random. Attackers select targets based on a simple economic calculation: how much pain can a short outage cause, and how quickly will the target pay to make it stop? Sportsbooks answer both questions in the attacker's favor.

Unlike most businesses, sportsbooks have revenue windows that are publicly known and precisely scheduled. The Champions League semifinal kicks off at 20:00 UTC. The Super Bowl starts at a time published months in advance. The Kentucky Derby, the Six Nations final, a Tyson Fury title fight. Every high-revenue window is on a public calendar, and attackers study that calendar just as carefully as operators do.

A sportsbook that goes offline for 10 minutes during a Premier League match loses far more than the revenue from those 10 minutes. In-play betting generates 70-80% of total handle for football matches. Players who cannot place bets during a live event do not come back later to make up for lost wagers. They open a competitor's app, deposit, and place their bets there. Some of them never come back.

This combination of predictable high-value windows, time-sensitive revenue, and low tolerance for downtime makes sportsbooks the single most profitable vertical for ransom DDoS operators. The attackers know the economics as well as the operators do, and they price their demands accordingly.

Anatomy of a Ransom DDoS Campaign

Ransom DDoS campaigns against sportsbooks follow a consistent pattern. Understanding each phase is essential for building a response plan that neutralizes the campaign before it causes damage.

Phase 1: Reconnaissance and Probing (Days to Weeks Before)

Before any ransom demand is sent, the attacker conducts reconnaissance. This phase is quiet and often goes undetected. The attacker identifies the target's IP ranges, maps the infrastructure (web frontend, API endpoints, payment gateway, odds engine), and runs small test floods to measure the target's capacity and response time.

These probes are typically short bursts, lasting 30 to 60 seconds, at volumes well below the target's saturation point. The attacker is not trying to cause disruption yet. They are measuring how quickly the target detects the traffic, whether any automated mitigation fires, and what the baseline traffic levels look like. This intelligence shapes the ransom demand and the demonstration attack that will follow.

What to look for: unexplained traffic spikes of 2-5x baseline lasting under a minute, especially from sources that do not match your normal geographic distribution. These are often UDP floods or SYN floods targeting a single IP. If your detection system flags these as minor anomalies and auto-resolves them, the attacker now knows your detection threshold and response capability.

Phase 2: The Ransom Note (24-48 Hours Before a Major Event)

The ransom email arrives with calculated timing. It is sent early enough that the operator has time to process the demand and arrange payment, but close enough to the event that there is no time to implement new defenses. Common delivery windows are 24-48 hours before a major sporting event.

The email typically claims affiliation with a known threat group (Fancy Bear, Lazarus Group, or Armada Collective are common claims, almost always false). It specifies a Bitcoin wallet address, a payment amount (typically 5-20 BTC for mid-size operators, higher for large brands), and a deadline. The email states that a "demonstration attack" will follow to prove their capability.

The language is formulaic. Multiple operators often receive nearly identical emails, sometimes on the same day, because these campaigns target dozens of sportsbooks simultaneously. The attacker does not need every target to pay. If 10% of targets pay, the campaign is profitable.

Phase 3: The Demonstration Attack (Hours After the Ransom Note)

This is the critical phase where the attacker proves they can deliver on their threat. The demonstration attack is designed to be painful enough to validate the ransom demand but short enough that it does not exhaust the attacker's resources before the real campaign begins.

Demonstration attacks typically last 10-30 minutes and hit at 50-70% of the volume the attacker can sustain. The purpose is not to take the target offline permanently. It is to show the operator that the attacker can cause real disruption, creating urgency around the payment deadline.

The demonstration attack is the pivot point of the entire campaign. If it fails, meaning the target's infrastructure absorbs or mitigates the attack with no visible impact, the ransom loses all leverage. The attacker cannot credibly threaten an operator whose platform stayed online during the demonstration. This is why sub-second detection and auto-mitigation fundamentally change the economics of ransom DDoS.

Phase 4: The Sustained Campaign (If Payment Is Not Received)

If the operator does not pay by the deadline, the attacker escalates. The sustained campaign targets the operator during their highest-revenue windows: live events, peak betting hours, major tournament weekends. Attacks rotate vectors every few minutes (UDP flood, SYN flood, HTTP flood, DNS amplification) to complicate manual mitigation efforts.

Sustained campaigns can last days to weeks. The attacker may send follow-up ransom notes with increased demands. Some campaigns include secondary targets: if the operator uses a specific payment processor or odds feed provider, the attacker may hit those services to cause collateral disruption even if the operator's own infrastructure is defended.

Why Paying the Ransom Never Works

The data on ransom payments is unambiguous: paying does not make the problem go away. Multiple factors ensure that payment leads to repeated victimization rather than lasting relief.

Target lists are shared and sold. Once an operator pays a ransom, their name is added to a list of confirmed payers. This list circulates among threat actors. Paying one group guarantees that other groups will target the same operator, often within weeks. The operator has demonstrated both vulnerability and willingness to pay, which are the two criteria attackers use to prioritize targets.

The same group comes back. Attackers who receive payment know that the operator's defenses have not improved (if they had improved, the demonstration attack would have failed and there would have been no reason to pay). The same group returns with a higher demand before the next major event. Each payment trains the attacker to expect more from the same target.

Payment does not guarantee relief. There is no contract, no SLA, and no customer support line for ransom DDoS. Some attackers take payment and attack anyway, either because they are testing the operator's resolve for future demands or because the attack infrastructure is already spun up and the marginal cost of continuing is near zero.

Regulatory exposure. In some jurisdictions, making ransom payments may create legal liability. Regulators and law enforcement agencies increasingly view ransom payments as funding criminal enterprises. For licensed operators, an undisclosed ransom payment that later surfaces during an audit creates a far worse regulatory problem than the original attack.

The only strategy that permanently eliminates ransom DDoS leverage is making the demonstration attack fail. When the attacker cannot cause visible disruption, the ransom demand carries no weight, and the operator is removed from the profitable-target list.

Technical Breakdown: Multi-Vector Attack Patterns

Ransom DDoS campaigns against sportsbooks rarely use a single attack vector. Modern campaigns combine multiple vectors simultaneously to overwhelm defenders who are trained to identify and filter one type of malicious traffic at a time.

The Three-Vector Simultaneous Attack

The most common pattern combines three vectors running in parallel:

• UDP flood (volumetric layer): High-bandwidth traffic aimed at saturating the target's upstream link. Typically 5-15 Gbps for mid-size operators, sourced from amplification reflectors (DNS, NTP, memcached, or CLDAP). The goal is bandwidth exhaustion, not application-layer damage.
• SYN flood (protocol layer): High packet-rate traffic targeting the TCP state tables on the target's servers and load balancers. Even if the volumetric component is filtered upstream, a SYN flood at 500K+ packets per second can exhaust connection tracking tables and crash firewalls that are not tuned for stateless filtering.
• HTTP flood (application layer): Legitimate-looking HTTP requests targeting expensive API endpoints (bet placement, account balance lookups, odds feed queries). Each request consumes backend resources: database queries, session validation, odds calculation. A few thousand requests per second against an unprotected API endpoint can exhaust application-layer capacity even when the network layer is clean.

The simultaneous nature of the attack is deliberate. When the operator's team identifies and mitigates the UDP flood, the SYN flood is still running. When they address the SYN flood, the HTTP flood has already degraded application performance. By the time all three vectors are mitigated manually, the event window has passed.

Vector Rotation

Sophisticated campaigns rotate vectors on a timer. The attacker runs a UDP flood for 5 minutes, then switches to a DNS amplification flood, then to an NTP amplification flood, then to a SYN flood. Each rotation forces the defender to re-identify the attack vector and adjust filtering rules. Manual response cannot keep up with rotation intervals under 10 minutes.

Carpet Bombing

Instead of targeting a single IP, the attacker distributes traffic across the operator's entire IP range. Each individual IP receives traffic below the per-IP detection threshold, but the aggregate volume saturates the upstream link. This pattern defeats detection systems that only monitor individual IPs without aggregating traffic across the subnet.

How Detection Speed Changes the Economics

The entire ransom DDoS model depends on one assumption: the demonstration attack will cause visible disruption. If that assumption is wrong, the entire campaign collapses.

Consider the timeline. The attacker sends a ransom note claiming they will take your platform offline. Hours later, the demonstration attack begins. If your detection system identifies the attack within the first second and auto-mitigation fires within the same second, the following happens:

• The attack traffic is dropped at the kernel level before it reaches the application layer
• FlowSpec rules propagate to upstream routers within seconds, filtering attack traffic at the network edge
• Your platform shows zero degradation throughout the entire demonstration attack
• The operator's team receives a Slack alert, reviews the auto-generated incident report, and moves on

From the attacker's perspective, the demonstration failed. They spent resources (botnet time, amplification reflectors, operational coordination) and achieved nothing. The ransom demand is now an empty threat. The operator has demonstrated, through the automated response to the demonstration attack, that the attacker cannot cause the disruption they are threatening.

This fundamentally changes the economics. The attacker's cost per campaign stays the same, but the expected revenue drops to near zero for defended targets. Rational attackers reallocate their resources to undefended targets. Over time, the operator is deprioritized on target lists because they are known to be unprofitable to attack.

The threshold for this outcome is sub-second detection. At 30 seconds of detection latency, the demonstration attack causes a brief but visible service degradation, which may be enough to make the ransom credible. At 5 minutes of detection latency, the demonstration attack has already caused significant disruption, and the ransom demand carries real weight. Only sub-second detection makes the demonstration attack invisible to end users.

Incident Response Playbook for Ransom DDoS

This playbook covers each phase of a ransom DDoS campaign with specific actions for operations, security, and compliance teams.

When You Receive a Ransom Email

1. Do not respond to the email. Any response confirms the email reached a valid recipient and was read by a human. Silence is the correct response.
2. Preserve the email as evidence. Forward the full email with headers to your security team. Save the raw email source (including headers) to your incident tracking system. The email headers, Bitcoin wallet address, and sending IP will be needed for law enforcement reporting.
3. Notify your incident response team. Activate your pre-defined escalation chain. The team should be aware that a demonstration attack is likely within 24 hours.
4. Verify your detection and mitigation systems are active. Confirm that all agents are reporting, auto-mitigation policies are enabled, and alert channels are functioning. This is not the time to discover that a Slack webhook expired or a FlowSpec session dropped.
5. Brief your compliance officer. Licensed operators should notify the designated compliance officer that a ransom demand has been received. This starts the documentation trail that regulators expect.
6. Contact law enforcement. File a report with the relevant authority (FBI IC3 in the US, Action Fraud in the UK, Europol's EC3 for EU-based operators). Do this immediately, not after the attack. Law enforcement values early notification.
7. Do not pay. For all the reasons outlined above, payment is the worst possible response.

During the Demonstration Attack

1. Monitor, do not interfere. If your automated mitigation is handling the attack, let it work. Manual intervention during an automated response introduces risk of misconfiguration.
2. Document the attack in real time. Note the start time, vectors observed, volume metrics, and mitigation actions taken (automated or manual). Your detection system should capture most of this automatically.
3. Verify all services are operational. Check your betting API, payment gateway, odds engine, and user-facing frontend. Confirm that the attack is being mitigated without service impact.
4. Communicate with stakeholders. If the attack causes zero service impact, a brief internal notification that a ransom-related attack was detected and automatically mitigated is sufficient. If there is any service degradation, activate your incident communication plan.

After the Demonstration Attack Ends

1. Review the incident report. Analyze the attack vectors, volumes, and mitigation effectiveness. Identify any gaps in coverage.
2. Prepare for escalation. The attacker's deadline will pass, and they may escalate. Ensure your team is staffed and alert channels are active for the next 72 hours.
3. Update your threat intelligence. Feed the attack source IPs, traffic patterns, and attacker fingerprints into your threat intelligence platform. Share indicators of compromise with your ISP and any industry information-sharing groups you belong to.
4. Brief your regulator if required. Some licensing jurisdictions require notification within a specific timeframe after a security incident, even if service was not disrupted. Check your license conditions and comply.

During a Sustained Campaign

1. Maintain automated response. Do not switch to manual mitigation unless the automated system is failing. Manual response is slower and more error-prone.
2. Monitor for vector rotation. If the attacker rotates vectors, ensure your system is classifying and mitigating each new vector as it appears.
3. Watch for secondary targets. Monitor your payment processors, odds feed providers, and any third-party services in your stack for signs of collateral targeting.
4. Maintain law enforcement communication. Update your filed report with new attack data. Law enforcement aggregates reports across multiple victims to build cases against threat actors.
5. Document everything for regulatory compliance. Every incident, every mitigation action, every communication. This documentation protects the operator in regulatory reviews.

Regulatory Implications for Licensed Operators

Ransom DDoS campaigns create regulatory obligations that go beyond the technical response. Licensed operators in regulated markets must navigate incident reporting requirements, demonstrate adequate security measures, and maintain audit-ready documentation.

Licensing body expectations. Regulators like the Malta Gaming Authority (MGA), UK Gambling Commission (UKGC), and Curacao eGaming Board require licensed operators to maintain adequate security controls and report significant incidents. A ransom DDoS attack, even one that was fully mitigated, typically meets the threshold for incident reporting because it demonstrates that the operator was targeted by a threat actor.

Incident reporting timelines. Reporting windows vary by jurisdiction. The UKGC expects notification of key events that could affect the operator's ability to conduct licensed activities. The MGA requires reporting within specified timeframes outlined in the license conditions. Failing to report a known security incident is often treated more seriously than the incident itself.

Evidence preservation. Regulators expect operators to preserve evidence of security incidents for audit purposes. This includes attack traffic captures (PCAPs), incident timelines, mitigation actions taken, and any communications received from threat actors (ransom emails). Automated incident reports that capture this data in real time are far more credible than reports compiled from memory days or weeks after the event.

Demonstrating adequate measures. The regulatory question is not whether you were attacked (that is outside your control) but whether you had reasonable measures in place to detect, mitigate, and recover. Automated detection and mitigation systems, documented incident response procedures, and regular testing provide the evidence regulators need to see.

How Flowtriq Handles Each Phase Automatically

Flowtriq's architecture is designed to neutralize ransom DDoS campaigns at every phase, from initial probing through sustained attacks.

During reconnaissance probes: The FTAgent detects short burst floods the moment they cross dynamic thresholds, even at low volumes. Every probe is logged with full traffic metadata, building a historical record of attacker behavior before the ransom note ever arrives. If auto-mitigation is enabled, probe traffic is dropped at the kernel level and the attacker's reconnaissance yields limited useful data about the target's actual capacity.

When the demonstration attack hits: Detection fires within the first second. The 4-level escalation chain activates automatically: kernel-level firewall rules drop attack traffic instantly, FlowSpec filters at the network edge within seconds, and RTBH or cloud scrubbing engages if the volume exceeds local capacity. The demonstration attack fails with zero service impact, removing all leverage from the ransom demand.

During sustained campaigns: Auto-mitigation handles vector rotation without human intervention. Each new attack vector is classified independently and mitigated at the appropriate layer. Rules are applied when attacks begin and withdrawn when they end, maintaining clean traffic flow without stale rules degrading performance. The operations team receives alerts but does not need to take manual action.

For regulatory compliance: Every incident generates an automated postmortem report with timestamps, attack classification, confidence scores, mitigation actions taken, traffic graphs, and downloadable PCAP evidence. These reports satisfy audit requirements for MGA, UKGC, and other licensing bodies. Export as PDF for compliance submissions or access via API for integration with your documentation workflow.

Back to Blog

Related Articles