SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Community / AGENT SKILL
handling-malware-samples-safely
0
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.
Understand the trade-offs.
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
# 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).