Double extortion: why you should test exfiltration before encryption

Double extortion is a form of ransomware attack in which the attacker steals data before encrypting the information system, then threatens to publish it if the ransom is not paid. The encryption halts the business; the threat of disclosure puts pressure on reputation, customers and compliance. Healthy backups let you restart, but they do not bring the stolen data back: the stage to test first is therefore exfiltration.

Why double extortion changes the question put to the CISO

For years, the answer to ransomware came down to one word: backup. Offline, tested, immutable copies, and the company could refuse to pay. That reasoning still holds for availability. It says nothing about confidentiality.

With double extortion, the attacker has two levers. The first, encryption, is dealt with by restoration. The second, copying data out of your perimeter, is dealt with by nothing other than prevention. Once the files are out, no restoration brings them back. You are then managing a data leak, with its notification obligations, its exchanges with the people concerned and its commercial consequences.

The useful question is therefore no longer “can we restore?” but “could an attacker established in our network move significant volumes of data out without being blocked or detected?”. That is a question of evidence, not of configuration.

What backups cover, and what they do not

Scroll the table →

The table sums up a point that is often misunderstood at board level: a well-spent backup budget leaves half the risk untouched. The other half depends on the controls that govern data leaving the network.

Exfiltration, the stage where the attack is most visible

In a double extortion attack, exfiltration generally takes place before encryption. The attacker has to move large volumes, often over several hours or several days. This is a moment of exposure: unusual outbound traffic, connections to external storage services, legitimate synchronisation tools turned to other ends.

The MITRE ATT&CK framework groups these behaviours under the Exfiltration tactic, which we detail in our article on the TA0010 tactic explained for defenders. For a defender, the value is simple: each technique described corresponds to a channel that can be monitored and tested.

In practice, the channels to question are well known:

• encrypted web traffic to storage or sharing services, where TLS inspection often leaves exceptions (see the blind spots of TLS inspection);
• infrastructure protocols allowed by default, such as DNS;
• personal cloud accounts and collaboration tools;
• direct connections from servers that should never talk to the Internet.

If one of these paths lets sensitive data through without an alert, you have found the place where a double extortion attack would succeed in your organisation.

A concrete scenario, seen from the defender’s side

Take a mid-sized industrial company (ETI). Backups are exemplary, restored every quarter. A DLP is deployed on workstations and email. The firewall filters risky web categories.

One Thursday evening, an attacker who has gained access through a contractor account starts gathering the engineering department’s directories on a file server. He compresses the archives and sends them to a consumer storage service, from that server, over HTTPS. The endpoint DLP is not installed on servers. The service’s category is allowed, because a business application uses it. The SOC receives a volume alert, but the rule is classed as low severity and handled on Monday.

How to test the exfiltration stage without exposing any real data

Testing what an attacker would do does not mean moving your real data. Good practice is to work with decoys: synthetic files that look like your sensitive data (formats, classification markers, patterns the DLP can detect) without containing any of it. The subject is developed in our article on synthetic data in production.

The preparation steps

1. Choose the data that matters. The data whose publication would do the most damage: customer personal data, drawings, contracts, HR data.
2. Map the starting points. User workstations, but also file servers, databases, cloud and application environments, wherever an attacker would gather the data.
3. List the egress channels. Web, DNS, email, cloud storage, collaboration tools.
4. Define the expected result for each scenario. Blocked, detected, or both, and within what timeframe.
5. Inform the right people. The SOC must be able to handle the alerts without triggering a crisis, but not be so well informed that it skews the detection measurement.

What you should have at the end

• for each attack scenario, a clear status: blocked, detected, or passed unnoticed;
• the delay between the synthetic data leaving and the alert reaching the SOC;
• a list of corrective actions ranked by impact, not a report of several dozen pages.

Prioritisation matters as much as the finding. Fixing a proxy exception that opens a channel to every server is worth more than ten rule adjustments on workstations. Our article on prioritising DLP remediation details the method.

Why a one-off test is not enough

An annual test gives you a snapshot. Yet your posture changes every week: a new filtering exception for a project, an application migrated to the cloud, an agent update, a new contractor. Each change can reopen a path that was closed.

Groups practising double extortion do not test your network once a year. They look for the weakness of the moment. Replaying the scenarios continuously lets you see when a control regresses, and fix it before it is used against you.

Frequently asked questions