Ransomware Architecture and Threat Model
Ransomware is the most operationally impactful malware category: it converts cryptographic asymmetry into leverage. Done correctly, a ransomware attack is cryptographically irreversible without the attacker's private key — the victim must pay or lose their data. Understanding ransomware architecture means understanding not just how to encrypt files, but how the entire key hierarchy, network communication, victim identification, and payment flow work together. This chapter establishes the threat model, the cryptographic architecture, and the operational design before any code is written.
Ransomware Threat Model
PHASE 1: Initial Access and Lateral Movement (pre-encryption)
─────────────────────────────────────────────────────────────────────────
Attacker gains initial access (phishing, exploit, purchased access)
→ Deploy RAT, establish persistence
→ Reconnoiter network, escalate privileges to Domain Admin
→ Identify backup infrastructure
→ Exfiltrate sensitive documents (double-extortion leverage)
→ Disable/destroy backups (VSS, Veeam, NetBackup)
→ Deploy ransomware to ALL systems simultaneously
→ DETONATE
PHASE 2: Encryption (Day 0 — simultaneous across all systems)
─────────────────────────────────────────────────────────────────────────
Ransomware deployed via:
- GPO (if Domain Admin) — pushed to all domain machines simultaneously
- PSExec / WMI lateral spread
- Manual deployment via C2 to each victim
Each victim machine:
→ Generate random symmetric key (AES-256-GCM)
→ Encrypt all target files with this key
→ Encrypt the symmetric key with attacker's RSA public key
→ Write encrypted key blob alongside encrypted files
→ Delete original files (or overwrite in place)
→ Wipe VSS (shadow copies) so no local recovery
→ Display ransom note
PHASE 3: Negotiation and Payment
─────────────────────────────────────────────────────────────────────────
Victim contacts attacker via Tor hidden service (dark web leak site)
Attacker provides decryptor tool + price (typically $50K-$50M+ for enterprises)
If no payment in N days: attacker publishes stolen data (double extortion)
Payment in cryptocurrency (Monero/Bitcoin)
Attacker provides private key → victim uses to decrypt their symmetric keys → decrypt files
DOUBLE EXTORTION VALUE:
Even if victim has backups → they still pay to prevent data leak
Even if victim restores from backup → attacker still has the data
Backup restoration is expensive and slow (days/weeks for large orgs)
Both threats compound each otherCryptographic Architecture — The Key Hierarchy
LAYER 1: File-level AES key (unique per file)
─────────────────────────────────────────────────────────────────────────
For each file to be encrypted:
Generate: random 32-byte AES-256-GCM key (K_file)
Generate: random 12-byte GCM nonce (N_file)
Encrypt file content: ciphertext = AES-256-GCM(K_file, N_file, plaintext)
Write: ciphertext to file (replaces original)
LAYER 2: Session RSA wrapping
─────────────────────────────────────────────────────────────────────────
The file's K_file is encrypted with the attacker's RSA public key:
K_file_encrypted = RSA-OAEP-SHA256(attacker_pubkey, K_file)
Written alongside each encrypted file:
.encrypted_key blob: [K_file_encrypted][N_file][victim_id][file_hash]
Or (more common): encrypt all K_files with a single session AES key,
then encrypt that session key with attacker RSA (fewer RSA operations).
LAYER 3: Attacker RSA private key (never on victim machine)
─────────────────────────────────────────────────────────────────────────
RSA private key: stored ONLY on attacker's server
To decrypt: attacker provides the private key (after payment)
Victim uses private key to decrypt session key → decrypt all K_files → decrypt files
WHY THIS HIERARCHY?
─────────────────────────────────────────────────────────────────────────
RSA encrypt entire files: too slow (RSA can only encrypt ~256 bytes at once)
AES encrypt everything with one key: if that key is recovered, all files decrypt
The hybrid approach:
Fast AES encryption for file content (gigabytes per second)
RSA wraps only the small AES key (256 bytes, fast)
RSA private key never touches the victim → cryptographically sound
VICTIM IDENTIFICATION:
Each victim gets a unique ID (generated from machine identifiers or random).
The attacker's negotiation portal uses this ID to associate decryption keys.Ransomware Variants and Operational Modes
/* Ransomware configuration structure — defines operational parameters */
typedef enum {
MODE_ENCRYPT_FULL = 0, /* Encrypt entire file (safe, slower) */
MODE_ENCRYPT_PARTIAL = 1, /* Encrypt first N bytes only (fast, some files still usable) */
MODE_ENCRYPT_INTERLEAVE = 2, /* Encrypt every other 512-byte block (fastest, hardest to detect) */
MODE_WIPER = 3, /* No encryption — overwrite with random bytes (no payment option) */
} EncryptionMode;
typedef struct {
/* Encryption parameters */
EncryptionMode mode;
DWORD partial_bytes; /* For MODE_ENCRYPT_PARTIAL: bytes to encrypt at file start */
/* File targeting */
BOOL skip_system_files; /* Don't encrypt Windows system files (would prevent OS boot) */
BOOL encrypt_network_shares;
BOOL encrypt_removable;
DWORD min_file_size; /* Skip tiny files (not worth encrypting) */
DWORD64 max_file_size; /* Skip enormous files if in fast mode */
/* Extensions to ENCRYPT (NULL = all files) */
const WCHAR **include_extensions; /* e.g., .docx, .xlsx, .pdf, .sql */
/* Extensions to SKIP */
const WCHAR **exclude_extensions; /* e.g., .exe, .dll, .sys, .lnk */
/* Directories to SKIP */
const WCHAR **exclude_dirs; /* Windows\, Program Files\, etc. */
/* Key management */
BYTE attacker_rsa_pubkey[2048]; /* Attacker's RSA-2048 public key */
BYTE victim_id[16]; /* Unique identifier for this victim */
/* Operational */
BOOL delete_shadow_copies;
BOOL disable_recovery_tools;
BOOL wipe_backups;
DWORD thread_count; /* Parallel encryption threads */
/* Ransom note */
const char *note_filename; /* e.g., "HOW_TO_DECRYPT.txt" */
const char *note_content; /* The ransom note text */
} RansomwareConfig;
/* Default configuration — tuned for enterprise target */
static const RansomwareConfig DEFAULT_CONFIG = {
.mode = MODE_ENCRYPT_PARTIAL,
.partial_bytes = 512 * 1024, /* 512KB — enough to corrupt most files */
.skip_system_files = TRUE,
.encrypt_network_shares = TRUE,
.encrypt_removable = TRUE,
.min_file_size = 4096, /* Skip files under 4KB */
.max_file_size = 512ULL * 1024 * 1024, /* Skip files over 512MB if partial */
.delete_shadow_copies = TRUE,
.disable_recovery_tools = TRUE,
.thread_count = 8, /* 8 parallel encryption threads */
.note_filename = "HOW_TO_DECRYPT.txt",
};Questions & Answers
Why is using RSA directly to encrypt files a bad design, and what's the correct approach?
RSA is an asymmetric cipher designed for small data — specifically, RSA-2048 can encrypt at most 214 bytes of plaintext per operation (RSA block size minus OAEP padding overhead). A 1MB file would require thousands of RSA operations, and RSA is mathematically expensive: a single RSA-2048 encryption takes approximately 1-2ms on modern hardware. Encrypting 100,000 files averaging 100KB each with RSA would take hours on a single core. The correct hybrid approach: use AES-256-GCM (gigabytes per second throughput, hardware-accelerated on modern CPUs with AES-NI) to encrypt file contents. Generate a random 32-byte AES key for each file (or for the session). Then use RSA-OAEP to encrypt only that 32-byte key — one fast RSA operation per file key. The attacker's private RSA key decrypts the AES key, which decrypts the file content. This is exactly how TLS, PGP, and all hybrid encryption systems work. The math: AES encrypts 1GB in ~1 second, RSA-OAEP encrypts a 32-byte key in ~1ms. A 100,000-file corpus averages ~100GB of file data: pure RSA would take days, hybrid takes minutes.
What happens if the C2 server is down when the ransomware runs and can't receive the victim's keys?
This is the critical architectural decision. Three approaches: (1) Online key exchange (riskiest for victim): the ransomware generates a random AES key locally, immediately tries to send it to the C2 server, and only proceeds with encryption after confirmation. If C2 is down, it retries or doesn't encrypt. Risk: if the C2 is taken down (FBI seizure, CDN blocking), victims can't decrypt even if they pay. Real ransomware groups have been burned by this — victims who paid couldn't decrypt because the C2 was seized. (2) Offline encryption with embedded RSA public key (standard): the RSA public key is hardcoded in the ransomware binary. No C2 needed for encryption — the file is always encrypted with the attacker's public key. The victim can't decrypt without the attacker providing the private key. C2 availability affects only the payment portal and decryptor delivery, not the encryption itself. This is the professional approach — Conti, BlackCat, LockBit all use embedded RSA public keys. (3) Offline key generation with secure delivery: generate an asymmetric key pair on the victim, encrypt victim's private key with attacker's public key and send to C2, discard victim's private key locally. But this requires online delivery and is vulnerable to interception.
What distinguishes successful ransomware groups from less effective ones in terms of technical implementation?
Technical differentiators in successful ransomware operations: (1) Speed: REvil could encrypt a 50TB enterprise environment in 4 hours using multithreaded encryption with I/O-optimized file access patterns and partial encryption of large files. Slower ransomware gives defenders time to detect and stop mid-encryption. (2) Shadow copy deletion before encryption, not after: deleting VSS before encrypting means even if encryption is stopped partway, the shadow copies are already gone. Victims can't restore partially encrypted files from shadow copies. (3) Network share propagation built-in: enterprise ransomware doesn't just encrypt the local machine — it walks SMB shares, reaching file servers, backup servers, and collaboration platforms. (4) Backup hunter: specific code to find and destroy Veeam, NetBackup, Acronis, and Windows Server Backup — not just VSS. (5) Privilege escalation before detonation: domain admin → GPO push → simultaneous detonation on all machines. Manual one-by-one deployment is detectable and stoppable. (6) Decryption proof: provide a "decrypt one file for free" capability to prove the decryptor works and build trust for payment.
Is there any defense against a well-executed ransomware attack?
The only reliable defenses against a cryptographically sound ransomware attack are preventative (stopping the attack before encryption) and backup-based (restoring from offline backups). After encryption with a proper key hierarchy, there is no technical recovery path without the attacker's private key. Preventative controls: network segmentation (limits propagation), EDR with behavioral detection (catches file modification patterns before completion), canary files (specially monitored "decoy" files that alert if modified — ransomware triggers the alert when it encrypts the canary), and privileged access controls (domain admin credentials that ransomware needs for propagation). Backup controls: the "3-2-1" backup rule specifically with offline/immutable backups. Online backups (same network, writable) are also encrypted or deleted. Immutable cloud backups (AWS S3 Object Lock, Azure Blob immutable storage, tape) are the last line. From a detection engineering perspective: ransomware has high-signal behavioral indicators — rapid file modification, I/O patterns targeting document extensions, VSS deletion events, and ransom note file creation. SIEM rules on these indicators can trigger containment before full encryption completes.
What is "double extortion" and how does it change the victim's calculus?
Traditional single-extortion ransomware: "pay us or lose your data." If you have good backups, you restore and don't pay. Double extortion adds: "we also stole your data before encrypting it, and we'll publish it publicly if you don't pay." Now the calculus changes: even if you can restore from backup (avoiding the encryption ransom), you face data breach liability, regulatory fines (GDPR, HIPAA), customer notification requirements, and reputational damage from having your internal documents, customer data, employee PII, and business strategies published on a dark web leak site. The threat of publication is often more compelling than the encryption itself for enterprises with mature backup programs. Triple extortion (emerging): add DDoS of victim's web services and direct customer contact ("your supplier was breached — ask them about it") to maximize pressure. The evolution toward extortion-only (no encryption, just data theft) is beginning — some groups steal data and threaten to publish without encrypting, which is faster, requires less technical sophistication in the payload, and is harder to detect (no file modification spike on the SIEM).