skilly. Buy ad slot
All skills
Community / AGENT SKILL

analyzing-ransomware-encryption-behavior

meltedinhex/analyst-ai-pack
0 installs 22 GitHub stars
0

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.

BEFORE YOU INSTALL

Understand the trade-offs.

SECURITY REVIEW

Not yet assessed

Review the original instructions and requested permissions before installing.

No security review is available for this catalog entry yet.

SKILL QUALITY

Not yet assessed

How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.

No quality assessment is available for this catalog entry yet.

The full skill.

Original instructions from the publisher’s SKILL.md

# 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:

```text
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.

```bash
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`](references/api-reference.md) for the file-marker
  comparison tool.
- No More Ransom and NIST crypto standards (linked in frontmatter).