Analyzing ransomware encryption behavior

Skill meltedinhex/analyst-ai-pack/skills/analyzing-ransomware-encryption-behavior

An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.

Install

npx -y skills add meltedinhex/analyst-ai-pack --skill analyzing-ransomware-encryption-behavior

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Analyzes how a ransomware sample encrypts files: identifying the crypto scheme (symmetric/asymmetric/hybrid), key handling, file targeting and extension/marker changes, shadow-copy deletion, and ransom-note artifacts. Activates for requests to analyze ransomware encryption, assess decryptability, or study ransomware behavior.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.8 KB, as published. Nobody here has run it

Analyzing Ransomware Encryption Behavior

When to Use

You need to understand how a ransomware sample encrypts data and whether recovery without the key is feasible.
You are documenting file targeting, markers, and the ransom workflow for an IR report.
You want to identify the crypto primitives to assess decryptability and detection points.

Do not use this to attempt key recovery on production data without backups; analyze in the lab on disposable test files only.

Prerequisites

Isolated lab with disposable test files of varied types/sizes.
Static/RE tools (see the Ghidra and crypto-identification skills) and the dynamic-analysis setup.
A clean snapshot to revert.

Safety & Handling

Detonate only against throwaway files in the isolated victim VM; never real data.
Treat the sample and any dropped components as live; revert after each run.

Workflow

Step 1: Identify the crypto scheme statically

Locate crypto constants and APIs to classify the scheme:

Symmetric only (AES/ChaCha/RC4)  -> key may be derivable/recoverable if mishandled
Asymmetric (RSA/ECC) wrapping    -> per-file symmetric key wrapped with attacker pubkey
Hybrid (typical)                 -> AES per file, RSA-wrapped key in the encrypted file/footer

Look for AES S-boxes, ChaCha constants ("expand 32-byte k"), and CryptImportKey/BCrypt*.

Step 2: Trace key generation and handling

Determine where the symmetric key comes from (CSPRNG vs weak source), whether it is stored, and how it is protected. Weak/reused keys or keys left in memory are recovery opportunities.

Step 3: Map file targeting

Identify which directories/extensions are targeted or skipped (allowlist of system paths), size thresholds, and partial-vs-full encryption (many encrypt only the first N bytes/blocks for speed).

Step 4: Capture markers and metadata

Most families append an extension, write a per-file footer/magic marker, and store the wrapped key or IV there. The script fingerprints before/after test files to extract markers.

python scripts/analyst.py compare plain/ encrypted/

Step 5: Document recovery-relevant facts

Note shadow-copy/backup deletion (vssadmin delete shadows), the ransom note, and any cryptographic mistakes that affect decryptability.

Validation

The identified scheme matches observed file changes (e.g. hybrid → high-entropy body + a fixed-size footer).
File markers/extensions are consistent across encrypted test files.
Shadow-copy deletion and note-drop are confirmed dynamically.

Pitfalls

Assuming decryptability from the algorithm name; correct AES/RSA usage is not recoverable. Recovery hinges on implementation flaws or leaked keys.
Missing partial-encryption schemes, leading to wrong impact assessment.
Running against real files instead of disposable test data.

References

See references/api-reference.md for the file-marker comparison tool.
No More Ransom and NIST crypto standards (linked in frontmatter).