After a ransomware attack, a free decryptor can save weeks of rebuilding, but a wrong, fake or badly run tool can destroy the only copy of the encrypted data or reinfect the network. Free decryption tools exist for a minority of ransomware families, published by security vendors and law enforcement through projects such as No More Ransom. This guide explains when a decryptor is realistic, how to identify the strain correctly, where legitimate tools come from, how to verify and test them on copies, and how to fold decryption into a recovery plan without destroying evidence. It also covers the data recovery firms that claim to decrypt without paying. It is written for incident responders, IT managers and recovery leads. The wider response, from containment to rebuild, is in the Ransomware Response and Recovery Guide, which this page does not repeat.
Key takeaways
- Most victims will not find a decryptor. The UK NCSC states that files encrypted by most ransomware "typically have no way of being decrypted by anyone other than the attacker"; plan recovery around backups and treat a decryptor as a bonus path.
- Identification comes first. A decryptor works for a specific family and often specific versions, so confirm the strain from the ransom note, the file extension and a sample file before downloading anything.
- Only take tools from the publisher or No More Ransom. Each No More Ransom entry names the vendor that made the tool and links a how-to guide; tools passed around on forums or offered by email are a malware risk.
- Never decrypt the only copy. Preserve images and copies of encrypted data, clean the system first, test the tool on a copy, and check output integrity before you trust it.
- "We can decrypt it" needs proof. Data recovery firms have charged victims for "proprietary" decryption while quietly paying the attackers, which brings sanctions and disclosure risk; ask how they will decrypt before engaging.
How free decryptors come to exist
Modern ransomware normally encrypts each file with a symmetric key and protects those keys with the operator's public key, so without the operator's private key the data cannot be recovered by brute force. A free decryptor becomes possible only when something breaks that model. Understanding which route produced a tool tells you how likely it is to work on your files.
| Route | What happened | What it means for victims |
|---|---|---|
| Implementation flaw | Researchers find a weakness in how the ransomware generates or stores keys, or in its encryption routine | Often works only for specific versions; operators usually fix the flaw once a tool is public, so newer infections may not be covered |
| Seized keys | Law enforcement gains access to operator infrastructure and recovers key material | Can cover many victims at once; may be distributed as a public tool or offered by contacting the agency |
| Leaked or released keys | Keys are leaked by insiders or rivals, or released when a group shuts down | Coverage depends on what was leaked; vendors usually package keys into a tool |
| Partial or intermittent encryption | Some strains encrypt only parts of large files for speed | Some data may be recoverable with file repair or carving even without a key; this is specialist work |
Law enforcement disruption is the clearest recent example of the seized keys route. After the February 2024 Operation Cronos action against LockBit, the FBI said in June 2024 that it held over 7,000 LockBit decryption keys and asked anyone who suspected they were a victim to report through ic3.gov. The Cybercrime Law Enforcement Takedowns Guide explains how such operations work, and the LockBit Threat Actor Profile covers the group itself.
Flaw-based tools appear for current families too. The No More Ransom tool list includes decryptors attributed to Avast for Akira, to SR Labs for BlackBasta and to Truesec for Chaos, alongside older families such as Cerber V1 and CoinVault. Listing does not mean every version of a family is covered: each entry has its own conditions.
Step one: identify the ransomware correctly
Running the wrong decryptor wastes time and can damage files. Identify the family before searching for a tool, and record how you reached the identification so it can be checked later.
- Ransom note: the file name, layout, contact method (Tor portal, email, chat ID) and any victim ID are the strongest indicators. Copy the note; do not delete it.
- Encrypted file extension and markers: many families append a fixed or victim-specific extension or write a recognisable footer into each file.
- Sample encrypted file: a small encrypted file, ideally with an unencrypted original of the same file from a backup or email attachment. Several tools need this "file pair" to work.
- Binary and telemetry: if your EDR or antivirus quarantined the payload, its detection name and hash give another identification route. Keep the sample for forensics; see the Digital Forensics (DFIR) Guide.
Identification services: ID Ransomware identifies the likely family from an uploaded ransom note and sample encrypted file (or contact addresses where there is no note) and says whether a known decryption method exists; it does not decrypt. Its FAQ said it detected 1,189 variants when checked. No More Ransom's Crypto Sheriff offers a similar check linked to its tool list. Before uploading, read the privacy terms: ID Ransomware states that files are stored temporarily on a shared host, that it cannot guarantee full confidentiality, that unmatched files may be shared with trusted analysts, and that email and Bitcoin addresses found may be shared with third parties or law enforcement. Do not upload encrypted files that contain regulated or highly sensitive data; choose a harmless file such as an encrypted image or template.
Treat the result as a hypothesis. Families rebrand and reuse code, and builders leak, so a match can point to a related strain. Cross-check with your incident response provider or threat intelligence. The Ransomware Family Lineage and Rebrands Guide and the Babuk and Leaked Builder Variants Guide explain why one name can cover several incompatible versions.
Where legitimate decryptors come from
No More Ransom is the main public catalogue. It was launched by the Netherlands' National High Tech Crime Unit, Europol's European Cybercrime Centre, Kaspersky and McAfee to help victims recover data without paying criminals, and the site is offered in 38 languages. Its tool list names the provider of every tool (for example Bitdefender and Emsisoft for Avaddon, Kaspersky and Avast for AES_NI) and links a how-to guide for each.
| Source | What you get | Checks before use |
|---|---|---|
| No More Ransom tool list | Decryptors from partner vendors and law enforcement, each with a how-to guide | Confirm the family and version conditions in the guide; download from the linked provider page |
| Security vendor decryptor pages | The vendor's own tools, sometimes before they reach No More Ransom | Reach the page from the vendor's main domain, not a search advert; read the stated requirements (file pairs, versions) |
| Law enforcement | Keys or tools from seized infrastructure, sometimes offered only on contact | Report through official channels (in the US, CISA, the FBI field office or IC3; in the UK, the official reporting route); never respond to unsolicited "agency" emails offering keys |
| Your incident response retainer | Access to private tooling and key collections, plus experience with the family | Ask what the method is and whether any payment to the attacker is involved |
| Forums, file shares, unsolicited emails | Unknown | Do not use: repackaged or fake decryptors are a known lure |
CISA's #StopRansomware Guide (September 2023, written with MS-ISAC, NSA and the FBI) tells victims to consult federal law enforcement "regarding possible decryptors available" even where mitigation is possible, because agencies may hold keys that are not public. Reporting early therefore serves recovery as well as legal duties.
Verifying and running a decryptor safely
A decryptor rewrites your files, so treat it like any change to production data. The ordered steps below assume the incident is contained and the decision to try decryption has been made by the incident lead.
- Preserve evidence first. CISA advises preserving volatile evidence such as system memory and Windows Security logs and powering down only as a last resort. Image affected disks or snapshot affected volumes, and keep a read-only copy of a representative set of encrypted files before any decryption attempt.
- Clean the system. No More Ransom warns that the malware must be removed before running a decryptor, or it may keep encrypting files or locking the system. In practice, decrypt on a rebuilt or isolated clean host and copy data to it, rather than on the infected server.
- Verify the tool. Download only from the provider page linked by No More Ransom or the vendor. Where the vendor publishes a hash, compare it; check that the Windows executable carries a valid code signature from the named vendor. Scan it before use in an isolated environment.
- Read the how-to guide. No More Ransom asks users to read the guide before downloading or running a tool. Note version limits, whether a file pair is needed (Emsisoft's ApocalypseVM tool, for example, needs an encrypted file of at least 4,096 bytes plus its original), and whether the tool deletes encrypted files after success. Turn off any "delete encrypted file" option.
- Test on copies. Run the tool on a copied sample set on an isolated host. Open the outputs in their applications, compare hashes with any originals from backup, and check databases and archives for internal consistency.
- Decrypt in waves. Prioritise by business need, decrypt to a separate location rather than in place, and keep the encrypted copies until the business owner confirms the data is complete. Log every run, tool version and result.
- Roll back if needed. If outputs are corrupt or incomplete, discard them and return to the preserved encrypted copies; nothing should have been lost. Record the failure for your provider or the tool vendor, who may release a fix.
Emsisoft's decryptor page states that its free tools are provided "as-is and without warranty of any kind" and may only work with specific versions. Assume the same of every free tool: the responsibility for testing sits with you.
Deciding between decryptor, backups and rebuild
A decryptor is one restore path among several. The NCSC calls up-to-date backups "the most effective way of recovering from a ransomware attack". Choose per system, not per incident.
| Situation | Usual choice | Why |
|---|---|---|
| Clean, recent backups exist and restore time is acceptable | Restore from backup; keep the decryptor as fallback | Backups restore a known good state; decrypted files may still be incomplete |
| Backups missing or encrypted, tested decryptor available | Decrypt copies onto rebuilt clean hosts | Recovers data without paying; the system itself should still be rebuilt |
| Backups stale, decryptor available | Restore backups, then decrypt only the data created since | Limits reliance on the decryptor to the gap |
| No decryptor, no usable backups | Preserve encrypted data, keep checking for tools, consider partial recovery and the business decision on payment | New tools and seized keys appear later; keep encrypted copies |
| Data was also stolen | Any of the above plus data breach handling | Decryption does not address extortion over stolen data or notification duties |
Do not decrypt operating systems back into service. Use decryption for data. Servers and endpoints should be rebuilt from known good images, because the attacker's persistence, accounts and tooling survive decryption. See the Recovering IAM and PAM After Ransomware or Domain Compromise for rebuilding the identity layer.
Keep the encrypted data. If no tool exists today, retain encrypted copies under a defined retention decision. Keys from takedowns and new flaw-based tools have appeared months or years after attacks, and the cost of storage is small compared with the data.
Small and large organisations: a small business with one encrypted file server can follow the steps with its IT provider in a day; the main risk is running a tool directly on the only copy. A large organisation with hundreds of encrypted hosts should run decryption as a managed workstream with its incident response provider, with a test lab, a tracker per system and business sign-off for each data set.
Recovery firms and "guaranteed decryption"
Some data recovery firms advertise the ability to decrypt any ransomware. A 2019 ProPublica investigation found that two US firms that claimed proprietary recovery methods had in fact paid the attackers for keys, including payments traced to the SamSam operators, and did not always tell clients. A researcher's test, posing as a victim of a deliberately unbreakable fake strain, drew offers from both firms to decrypt it.
- Ask the method: is there a public decryptor, private key material, or a payment to the attacker? A firm that cannot explain how it decrypts a family with no known flaw is probably paying.
- Sanctions exposure: a payment made on your behalf can still create sanctions and legal exposure. See the Ransomware Payments and Sanctions Guide.
- Insurer and counsel: cyber insurers often require their panel providers and approval before payment or recovery spending; involve them before engaging any firm. See the Cyber Insurance Guide.
- Negotiation is separate: if the business decides to negotiate, run it deliberately with counsel. See the Ransomware Negotiation Guide.
An attacker-supplied decryptor also needs the same testing. The Colonial Pipeline ransomware attack page records that the company paid about 75 bitcoin and that its chief executive described the decryption tool it received as helpful but "not perfect".
Detection, logging and measurement
Decryption work happens during an incident, so record it as part of the incident record. Log the identification evidence, tool source and hash, tool version, host, data set, start and end time, and the validation result for each run. Monitor the clean decryption hosts with EDR and keep them off the production network until outputs are checked.
- Time to identification: hours from detection to a confirmed family, with evidence.
- Decryptor success rate: share of tested files that open and match backup hashes or pass application checks.
- Data recovered by path: percentage of critical data sets restored from backup, decryptor or rebuild.
- Integrity failures: number of decrypted data sets rejected by business owners.
- Exercise coverage: whether the last ransomware exercise included the identify, verify and test steps on this page.
Framework mapping
| Framework | Reference | Relevance to decryptors |
|---|---|---|
| MITRE ATT&CK | T1486 Data Encrypted for Impact; T1490 Inhibit System Recovery | The techniques a decryptor or backup restore reverses; T1490 is why backups and shadow copies may be gone |
| NIST CSF 2.0 | RS.AN-03, RS.MI-01, RC.RP-01, RC.RP-03, RC.RP-05 | Analysis (identification), containment before decryption, recovery execution, verifying restoration assets and restored data |
| NIST CSF 2.0 | PR.DS-11 | Backups created, protected and tested, which decide whether a decryptor is needed |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, CP-9, CP-10, SI-3, SI-7 | Incident handling and reporting, backup and reconstitution, malware removal before decryption, integrity checks on tools and outputs |
Common failure patterns
- Decrypting the only copy in place: a tool fails part way, or deletes encrypted originals, and the data is gone for good. Always work on copies and decrypt to a new location.
- Running a decryptor on an infected host: the ransomware is still active and re-encrypts, or the attacker still has access. Clean or rebuild first, as No More Ransom warns.
- Trusting a name match: the family was identified from the extension alone, but it was a rebrand or a builder variant and the tool silently produced corrupt output.
- Downloading a "decryptor" from a search advert or forum: the tool is a fake that installs another payload during the most chaotic week the organisation will have.
- Uploading sensitive files to identification services: regulated data leaves the organisation on a shared host. Use harmless sample files.
- Paying a recovery firm that pays the attacker: the victim funds the criminals unknowingly and inherits sanctions and disclosure questions.
Practitioner checklist
- Add a decryptor workstream to the ransomware playbook: identify, source, verify, test, decrypt in waves, validate.
- Preserve disk images and copies of encrypted files before any decryption attempt.
- Identify the family from the note, extension, sample file and EDR detection, and record the evidence.
- Check No More Ransom and the relevant vendor pages, and ask law enforcement about keys when you report.
- Download tools only from the named provider, check signatures or hashes, and read the how-to guide.
- Run tools only on clean, isolated hosts against copies, with delete options turned off.
- Validate outputs with hashes or application checks and business owner sign-off.
- Rebuild systems from known good images; use decryption for data only.
- Retain encrypted data under a recorded decision in case a tool appears later.
- Ask any recovery firm how it decrypts, and involve counsel and the insurer first.
Standards and references
- No More Ransom: Decryption Tools
- No More Ransom: About the Project
- CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide
- NCSC: Mitigating Malware and Ransomware Attacks
- MITRE ATT&CK: Data Encrypted for Impact
- MalwareHunterTeam: ID Ransomware
- Emsisoft: Ransomware Decryption Tools
- ProPublica: Ransomware Data Recovery Firms Paying Hackers
Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Backup Security and Immutable Backup Guide · Ransomware Payments and Sanctions Guide · Ransomware Groups Guide