Is it possible to deliberately preserve a small set of files, along with backups of their original versions, so that if a ransomware attack occurs, security researchers could compare the pre-encryption and post-encryption versions and potentially recover the decryption key or otherwise build a decryptor?
If so:
- Is there a canonical or especially useful set of file types that should be preserved for this purpose?
- What characteristics make certain files more valuable than others in a known-plaintext or before/after comparison attack?
- Under what conditions can this approach actually work, and why does it fail against many modern ransomware families?
- What is the most practical defender-oriented checklist of files and related artifacts to archive now, so that if a future decryptor becomes possible, the chances of successful recovery are maximized?
The goal is not to assume you will be able to break the ransomware. The goal is to preserve the kinds of artifacts that are most useful if the ransomware later turns out to have made a cryptographic mistake, or if a public decryptor becomes available.
- PNG files
- PDF files
- DOCX / XLSX / PPTX files
- ZIP files
- One append-heavy database file, such as SQLite
- One or two small text or config files whose original contents are known exactly
- One standard image or template file used repeatedly in the environment
- The clean/original copy
- The encrypted version, if an attack occurs
- The original path and filename
- The encrypted filename and any added extension
- Before/after file sizes
- Timestamps
- A SHA-256 hash of the clean file
- A SHA-256 hash of the encrypted file
- The ransom note
- At least one sample encrypted file
- The ransomware-added extension, if any
- Any notes about when the attack happened and which systems were affected
- If safely captured by professionals, a copy of the malware binary or launcher
- 1 PNG
- 1 PDF
- 1 DOCX
- 1 XLSX
- 1 ZIP
- 1 append-heavy database file
- 1 small known text/config file
- 1 common template or reference image
- 1 ransom note, if attacked
- Encrypted counterparts of the above, if available
The most useful pair is often the exact same file before and after encryption: same filename, same original location, and a clean version from backup.
Sometimes, yes — but there is no universal canonical set of files that guarantees recovery.
When ransomware researchers succeed by comparing a clean file to its encrypted version, the real reason is usually not merely the existence of a before/after pair. What they are typically exploiting is a cryptographic or implementation mistake in the ransomware.
Examples of mistakes that can make recovery possible include:
- Reused keystream
- Reused nonce or IV
- Weak XOR-style encryption
- Deterministic partial encryption
- Broken key generation
- Improper key reuse across files
If the ransomware uses sound modern cryptography correctly — for example, a fresh per-file symmetric key or nonce, with those keys then protected using the attacker’s public key — then having both the original and encrypted versions of the same file usually does not let you recover the decryption key.
That is why this approach is best understood as an opportunistic recovery aid, not a primary defense strategy.
The best files for this kind of analysis are those with highly predictable structure or exactly known content.
These are especially valuable:
- PNG files, because they have a well-defined signature and chunk structure
- PDF files, because they start with recognizable headers and have regular internal structure
- ZIP files
- Office files such as DOCX, XLSX, and PPTX, because they are ZIP-based containers internally
- Small template-based text or config files whose contents are known exactly
- Append-heavy database files, where an older copy and a newer encrypted copy may differ mostly by appended data
The strongest possible sample is not just a “good file type,” but a file whose original bytes are known exactly. A standard company logo, a stock image used everywhere, a blank template, an exported form, or a known installer can all be more useful than a random user-created document.
This approach works only under fairly specific conditions. The biggest enabler is usually a real flaw in the ransomware.
The conditions that can make recovery feasible include:
-
The same key material or keystream is reused across files.
In that case, one known plaintext/ciphertext pair may reveal information useful for decrypting others. -
Encryption is partial, patterned, or deterministic.
Some ransomware encrypts only parts of each file for speed, which can leave useful structure visible. -
The file format reveals a lot about the plaintext.
Fixed headers, signatures, and internal structure increase the amount of known plaintext. -
Multiple files of the same type are available.
A large set of samples can reveal patterns that a single pair cannot. -
The clean and encrypted copies are truly corresponding versions of the same file.
Exact pairing matters. Random clean files of the same type are much less valuable than the real before/after pair.
The decisive factor is almost always whether the ransomware made a mistake. The file set only helps researchers exploit that mistake.
Many modern ransomware families cannot be defeated this way.
If the ransomware uses correct modern cryptography with:
- fresh per-file keys,
- fresh nonces/IVs,
- proper authenticated encryption, and
- attacker-held asymmetric key wrapping,
then known plaintext is usually not enough to recover the decryption key.
In other words:
There is no magic file set that defeats correctly implemented ransomware.
That is why preserving helpful files is worthwhile as a secondary recovery aid, but attacker-inaccessible backups remain the real defense.
The practical takeaway is straightforward:
- Preserve helpful file pairs and incident artifacts because they may help researchers later.
- Do not assume cryptanalysis will work.
- Maintain offline, immutable, or otherwise attacker-inaccessible backups.
The preserved-file approach is best viewed as:
A way to improve your odds in the rare cases where the ransomware is flawed — not a substitute for proper backups.
Yes, you can prepare a useful set of files and artifacts that may help future decryptor efforts. But what makes recovery possible is usually a weakness in the ransomware, not the mere existence of those files.
