reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
@@ -0,0 +1,122 @@
|
||||
---
|
||||
name: handling-malware-samples-safely
|
||||
description: 'Establishes safe practices for acquiring, storing, transferring, and disposing
|
||||
of malware samples: password-protected archives, neutralized extensions, hashing for
|
||||
identity, and chain-of-custody. Activates for requests about safely storing or sharing
|
||||
malware, sample handling hygiene, or defanging artifacts.'
|
||||
domain: cybersecurity
|
||||
subdomain: lab-foundations
|
||||
tags:
|
||||
- malware
|
||||
- sample-handling
|
||||
- hashing
|
||||
- defanging
|
||||
- chain-of-custody
|
||||
- hygiene
|
||||
version: 1.0.0
|
||||
author: analyst-ai-pack
|
||||
license: Apache-2.0
|
||||
mitre_attack:
|
||||
- T1027
|
||||
d3fend:
|
||||
- D3-FA
|
||||
references:
|
||||
- 'MalwareBazaar — https://bazaar.abuse.ch/'
|
||||
- 'NIST SP 800-86 Guide to Integrating Forensic Techniques — https://csrc.nist.gov/pubs/sp/800/86/final'
|
||||
---
|
||||
|
||||
# Handling Malware Samples Safely
|
||||
|
||||
## When to Use
|
||||
|
||||
- You are receiving, storing, or sharing a malicious file and need to prevent accidental
|
||||
execution or contamination.
|
||||
- You need a consistent naming and identity scheme so a sample can be tracked across tools
|
||||
and tickets.
|
||||
- You are packaging a sample to send to another analyst or a sandbox.
|
||||
|
||||
**Do not use** these conventions as a substitute for an isolated detonation environment; safe
|
||||
storage prevents accidents but analysis still requires an isolated lab.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- An archive tool that supports password-protected, encrypted archives (7-Zip).
|
||||
- A hashing utility (`sha256sum`, `certutil`, or the bundled script).
|
||||
- A defined storage location with restricted access, separate from general file shares.
|
||||
|
||||
## Safety & Handling
|
||||
|
||||
- Treat every sample as live. Never double-click; never leave it with its original
|
||||
executable extension on a working machine.
|
||||
- Store samples inside an **encrypted, password-protected archive** with the conventional
|
||||
password `infected`.
|
||||
- **Neutralize the extension** on disk (e.g. `sample.exe` → `sample.exe.bin` or
|
||||
`sample.exe_`) so the OS will not execute it on a stray click.
|
||||
- **Defang indicators** in any text leaving the lab: `hxxp://`, `1.2.3[.]4`, `evil[.]com`.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Identify the sample by hash
|
||||
|
||||
A sample's identity is its SHA-256, not its filename. Compute hashes immediately:
|
||||
|
||||
```bash
|
||||
python scripts/analyst.py hash sample.exe
|
||||
# md5, sha1, sha256, size, ssdeep-like size bucket
|
||||
```
|
||||
|
||||
Rename the working copy to its SHA-256 so identity travels with the file:
|
||||
|
||||
```bash
|
||||
mv sample.exe 9f86d0818...<sha256>.bin
|
||||
```
|
||||
|
||||
### Step 2: Store in an encrypted archive
|
||||
|
||||
```bash
|
||||
7z a -p"infected" -mhe=on <sha256>.7z <sha256>.bin
|
||||
# -mhe=on encrypts filenames too
|
||||
```
|
||||
|
||||
Keep the loose, neutralized copy only inside the lab; the archive is the storage/transfer
|
||||
form.
|
||||
|
||||
### Step 3: Record provenance
|
||||
|
||||
Capture where the sample came from, when, and who handled it. The script can emit a JSON
|
||||
metadata record:
|
||||
|
||||
```bash
|
||||
python scripts/analyst.py record <sha256>.bin --source "MalwareBazaar" --case CASE-001
|
||||
```
|
||||
|
||||
### Step 4: Defang before sharing
|
||||
|
||||
When pasting URLs/IPs into a report or ticket, defang them:
|
||||
|
||||
```bash
|
||||
python scripts/analyst.py defang ioc.txt
|
||||
# http://evil.com/x -> hxxp://evil[.]com/x
|
||||
```
|
||||
|
||||
## Validation
|
||||
|
||||
- `7z l -slt <sha256>.7z` shows encrypted headers (filenames not visible without password).
|
||||
- The on-disk working copy has a neutralized extension and matches the recorded SHA-256.
|
||||
- The provenance record contains source, timestamp, case ID, and all three hashes.
|
||||
- No raw clickable URLs/IPs remain in any artifact destined to leave the lab.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Sharing a sample in a plain zip — mail gateways and AV will quarantine or mangle it, and
|
||||
recipients risk accidental execution. Always password-encrypt.
|
||||
- Trusting the filename or first-seen label as identity; only the hash is authoritative.
|
||||
- Forgetting filename encryption (`-mhe=on`), which leaks the sample name and your naming
|
||||
scheme.
|
||||
- Defanging only URLs but leaving live IPs or email addresses in the report.
|
||||
|
||||
## References
|
||||
|
||||
- See [`references/api-reference.md`](references/api-reference.md) for the hashing,
|
||||
provenance, and defang tooling.
|
||||
- MalwareBazaar and NIST SP 800-86 (linked in frontmatter).
|
||||
Reference in New Issue
Block a user