Recovery methodsTechnical

Ransomware Encryption Patterns and Recovery Paths

Ransomware does not always encrypt files the same way — recovery depends on whether data was overwritten in place, copied and the original deleted, only partially encrypted, or protected by a key that turned out to be recoverable.

Symmetric, hybrid, and everything in between

Encrypting large files directly with public-key cryptography is inefficient, so a common efficient pattern is hybrid encryption: generate a random symmetric key, encrypt file content quickly with that key, then protect the symmetric key itself using an asymmetric public key, storing an encrypted key blob alongside the file or in victim metadata. This gives an attacker speed, unique per-victim or per-file keys, and no need to embed the actual decryption key inside the malware. If correctly implemented, possessing both the malware executable and the encrypted files does not hand over the private key needed to decrypt them.

A public key in ransomware is not a decryption secret

Ransomware frequently embeds the attacker's public key, whose role is to encrypt or wrap victim keys, not to decrypt them. Finding an “RSA key” string inside a malware sample is not evidence of a usable decryption key — the attacker can safely distribute the public half; the private key remains the actual secret.

Per-host vs. per-file keys, and implementation flaws

Some families use one symmetric key per victim host; others generate a separate random key per file. Beyond correct hybrid designs, some implementations contain embedded or static keys, broken random-number generation that makes keys predictable, or server-generated victim keys obtained by malware communicating with attacker infrastructure — any of which can make a family decryptable despite its designers' intentions. Decryptability is an implementation property of a specific variant, not a property of “ransomware” as a category.

Full-file encryption is not the only pattern

Modern ransomware often optimizes for speed by encrypting only the first N bytes, selected ranges, alternating chunks, the beginning and end, or metadata/index regions of a file, while skipping small files or certain extensions and directories entirely. This can leave files partially readable, structurally recognizable, or recoverable through application-specific repair even when full decryption is unavailable — “encrypted file” does not always mean every byte of the file is actually encrypted.

Partial encryption invites application-aware reconstruction

A large database or similar structured file with only periodically encrypted blocks may be recoverable by decrypting what a key allows, recovering the unencrypted pages directly, using the application's own redundancy, combining a clean backup with surviving changed pages, or recovering an unaffected secondary replica. This is not ordinary file carving — it is application-aware reconstruction of a file that was only partly cryptographically damaged, and it can succeed even without a working decryptor.

In-place encryption destroys the original at the same logical location

Where ransomware reads a file, encrypts each block, and writes the ciphertext back into the same file, no original plaintext remains in those logical sectors for deleted-file recovery to find. Only backups, snapshots, a working decryptor and key, or separate stale copies elsewhere can help in that specific pattern.

Encrypted copy plus deleted original opens a second recovery path

An alternative pattern reads the original file, writes a new encrypted copy under a different name, then deletes the original. This creates two independent recovery avenues: decrypting the encrypted copy, or recovering the deleted original if the underlying storage has not yet overwritten or reclaimed it. Recoverability of that deleted original depends on the same factors as any other deletion — HDD vs. SSD, TRIM, filesystem, subsequent writes, and how much free-space reuse has happened since. On an HDD, metadata may still point to the deleted original and its clusters may survive; on an SSD, TRIM can make those plaintext remnants inaccessible quickly. Before assuming decryption is the only path, determine which pattern actually occurred.

Memory and backups are separate recovery avenues, not decoration

If ransomware is still actively running, volatile memory can contain process state, encryption keys, derived key material, or command-and-control artifacts — valuable but not guaranteed, since practical recovery depends on the family's implementation, whether key material stays resident, and how long the process has been running. Separately, a legitimate offline or offsite backup, a snapshot the attacker could not reach, or an independent secondary copy can restore data with no decryption required at all, provided the backup infrastructure itself was not also targeted or destroyed during the incident.

Nested encryption multiplies the layers to unwind

A SAN LUN carrying a VMFS datastore, a VMDK, an NTFS filesystem and a SQL database can all sit beneath a single ransomware pass over the virtual disk, and a partial pass over that VMDK can damage many guest-level files indirectly. Recovery is often better targeted at the virtual-disk structure level, the guest filesystem level, or the application database level individually, rather than treating one large encrypted VMDK as a single generic file to decrypt all at once.

Practical rule

Determine what actually happened to the original plaintext — overwritten in place, copied and deleted, or only partially touched — before assuming decryption is the only recovery path available.