How Ransomware Encrypts Your Files: A Technical Deep Dive

Ransomware is the most financially damaging category of malware operating today. Billions of dollars in ransoms, billions more in recovery costs, hospitals that can’t access patient records, manufacturers idled for weeks. But beneath the headlines, most people don’t actually understand how ransomware encrypts files — and that understanding matters, because it’s what determines whether recovery is possible, what mistakes attackers sometimes make, and why decryptors occasionally exist.

This is a technical walkthrough of how modern ransomware encryption works. Not a specific malware family — the general architecture that’s been refined over the past decade into the standard approach used by most current ransomware.

The Core Problem: Encrypting Fast Without Weaknesses

A ransomware operator faces a fundamental design problem. They need to encrypt potentially millions of files across a corporate network quickly, and they need the encryption to be mathematically unbreakable without the decryption key. But they also need to eventually hand over a working decryptor to victims who pay — so the key system needs to be manageable on their end.

The solution is a hybrid encryption scheme, combining the speed of symmetric encryption with the key management capabilities of asymmetric encryption. Understanding this architecture is the foundation of everything else.

Phase 1: Key Generation

When ransomware executes, the first thing it does is generate keys. Modern ransomware typically uses a layered key structure:

• The operator’s RSA key pair: The attacker generates an RSA-2048 or RSA-4096 key pair before the campaign. The public key is embedded in the ransomware binary. The private key stays on the attacker’s infrastructure — it never touches the victim’s machine. This is the master key.
• A per-victim RSA key pair: On execution, the malware generates a fresh RSA key pair unique to this victim. The public key is used to protect the symmetric keys. The private half is encrypted using the attacker’s embedded public key and stored in a ransom note or sent to the attacker’s C2 server.
• Per-file symmetric keys: For each file (or batch of files), the malware generates a unique AES-256 key. This key encrypts the actual file content. The AES key is then encrypted with the victim RSA public key and stored alongside the encrypted file.

Phase 2: File Encryption

With keys generated, the ransomware begins the encryption sweep. The typical process for each file:

1. Generate a random AES-256 key and IV (initialisation vector) for this file
2. Read the original file content into memory (or stream it)
3. Encrypt the content using AES-256 in CBC or CTR mode
4. Encrypt the AES key using the victim’s RSA public key
5. Write the encrypted content plus the encrypted AES key to disk
6. Either overwrite the original file or write a new file with a ransomware extension (.locked, .encrypted, or a custom extension unique to the family)
7. Optionally: securely delete the original using multiple overwrites

This design means that even if you recover the encrypted AES key from the file, you can’t decrypt it without the victim RSA private key — which is itself encrypted with the attacker’s master public key. The entire chain is unbreakable without the attacker’s master private key, assuming the implementation is correct.

Why AES for Files and RSA for Keys?

AES is a symmetric cipher — the same key is used to encrypt and decrypt. It’s extremely fast: a modern CPU can encrypt gigabytes per second using AES-NI hardware acceleration. That speed matters when you’re trying to encrypt a corporate file server with terabytes of data before anyone notices.

RSA is an asymmetric cipher — there’s a public key for encrypting and a private key for decrypting. It’s computationally expensive — orders of magnitude slower than AES — but it solves the key distribution problem. The attacker can embed a public key in the malware binary without giving away the ability to decrypt. Only whoever holds the private key can decrypt the AES keys, which are the actual file encryption keys.

If ransomware used only AES, the key would need to be either embedded in the binary (trivially extractable) or sent to a C2 server (blockable by cutting network access). The hybrid scheme means the AES keys are protected by a key that never leaves the attacker’s infrastructure.

Shadow Copies and Backup Deletion

Before or alongside encryption, modern ransomware almost always deletes Volume Shadow Copies — Windows’ built-in backup mechanism. Without this step, victims could restore files without paying. The standard command:

vssadmin.exe delete shadows /all /quiet
wmic shadowcopy delete
bcdedit.exe /set {default} recoveryenabled No
wbadmin delete catalog -quiet

Some ransomware variants also target backup software directly, terminating processes associated with Veeam, Backup Exec, and other backup agents before encrypting their databases. They also disable Windows automatic repair and recovery options, making restoration from within Windows impossible without external backups.

When Decryptors Exist: Implementation Mistakes

Free decryptors occasionally appear for specific ransomware families, provided by security researchers or law enforcement seizures. Understanding why they exist clarifies what “good” ransomware implementation means from the attacker’s perspective:

• Weak random number generation: Early ransomware sometimes used predictable or seeded random number generators to create AES keys. If the seed was the timestamp or another guessable value, keys could be reconstructed. Modern ransomware uses cryptographically secure PRNGs.
• Reused keys: Some variants encrypted multiple files with the same AES key. Finding the key for one file decrypts all files encrypted with that key. Modern implementations use unique keys per file.
• Key left in memory: Some implementations left the AES keys in process memory after use. Memory forensics tools could recover them from RAM dumps. Modern variants clear keys from memory immediately after use.
• C2 key storage: Some variants sent decryption keys to a C2 server and stored them there. Law enforcement takedowns or server seizures could recover those keys. Modern variants use the offline RSA scheme described above, requiring no C2 connection to encrypt files.
• Flawed RSA implementation: Bugs in the key generation code — such as not seeding the entropy pool correctly — could make the RSA key pair predictable.

Partial Encryption and Speed Optimisation

A trend in modern ransomware groups is intermittent encryption — rather than encrypting entire files, they encrypt only portions of each file (for example, the first 10% or every other 512-byte block). The file is still unreadable — a partially encrypted Office document, database file, or image is corrupt enough to be unusable — but encryption is dramatically faster. LockBit, one of the most prolific ransomware groups, made speed a core marketing point to their affiliates, claiming encryption speeds that outperformed competitors by encrypting only critical file sections.

The tradeoff is that intermittent encryption sometimes leaves recoverable fragments — forensic analysis has occasionally reconstructed partial data from files that were only partly encrypted. But for practical purposes, the files are still destroyed from the victim’s perspective.

What This Means for Defence

The encryption mechanism itself is mathematically sound — there’s no attacking modern AES-256 or RSA-4096 directly. Defence has to happen before or during execution, not after. The practical implications:

• Offline backups are the only real recovery option. Network-attached backups get encrypted. Cloud backups synced to the infected machine get encrypted. Immutable backups on isolated systems survive.
• Shadow copies alone aren’t enough. Every ransomware family deletes them. They shouldn’t be your primary recovery plan.
• Detection needs to happen in the pre-encryption phase. By the time files are being encrypted, you’re in damage limitation mode. The attacker has typically been in the network for days or weeks before deploying ransomware. SIEM detection of the precursor activity — credential theft, lateral movement, backup access — is where you stop it.
• Memory forensics during active incidents. If ransomware is actively running, a memory dump may capture encryption keys before they’re cleared. This requires immediate response.

References

• CISA StopRansomware Guide
• MITRE ATT&CK T1486 — Data Encrypted for Impact
• No More Ransom Project — Free Decryptors
• Kaspersky: Ransomware Encryption Mechanisms Explained