Double Extortion: When Locking Your Files Is Only Half the Threat

The 30-second explanation

The attacker locks your files, but takes a copy first. Even if you restore everything perfectly from backups by the next morning, they can still hold the threat of publishing what they stole over you. Getting your files back doesn't undo a theft that already happened days earlier.

How it works

1. 1

   1. Access

   Attackers gain a foothold, often via a stolen credential or phishing, and spend time moving laterally while avoiding detection.

2. 2

   2. Steal

   Valuable files are identified, compressed into archives, and uploaded to an attacker-controlled cloud storage service or dedicated leak-site infrastructure.

3. 3

   3. Encrypt

   Once the theft is complete, ransomware is deployed broadly and quickly, often after backup snapshots and shadow copies are deleted first.

4. 4

   4. Threaten

   A ransom note directs the victim to a negotiation portal, demanding separate payment to decrypt files and to prevent publication of the stolen data.

Before encrypting anything, the attackers spend time inside the network specifically looking for data worth stealing: financial records, customer information, internal communications. They copy it out to infrastructure they control. Only once that's done do they encrypt, usually as a final, fast step across as many systems as possible. The ransom note that follows carries two separate demands instead of one: pay to receive a decryption key, and pay again to stop the stolen data from being published. That changes the calculation for whoever is deciding how to respond. Strong, tested backups fully solve the availability problem, since files can be restored, but they do nothing for the confidentiality problem, because the data has already left regardless of what happens next. Paying doesn't reliably fix that either. There's no way to confirm a copy handed to a criminal group was actually destroyed rather than quietly kept or resold, so the exposure can outlast the payment. Catching the intrusion during the quiet reconnaissance-and-theft stage, before either demand becomes possible to make, is the defence that actually works here.

Real-world example

How to spot it

• Large outbound transfers to unfamiliar destinations

  Sustained or bursty upload traffic to a cloud storage or file-sharing domain the organisation doesn't normally use, especially overnight.

• Archive and compression tools on servers

  Compression utilities running on file servers or database hosts where they have no normal business reason to be.

• Cloud sync or transfer tools appearing on servers

  Installation of consumer file-sync clients on systems that should only run approved enterprise software.

• Unusual access in the days before encryption

  A pattern of file-share browsing and access to sensitive directories in the days leading up to an encryption event, visible only in retrospect unless it's caught live.

What to do

1. 1Monitor for unusual outbound data volume and destinations, not just for encryption activity, so the theft stage can be caught while it's still happening.
2. 2Keep offline or immutable backups for recovery, but build an incident response plan that also covers the data-leak scenario, since backups alone don't address it.
3. 3Prepare legal, communications and customer-notification steps in advance of an incident, so decisions aren't made for the first time under a countdown.