Can files encrypted by ransomware be recovered?

Recoverability does not depend on willingness to pay or on how many people work the problem. It depends on a few objective conditions, and an assessment checks each of them:

• Which family, which version? Only a small number of families can be decrypted - because keys leaked, law enforcement seized them, or the implementation was flawed - and even then usually only for particular versions or time periods. Our online identification tool gives a first read on the family.
• How were the files encrypted? Some families encrypt every byte. Others, for speed, encrypt only the start of each file or alternate encrypted and skipped blocks; SentinelOne documented intermittent encryption in BlackCat, PLAY and Black Basta back in 2022. Large files that were only partly encrypted often still hold a great deal of extractable data.
• What survived? Offline backups, storage and hypervisor snapshots, cloud-drive version history, copies on staff laptops, the same data held in downstream systems. Any one of them can end up carrying the recovery.
• What happened afterwards? Reboots, reinstalls, formatting and recovery software installed onto the affected disk all overwrite remnants that were still retrievable. A lot of "unrecoverable" data was lost to the rescue attempts, not to the malware.

Until all four questions have real answers, "recoverable" and "unrecoverable" are both guesses.

The table covers the situations we meet most often. A single incident usually allows several of these paths at once; the assessment checks each and combines them.

A few notes:

• Public decryptors are the exception. Which families have one, and the limits of each, is covered in which ransomware decryption tools exist.
• Partial encryption is the biggest opportunity for large files. Databases and virtual disks run to tens of gigabytes and are slow to encrypt in full, so many families only cover part of them. In the ESXiArgs campaign of February 2023 the encryptor left the flat files holding virtual disk data unencrypted, and the US agency CISA released a script that rebuilt virtual machines from those disks. Method is covered under database encrypted and virtualization platform encrypted. To be clear, structural repair produces readable data, not necessarily the original file.
• Do not count on Windows shadow copies. Deleting them and emptying backup catalogues is standard ransomware behaviour, listed in MITRE ATT&CK as a technique of its own (T1490). Array, NAS and hypervisor snapshots sit outside the encrypted system's permissions and survive far more often; see backups deleted or encrypted.
• Deleted originals may still be on disk. Not every encryptor overwrites in place; some write an encrypted copy and delete the original. Deleted data can be carved until something overwrites it, which matters most on file servers full of small files - provided writes stopped straight away. See file server and NAS encrypted.

"Cannot be recovered" deserves the same clarity as "can". In these situations the room for recovery is usually very small:

• A modern family with correct cryptography and no leaked keys, and files encrypted in full. Such families generate a separate key per file and wrap it with a public key the attackers control; without their private key there is no mathematical shortcut. Many of the families common in China in recent years fall into this group, and the current status of each is recorded on its family page.
• Small files encrypted completely. Office documents, PDFs and images are small enough that encryptors usually cover them end to end, leaving no unencrypted region to extract.
• Every copy sat inside the same permission boundary. A backup server joined to the production domain, NAS snapshots deletable by the same administrator account, off-site sync that faithfully copied the encrypted files - in environments like these, backups tend to fail together with production.
• Data was wiped rather than encrypted. Some attacks use wipers, or ransomware with a wipe mode such as Anubis, and file contents are simply overwritten; no key can bring them back.
• The scene has already been destroyed. Repeated reboots, OS reinstalls, formatting, or recovery software run on the original disk with output written to the same volume overwrite both deleted originals and unencrypted regions.

Where this is the situation, the assessment names the data that is definitively lost. We do not inflate the recoverable scope, and we do not push ahead with recovery work that has no substantive prospect of success.

The same extension can lead to opposite conclusions. The usual dividing lines are these:

• Encryption date and version. The Mallox decryptor Avast released in October 2024 only works on versions circulating from 2023 to early 2024; the operators fixed the flaw around March 2024, and files encrypted afterwards cannot be opened with it. SRLabs' Black Basta tool likewise only covers versions from roughly November 2022 to December 2023.
• Whether keys were obtained. When law enforcement seized LockBit's infrastructure in February 2024 the FBI already held more than 2,500 decryption keys, rising to over 7,000 by June that year. That is a lot of keys, yet still only a subset of victims; see the LockBit family page.
• Online key or offline key. STOP/Djvu falls back to a built-in offline key when it cannot reach its server. Emsisoft's tool can only decrypt files encrypted with offline keys it holds; files encrypted with an online key cannot be decrypted.
• File size and type. In a single run, large files may have only their headers encrypted while small files are covered completely. On one server, the database may yield most of its business tables while not a single Word document opens.
• Whether the scene was preserved. Some recovery methods rely on file modification times to narrow the key search - the published method for Akira's Linux/ESXi variant is one - and once timestamps are rewritten that route closes. Avast's Mallox tool must run on the computer where encryption happened, so reinstalling the operating system first may leave it unusable.

So "someone said this extension can be decrypted" cannot simply be applied to your environment. The answer has to come from your own samples.

The purpose of an assessment is to put in writing, before any recovery work, what can be recovered, to which point in time, and what cannot. Our approach:

1. Identify family and version. Cross-check the note, extension, contact details and encrypted samples, and establish whether a public tool, seized keys or a known flaw applies.
2. Measure encryption coverage. Run entropy analysis on key files to establish full, header-only or intermittent encryption.
3. Inventory every data source. Backups, snapshots at each layer, offline media, endpoint copies and downstream systems, each checked for survival and cleanliness.
4. Trial on copies. Attempt decryption or structural repair on read-only images, proving each path with real data.
5. Issue a written conclusion. Per system: recoverable scope, achievable recovery point, gaps and expected duration.

The initial conversation and the first read on the family are free. A full assessment requires access to the environment, imaging and trial repairs; whether and how it is charged is explained and confirmed before it starts. The overall sequence is on our process page, and what drives cost and duration is covered in how much ransomware recovery costs and how long it takes.