Analyzing Ransomware Encryption MechanismsSAFE

817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains ·

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: analyzing-ransomware-encryption-mechanisms
description: 'Analyzes encryption algorithms, key management, and file encryption
  routines used by ransomware families to assess decryption feasibility, identify
  implementation weaknesses, and support recovery efforts. Covers AES, RSA, ChaCha20,
  and hybrid encryption schemes. Activates for requests involving ransomware cryptanalysis,
  encryption analysis, key recovery assessment, or ransomware decryption feasibility.

  '
domain: cybersecurity
subdomain: malware-analysis
tags:
- malware
- ransomware
- encryption
- cryptanalysis
- reverse-engineering
version: 1.0.0
author: mahipal
license: Apache-2.0
nist_csf:
- DE.AE-02
- RS.AN-03
- ID.RA-01
- DE.CM-01
mitre_attack:
- T1486
- T1573.001
- T1573.002
- T1027
mitre_f3:
  version: '1.1'
  tactics:
  - monetization
  - positioning
  techniques:
  - id: F1018
    name: Convert to Cryptocurrency
    tactic: monetization
    source: f3
  - id: F1047
    name: Transfer of funds
    tactic: monetization
    source: f3
  - id: T1219
    name: Remote Access Tools
    tactic: positioning
    source: attack
---

# Analyzing Ransomware Encryption Mechanisms

## When to Use

- A ransomware infection has occurred and recovery requires understanding the encryption scheme used
- Assessing whether decryption is possible without paying the ransom (implementation flaws, known decryptors)
- Reverse engineering ransomware to identify the encryption algorithm, key derivation, and key storage mechanism
- Developing a decryptor tool when a weakness in the ransomware's cryptographic implementation is identified
- Classifying a ransomware sample by its encryption approach to attribute it to a known family

**Do not use** for production data recovery operations without first verifying the decryption method on test copies of encrypted files.

## Prerequisites

- Ghidra or IDA Pro for reverse engineering the ransomware binary
- Python 3.8+ with `pycryptodome` library for testing encryption/decryption routines
- Sample encrypted files and their corresponding plaintext originals (known-plaintext pairs)
- Access to the ransomware binary (unpacked if applicable)
- Familiarity with symmetric (AES, ChaCha20) and asymmetric (RSA) cryptographic algorithms
- NoMoreRansom.org database for checking existing free decryptors

## Workflow

### Step 1: Identify the Encryption Algorithm

Determine which cryptographic algorithm the ransomware uses:

```python
# Check for Windows Crypto API usage in imports
import pefile

pe = pefile.PE("ransomware.exe")

crypto_apis = {
    "CryptAcquireContextA": "Windows CryptoAPI",
    "CryptAcquireContextW": "Windows CryptoAPI",
    "CryptGenKey": "Windows CryptoAPI key generation",
    "CryptEncrypt": "Windows CryptoAPI encryption",
    "CryptImportKey": "Windows CryptoAPI key import",
    "BCryptOpenAlgorithmProvider": "Windows CNG (modern crypto)",
    "BCryptEncrypt": "Windows CNG encryption",
    "BCryptGenerateKeyPair": "Windows CNG asymmetric key gen",
}

print("Crypto API Imports:")
for entry in pe.DIRECTORY_ENTRY_IMPORT:
    for imp in entry.imports:
        if imp.name and imp.name.decode() in crypto_apis:
            print(f"  {entry.dll.decode()} -> {imp.name.decode()}: {crypto_apis[imp.name.decode()]}")
```

```
Common Ransomware Encryption Schemes:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AES-256-CBC + RSA-2048:    Most common hybrid scheme (LockBit, REvil, Conti)
AES-256-CTR + RSA-4096:    Stream cipher mode variant (BlackCat/ALPHV)
ChaCha20 + RSA-4096:       Modern stream cipher (Hive, Royal)
Salsa20 + ECDH:            Curve25519 key exchange (Babuk)
AES-128-ECB:               Weak mode - potential decryption via known-plaintext
XOR-only:                  Trivial encryption - always recoverable
Custom algorithm:          Often contains implementation flaws
```

### Step 2: Analyze Key Generation and Management

Reverse engineer how encryption keys are generated and stored:

```
Key Management Patterns in Ransomware:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. STRONG (no recovery possible without key):
   - Per-file AES key generated with CryptGenRandom
   - AES key encrypted with embedded RSA public key
   - Encrypted key appended to each file or stored separately
   - RSA private key held only by attacker's C2 server

2. WEAK (potential recovery):
   - AES key derived from predictable seed (timestamp, PID)
   - Same AES key used for all files (single key compromise = full recovery)
   - Key transmitted to C2 before encryption starts (PCAP may contain key)
   - XOR with short repeating key (brute-forceable)
   - PRNG seeded with GetTickCount or time() (limited keyspace)

3. FLAWED IMPLEMENTATION:
   - ECB mode (preserves plaintext patterns)
   - Initialization vector (IV) reuse across files
   - Key stored in plaintext in memory (recoverable from memory dump)
   - Partial encryption (only first N bytes encrypted)
```

### Step 3: Examine File Encryption Routine

Reverse engineer the file processing logic:

```c
// Typical ransomware file encryption flow (decompiled pseudo-code from Ghidra):

void encrypt_file(char *filepath) {
    // 1. Check file extension against target list
    if (!is_target_extension(filepath)) return;

    // 2. Generate per-file AES key (32 bytes for AES-256)
    BYTE aes_key[32];
    CryptGenRandom(hProv, 32, aes_key);

    // 3. Generate random IV (16 bytes)
    BYTE iv[16];
    CryptGenRandom(hProv, 16, iv);

    // 4. Read file contents
    HANDLE hFile = CreateFile(filepath, GENERIC_READ, ...);
    BYTE *plaintext = read_entire_file(hFile);

    // 5. Encrypt with AES-256-CBC
    aes_cbc_encrypt(plaintext, file_size, aes_key, iv);

    // 6. Encrypt AES key with RSA public key
    BYTE encrypted_key[256];  // RSA-2048 output
    rsa_encrypt(aes_key, 32, rsa_pubkey, encrypted_key);

    // 7. Write: encrypted_data + encrypted_key + IV to file
    write_file(filepath, encrypted_data, encrypted_key, iv);

    // 8. Rename file with ransomware extension
   

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (4)

bytes.fromhex("637c777bf26b6fc53001672bfed7ab76"): "AES S-Box (Rijndael)",

bytes.fromhex("52096ad53036a538bf40a39e81f3d7fb"): "AES S-Box (continued)",

bytes.fromhex("6a09e667bb67ae853c6ef372a54ff53a"): "SHA-256 initialization vector",

bytes.fromhex("d1310ba698dfb5ac"): "Blowfish P-array fragment",

Gates applied: no_behavioural_pass.