reverse-skills-max/vendor-new/analyst-ai-pack/skills/handling-malware-samples-safely/SKILL.md

name, description, domain, subdomain, tags, version, author, license, mitre_attack, d3fend, references

name	description	domain	subdomain	tags	version	author	license	mitre_attack	d3fend	references
handling-malware-samples-safely	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.	cybersecurity	lab-foundations	malware sample-handling hashing defanging chain-of-custody hygiene	1.0.0	analyst-ai-pack	Apache-2.0	T1027	D3-FA	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:

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:

mv sample.exe 9f86d0818...<sha256>.bin

Step 2: Store in an encrypted archive

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:

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:

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 for the hashing, provenance, and defang tooling.
• MalwareBazaar and NIST SP 800-86 (linked in frontmatter).