Exfiltration-only ransomware — the data-extortion response playbook

This playbook fires when your organization faces a ransom or extortion demand backed by stolen data, with no file encryption — or where encryption, if present, is incidental and recovery is not the question. The hallmark is a note or portal message that threatens to publish, sell, or notify your customers and regulators unless you pay, often with a sample of exfiltrated files as proof and a countdown on a leak site.

In scope: the detection, scoping, notification and extortion-decision workflow for a data-theft extortion event. Out of scope: classic encrypting ransomware where restoring service is the priority — for the pay-or-rebuild decision mechanics see the ransomware negotiation decision playbook, and for an agent-driven chain see agentic AI ransomware containment. The news-side background on the 2026 shift is in the exfiltration-only ransomware explainer.

Why this is now the default model: groups such as Hunters International shut down their encryptor and relaunched as the extortion-only operation World Leaks, using a custom exfiltration tool rather than a locker, and the wider market has shifted from encryption to pure extortion as payment rates collapsed.

There is no decryption key to wait for, so the deadlines are external. Track two clocks from the moment you become aware:

• The leak-site clock. The attacker sets a publication countdown, usually days, after which samples escalate to a full dump. This clock is adversary-controlled and can be moved — do not treat it as fixed.
• The statutory clocks. If personal data left, GDPR Article 33 gives 72 hours to notify the supervisory authority from awareness. NIS2 Article 23 (24h early warning / 72h / 1-month) and, for financial entities, DORA major-incident reporting may fire on the same facts. These are legal and do not move.

The trap is to spend the first day on containment and treat notification as a later step. In an exfiltration-only event the data is already gone on day zero, so the notification clock is often the most urgent constraint you have. Start the regulatory timeline in parallel with technical work, not after it.

Goal: establish whether data is still leaving and cut the channel, then preserve evidence.

• Confirm the exfiltration is real and bound its window: pull egress telemetry (firewall, proxy, NetFlow, DNS) for the suspected period and the prior 7-30 days — staging often predates the demand by weeks.
• Identify the egress channel (cloud-storage upload, attacker-controlled host, DNS tunneling, a legitimate SaaS used as a conduit) and block it without tipping a still-active actor before you have scoped access.
• Preserve before you remediate: snapshot affected hosts, export the relevant logs, and record timestamps — the shutdown itself can destroy the volatile evidence you will need for the filing.
• Rotate credentials and revoke sessions/tokens for any identity in the access path; data-theft actors frequently retain a second foothold.
• Open the internal timeline log and notify the DPO and legal lead in parallel with the SOC — their clocks are already running.

Checklist: egress window bounded; channel identified and blocked; forensic snapshots taken; credentials/tokens rotated; timeline log open; DPO and counsel engaged.

Goal: turn ‘they claim they took data’ into a defensible inventory of what actually left, because both your notification duty and your extortion exposure turn on the specifics.

• Reconstruct the exfiltrated set from egress volume, accessed file shares and databases, and the attacker’s own proof samples. Match claimed samples against real records — bluffing and padding are common.
• Classify the data: personal data (triggering GDPR), special-category or health data, regulated financial records, trade secrets, third-party data you process for others (which shifts notification duty up the chain — see third-party SaaS breach notification).
• Map each data category to its notification regime and deadline before the 72-hour GDPR gate expires. Under-scoping to avoid notifying is the failure that turns an incident into a regulatory penalty.
• Decide the customer and partner communication position now, not after the leak forces it.

Checklist: exfiltrated inventory reconstructed; attacker samples verified against real data; data categories classified; per-regime notification map built; comms position drafted.

Goal: make the payment decision on evidence, then close the loop. In exfiltration-only cases payment does not restore anything — it buys a promise to delete data you cannot verify was deleted, and attackers routinely re-extort or sell anyway.

• Screen for sanctions exposure first. A payment to a sanctioned entity carries strict-liability sanctions risk; this applies to data-extortion payments, not only to decryption payments. Do not pay without OFAC or relevant-regime screening and counsel sign-off.
• Weigh the honest base rate. Coveware’s Q3 2026 data shows nearly 80% of incidents now resolve without a ransom payment, and the data-theft-only payment rate fell to a record-low 15% — paying is now the exception, not the default.
• Assume publication regardless. Build the plan that assumes the data becomes public: notified individuals, credential resets, fraud monitoring, legal holds. A deletion promise is not a control.
• Close with a final report: verified scope, notifications filed and when, remediation status, and the detection-gap root cause (how the staging and egress went unseen).

Checklist: sanctions screening done; decision recorded with rationale and approver; assume-publication plan executed; notifications filed; final report with detection-gap analysis.

Across detection, scoping and any filing, have ready (signed, timestamped, with chain-of-custody):

• Egress telemetry export covering the incident window plus 7-30 days of baseline.
• The channel-identification analysis (how and where data left).
• The reconstructed exfiltration inventory, with the attacker samples matched to real records.
• Data-classification mapping to each notification regime.
• Containment and credential-rotation logs with timestamps.
• Sanctions-screening record and the payment-decision memo.
• Notifications filed, per regime, with timestamps.

The hard part of an exfiltration-only case is proving what left and when — and most teams cannot, because nothing on the wire was being watched behaviorally. This is the gap an on-premise AI traffic-analysis layer is built to close: a deep-learning model with four parallel inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting) running on the appliance GPU at multi-gigabit line rate, flagging the staging and the anomalous egress — never-seen destination ASNs, sustained outbound volume from a host that only ingests, DNS-over-HTTPS bursts — while it is happening, not in the next morning’s SIEM digest. Because it runs on-premise on private models, the traffic and the evidence never leave the estate. The offensive side closes the loop: an autonomous AI red team that rehearses the exfiltration path in advance turns ‘could data leave unseen’ into a tested finding with a signed proof, instead of a question you first answer during the incident.

Patterns seen across peer organizations:

• Treating it as a recovery incident. Restoring from backup and declaring victory, while the attacker still holds the data and the notification clock runs unaddressed.
• Waiting for certainty before notifying. The GDPR 72-hour and NIS2 clocks run from awareness; a preliminary notification is expected, and under-disclosing to buy time is the costliest mistake.
• Trusting the deletion promise. Paying and closing the file, with no assume-publication plan — then facing a leak or re-extortion months later with no prepared response.
• Scoping from the attacker’s claims. Accepting the ransom note’s inventory instead of reconstructing what actually left; it leads to both over-notifying and missing categories.
• No egress visibility. Discovering the theft only from the ransom note, because nothing was watching outbound behavior — the single most common root cause, and the one that decides whether you had any chance to stop it.

A single data-theft event usually triggers more than one regime, each with its own clock and authority, off the same evidence base:

• GDPR Article 33 — 72 hours to the supervisory authority when personal data left; Article 34 adds notification to affected individuals when the risk is high (a public leak generally qualifies).
• NIS2 Article 23 — 24h early warning / 72h notification / 1-month final for essential and important entities.
• DORA major-incident reporting for financial entities, on its own deadlines.
• Processor chains — if the stolen data belongs to your customers, your duty to notify them up the chain fires too; see third-party SaaS breach notification.

In every case the underlying record is the same; the notifications are different summaries of one evidence base. Build it once and export per regime, rather than running parallel evidence trails under simultaneous clocks.