SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-ransomware

re-ransomware

Security & auditing

View repository

Updated 10-16 05:06

About this skill

Ransomware analysis (encryption identification / ransom note / decryption recovery)

When to use / when not to use

  • Use: samples where victim files are encrypted (extension changes, corrupted file headers, increased entropy) and ransom notes (README/DECRYPT) appear
  • Use: when you need to determine "whether recovery is possible" and provide a decryption recovery path (key extraction → decryption script / community decryption tools)
  • Use: encryption algorithms, key management, and C2 interaction reconstruction of ransomware samples
  • Don't use: the sample has not yet been confirmed as ransomware (first do [[re-triage]] initial triage + [[re-behavior]] behavior confirmation)
  • Don't use: when only analyzing the encryption algorithm itself (go directly to [[re-crypto-id]] / [[re-crypto-keys]])
  • Note: running the sample = it will actually encrypt files, so it must be inside a sandbox snapshot ([[re-sandbox]] is a mandatory prerequisite, [[re-analyze/platform-tips]] highest principle); static analysis can skip the sandbox

Tool preparation

Verify all tools before use. The complete setup of the encryption trio and the sandbox is covered in their respective skills and is reused directly by this skill; unique to this skill is the filesystem snapshot tool (to prevent the sample from encrypting and destroying the analysis environment, pitfall 1).

Encryption analysis trio (reusing the crypto domain)

  • [[re-crypto-id]]: algorithm identification (constant table fingerprints, custom encryption)
  • [[re-crypto-keys]]: key extraction (hardcoded/memory/resources)
  • [[re-crypto-decrypt]]: decryption script (see that skill for pycryptodome installation)
  • Verify: python3 -c "from Crypto.Cipher import AES; print('ok')"(see [[re-crypto-decrypt]])

Sandbox environment (runtime prerequisite)

  • [[re-sandbox]]: VM snapshot + network isolation (INetSim / fake DNS); dynamic analysis of ransomware samples defaults to the VM snapshot level (encryption behavior is highly destructive)
  • Verify: snapshot VBoxManage snapshot <vm> list has clean; network ping 8.8.8.8 unreachable

Filesystem snapshot tool (record pre-encryption state)

  • Linux: btrfs snapshot snapper——Debian/Ubuntu apt install snapper / Fedora dnf install snapper / Arch pacman -S snapper; verify: snapper --version. For non-btrfs use tar/rsync(built-in) to back up the observation directory
  • Windows: Volume Shadow Copy vssadmin(built into the system)——vssadmin list shadows verify; snapshots are also one of the decryption recovery paths (step 5)
  • macOS: Time Machine tmutil(built-in)——tmutil listbackups verify
  • Hashing/enumeration: sha256sum / find(built into coreutils)

Family identification and decryption tool research (online, no installation required)

  • ID Ransomware (id-ransomware.malwarehunterteam.com): upload the ransom note/encrypted file header to identify the family
  • No More Ransom (nomoreransom.org): a collection of official decryptors (pitfall 4 timeliness)
  • [[re-ti]]: look up the sample hash on VT / community reports to confirm the family and existing analysis conclusions

Operating steps

Execute in order, recording evidence (path + sha256, see [[re-triage]]) at each step. Static first ([[re-analyze/platform-tips]] static-first principle): do steps 1-2 on the host first, and only enter the sandbox when runtime is needed.

  1. Initial judgment (extension changes / encryption header characteristics / ransom note)：

    sha256sum sample.exe 被加密文件            # 存证（[[re-triage]]）
file 被加密文件                            # 文件头是否被改写/替换
xxd -l 64 被加密文件                       # 头部特征：固定前缀=感染 ID/密钥块，尾部特征同理
find / -xdev -iname "*README*" -o -iname "*DECRYPT*" -o -iname "*RECOVER*" 2>/dev/null
find . -type f -mmin -60 -size +1k | head  # 加密时间窗内被改动的文件
    • Judgment signals: batch extension changes (.crypt/.locker/.encrypted), original files deleted/overwritten, ransom notes appearing in directories, desktop wallpaper replaced
    • First, keep a baseline of the victim files' overall hash/directory listing (mutually backing up with the snapshot)

  2. Encryption algorithm identification (via the crypto domain)：

    • Static analysis of the sample: [[re-crypto-id]]——constant table fingerprints (AES S-box / RSA public key DER / CRC table), XOR/ROL/ROR transformations, whether hybrid encryption is used (RSA wrapping AES key is the most common)
    • Observation of the ciphertext: fixed blocks at the head/tail (infection ID, key block), ciphertext length alignment (AES block length 16), entropy (>7.0 → candidate for encryption/compression/high randomness, needs to be corroborated with file headers and context—high entropy itself is not a determination of encryption)
    • Determine one of three: symmetric (AES whole file) → find the symmetric key; asymmetric (RSA directly encrypting) → almost unrecoverable; hybrid (RSA encrypting the AES key) → if the key block is saved with the file, see step 3
    • Conclusion (algorithm hypothesis + evidence) passed to steps 3/5

  3. Key management recovery (local / network / C2 distribution)：

    • Local: [[re-crypto-keys]] static first (strings/hardcoded/resources/import table) → if not found, then go to memory ([[re-memdump]] defaults to dumping gcore; dump timing = while the encryption loop is executing, key has been derived but not destroyed)
    • Network/C2 delivery: in-sandbox [[re-sandbox]] (INetSim/fake DNS) + [[re-netcap]] packet capture, [[re-protocol]] reconstruction—the key may only be delivered at runtime by the C2, and cannot be obtained statically
    • Hybrid model: the sample contains an RSA public key, and the AES key is encrypted and written into the file header → unrecoverable without the private key (honestly disclose, see the pitfall in [[re-crypto-keys]])
    • Record source evidence for each candidate key (offset/function name/dump path), for use by [[re-crypto-decrypt]]

  4. Ransom note and C2 interaction (via [[re-protocol]])：

    • Read the ransom note: extract email / URL (Tor/dark web) / BTC address / infection ID → record into IOC ([[re-ioc]])
    • C2 interaction: [[re-protocol]] orchestration—[[re-netcap]] packet capture → [[re-crypto-id]] determine ciphertext → [[re-crypto-keys]] obtain key → [[re-crypto-decrypt]] decrypt traffic → [[re-proto-rev]] reconstruct interaction (key upload/status reporting/infection ID registration)
    • Key points of focus: whether data is uploaded before encryption (double extortion, pitfall 2), whether the key is sent back to the C2

  5. Recovery approach (key extraction → decryption script; no key → community tools)：

    • With key: [[re-crypto-decrypt]] write a batch decryption script (algorithm/mode/IV replayed per the [[re-crypto-id]] conclusion) → first validate on a small sample to obtain plaintext → then execute on the full set
    • Partial encryption/header encryption: only the first few KB of the header or some blocks are encrypted → truncating the header/rebuilding the file header can recover most files (first check whether the ciphertext length = the original length, this is the cheapest path)
    • No key: ID Ransomware to identify the family → No More Ransom / vendor decryptors (must match the variant, pitfall 4) → if ineffective, honestly report "currently unrecoverable"
    • Snapshot/backup recovery takes priority: vssadmin / snapper / Time Machine rollback (note the sample may delete shadow copies first, check whether they were deleted)
    • Output: recovery feasibility conclusion + decryption script + evidence chain ([[re-ioc]] report structure)

Cross-domain joint

  • [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]]: referenced respectively in steps 2/3/5, forming the main chain of encryption identification→key→decryption
  • [[re-sandbox]] / [[re-behavior]]: dynamic analysis mandatory prerequisite ([[re-analyze/platform-tips]] highest principle) and observation of encryption/exfiltration behavior
  • [[re-protocol]]: C2 interaction behind the ransom note (netcap / crypto-* / proto-rev), step 4
  • [[re-ti]]: sample hash/family identification (VT, ID Ransomware)
  • [[re-ioc]]: extract IOCs from ransom note email/URL/wallet address, key and ciphertext fingerprints
  • [[re-malware]]: this skill is referenced by the re-malware gateway (ransomware sample branch); behavior analysis/reporting follows the gateway full workflow
  • [[re-analyze/platform-tips]] related branches: default sandbox (encryption behavior is highly destructive), static-first, platform branches (snapper on Linux, vssadmin on Windows)

Common pitfalls and traps

  • The sample encrypts all files inside the sandbox: symptom - once the sample runs, all files on the sandbox disk are encrypted, including the sample itself and behavior logs, and forensic artifacts are destroyed; cause - running without a filesystem snapshot/honeypot isolation, or failing to restore the snapshot after analysis; countermeasure - [[re-sandbox]] snapshot + honeypot folders (place fake documents/fake keys to observe encryption target selection) + pass in the sample read-only, and restore the snapshot immediately after analysis (see [[re-sandbox]] for the pitfall checklist); keep the original sample and ciphertext copies in a separate backup on the host
  • Double extortion (data leak + encryption): symptom - the ransom note simultaneously threatens "encrypt files + publicly leak data", and focusing only on encryption misses the exfiltration stage; cause - double extortion model: steal data first (C2 upload) then encrypt, with ransom demands in two parts; countermeasure - [[re-behavior]] / [[re-netcap]] prioritize observing network exfiltration (leak impact is greater than encryption), record behavior and IOCs in two phases, and state them separately in the report
  • RaaS variant differences: symptom - different samples of the same family have different encryption extensions/algorithms/key schemes, and applying generic family conclusions leads to errors; cause - RaaS (Ransomware-as-a-Service) rents customizable variants to attackers, and each tenant can configure them; countermeasure - rely on actual testing of the sample at hand (reconfirm with [[re-crypto-id]]), and record sample-level features (sample hash/key block fingerprint) rather than family-level conclusions
  • Timeliness of decryption tools: symptom - the No More Ransom decryptor reports "not this variant" or produces garbled output; cause - the decryptor only covers specific variants/older versions, while new variants have changed algorithms or key schemes; countermeasure - first use ID Ransomware + sample hash to precisely match the variant before choosing a tool; if it fails, go the key extraction route (steps 3/5) or honestly report that recovery is impossible; tools are updated as C2 keys leak, so recheck periodically