Malware triage
47 Claude skills for security tradecraft across AppSec, Pentest, Blue Team, and GRC. NL/EU regulatory-anchored. Pattern-level discipline.
npx -y skills add roodlicht/accans-sec-skills --skill malware-triageAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 4 stars4 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
Malware triage workflow — sandbox output analysis (CAPE/Hybrid-Analysis/ANY.RUN/Joe Sandbox), YARA rule scaffolding at pattern level, IOC extraction, and TTP mapping to MITRE ATT&CK. Sandbox-only discipline; do not detonate in production or without an isolated runtime.
SKILL.md
11.5 KB, ~2.9k tokens by cl100k_base, as published. Nobody here has run it
Malware Triage
Sandbox-only discipline: analysing a sample means running it in an isolated environment. Detonating in production or on a workstation with network egress creates an incident instead of solving one. Treat all samples as worm-class — that discipline costs less than a production outbreak. Detailed reverse engineering (debugger-attached, IDA Pro / Ghidra interactive) is out of scope here — that is a further specialization. The skill covers sandbox-driven triage and YARA scaffolding at signal-pattern level.
When to use
A suspicious file or process lands on your SOC desk. Before you can say "clean" or "incident", you need a structured triage. This skill provides the structure.
Triggers on:
- A question like "what does this sample do", "write a YARA rule for this family", "ATT&CK mapping from this sandbox output", "is this the same malware family as last month".
- A handoff from
ioc-hunter(sample known, IOCs needed),log-triage(suspect-execution event in EDR),forensics-assist(memory-extracted binary),ir-runbook(sample is part of an incident). - Bug-bounty or bug disclosure where a sample is provided.
- A periodic review of EDR quarantine.
When NOT (handoff)
- Deep reverse engineering with disassembler/debugger → out of scope. Requires specialized reverse work.
- Detection-rule building on IOCs or TTPs →
detection-engineer(Sigma/SPL/KQL). - IOC feed curation and sharing →
ioc-hunter. - Forensic evidence-grade analysis for court →
forensics-assistplus a specialized forensics team. - Active response after a confirmed incident →
ir-runbook. - Production detonation → don't. Lab/sandbox only.
- Attacker-tooling replication or tuning → out of scope.
Approach
Six phases. Phase 1 (intake discipline) and phase 4 (YARA scaffolding) are where triage work becomes durable.
1. Intake and sandbox choice
- Sample acquisition: file comes from EDR quarantine, an email attachment, a USB find, or a public repo. Ensure secure transfer to the lab (encrypted, password-protected ZIP outside production paths).
- Hash-first check: compute SHA-256, look up against VirusTotal / Hybrid-Analysis / abuse.ch MalwareBazaar / internal history. Known? Then triage can be sped up by reading existing analysis.
- Sandbox choice:
- CAPE Sandbox (open-source, on-prem) — Cuckoo fork with config extraction. Default for on-prem-only policy.
- ANY.RUN (commercial, cloud) — interactive sandbox with manual progression. Good for user-interaction-required malware.
- Joe Sandbox (commercial) — deep, multi-OS.
- Hybrid-Analysis (Falcon Sandbox, free for research) — solid free tier.
- VirusTotal — not just hash lookup; runs a sandbox if a sample is uploaded. Beware: upload is public; do not use for confidential samples.
- Live versus static first pass: before you run dynamic, gather static info — file type, headers, embedded strings, packer fingerprints (
pestudio,die,flossfor obfuscated strings,binwalkfor archives).
Discipline: confidential samples (potential PII, potential IP leak) go to an on-prem sandbox or a paid private tier, not public VirusTotal.
2. Static-analysis pass
Before dynamic execution:
- File type and metadata: PE/ELF/Mach-O/script (PowerShell/JS/macro), compiler info, signing status.
- String extraction (
strings,flossfor stack-encoded). Hosts, URLs, file paths, mutex names, registry keys. - Sections / imports / exports: unusual imports (CryptAcquireContext + InternetOpen + WriteFile is a frequent ransomware pattern),
.textsection size vs entropy (high entropy = packed). - YARA first pass: known rules from community repositories (
Yara-Rules,Neo23x0/signature-base,Elastic/protections-artifacts) against the sample. A known-family match speeds up the rest. - Code-signing check: signed but unknown publisher is a red flag (stolen or dropped cert). Verify the cert chain.
3. Dynamic analysis via sandbox
Sandbox runs in an isolated VM with instrumented process events.
- Process-tree observation: parent → child → grandchild. Classic suspect:
winword.exe → cmd.exe → powershell.exe → certutil.exe. - Network egress: DNS queries (resolved and unresolved), HTTP requests, TLS fingerprints (JA3/JA4), C2 hosts. Match against
ioc-hunterfeeds. - Filesystem changes: writes to Startup folders, schedule folders, AppData paths.
- Registry changes: Run keys, services, COM hijacks, BITS jobs.
- API calls: WriteProcessMemory + CreateRemoteThread (process injection T1055), CryptEncrypt burst (ransomware), VirtualProtect (shellcode runtime).
- Persistence-mechanism detection: scheduled-task creation, service installation, registry Run keys.
- Anti-VM / anti-sandbox: CPUID checks, mouse-movement checks, sleep-skip detection. The sandbox output usually shows whether detection happened.
For user-interaction malware (banking trojans, info-stealers with UI trigger): manual interaction in an interactive sandbox.
4. YARA-rule scaffolding at pattern level
YARA is the standard for malware classification. We write rules at pattern level, not for one specific binary.
rule SUSPECT_MyFamily_Loader {
meta:
author = "<analyst>"
date = "YYYY-MM-DD"
description = "Detects MyFamily loader pattern with embedded config string"
reference = "<sandbox-report-link>"
hash_seen = "<sha256>"
tlp = "AMBER"
strings:
$config_marker = "MYCFG_v2:" ascii wide
$api_resolve_a = "GetProcAddress" ascii
$api_resolve_b = "LoadLibraryA" ascii
$unique_string = "MyFamilyLoader/" ascii nocase
$opcode_pattern = { 8B ?? ?? ?? 89 ?? E8 ?? ?? ?? ?? }
condition:
uint16(0) == 0x5A4D and // PE header
filesize < 5MB and
(
$config_marker or
($unique_string and 2 of ($api_resolve_*) and $opcode_pattern)
)
}
Discipline:
meta.author,meta.date,meta.tlp: tracking and sharing policy.meta.hash_seen: what the rule was conceived against; helps later reviewers.- Specific enough to distinguish at family level, not so specific that a second sample from the same family is missed.
- Performance-aware: wildcards in opcodes and heavy regex against all files slow scanners down. Anchor with PE magic, file-size limits, context.
- Test for false positives: scan the rule against 1000+ benign binaries before production deployment.
yaraCLI orThreatray/Cylancetest corpora. - Sharing: TLP classification explicit. Open-share community rules to the Yara-Rules repo, sector-share via FI-ISAC NL or MISP events.
5. TTP extraction and ATT&CK mapping
Sandboxes give raw events; mapping them to ATT&CK techniques makes them reusable.
Per observation: technique T-ID. Common mappings:
- Embedded macro that downloads PowerShell → T1566.001 (Spearphishing Attachment) + T1059.001 (PowerShell).
- Process hollowing → T1055.012.
- LSASS access → T1003.001.
- Scheduled-task creation → T1053.005.
- Registry Run key → T1547.001.
- Network C2 over HTTPS → T1071.001 + T1573.002.
- DNS-tunneling C2 → T1071.004.
- Tor dropper / I2P → T1090.003 (multi-hop proxy).
ATT&CK coverage output: a table with technique T-ID, observation, evidence link (sandbox-report section). Provides input for detection-engineer (which detection rules are touched by this family) and purple-ops (gap analysis: which we miss).
6. Output, sharing, and verification-loop
- Family classification (if recognized): name + version (where known), source attribution (which vendor classifies it as such).
- IOCs extracted: hashes, IPs/domains/URLs, mutex names, file paths, registry keys. Forward to
ioc-hunterwith a confidence score. - YARA rule(s): as new or as refinement of existing.
- TTP mapping: ATT&CK table.
- Recommendations for the blue-team stack: which rules cover this, which are missing.
Sharing: keep confidential context internal; for community samples share to MISP / abuse.ch MalwareBazaar / VirusTotal / FI-ISAC.
Verification-loop: Layer 1 scope (all observations from the sandbox report carried over, sandbox ran fully?, no anti-sandbox detection bypass skipped?). Layer 2: ATT&CK T-IDs correct, family attribution only when there is a vendor source (no invented attribution), YARA syntax against the current YARA version (4.x), sandbox-feature claims (CAPE config extraction, ANY.RUN interactive) current.
Output
Malware triage report — <sample-id / hash>
SHA-256: <hash>
File type: <PE/ELF/Mach-O/script>
Sandbox: <CAPE/ANY.RUN/Joe/etc> | Run-id: <ref>
First seen: <date/source>
TLP: <classification>
Static analysis:
Compiler: <ref>
Packed/obfuscated: <yes/no, method>
Strings of interest: <briefly noted, redacted>
Code-signing: <signed-by-X / unsigned / suspicious>
YARA pre-match: <existing family rules that match>
Dynamic observations:
Process tree: <parent → child → ...>
Filesystem writes: <persistence paths>
Registry changes: <run keys / services>
Network egress: <C2 hosts, DNS queries, JA3/JA4>
API pattern: <process injection / encryption burst / etc>
Persistence: <mechanism>
Anti-sandbox: <detected / not>
Family classification:
Name: <known family or "unknown variant">
Variant: <if derived>
Attribution: <vendor source if available>
IOCs (handoff to ioc-hunter):
Hashes: <list>
IPs: <list>
Domains: <list>
URLs: <list>
Mutex: <list>
TLP: <classification>
YARA rule(s):
<full rule block>
TTP mapping (ATT&CK):
Tactic | Technique-ID | Observation | Sandbox-evidence-ref
Recommendations:
Detection (handoff to detection-engineer): <which rules to write>
Hunt (handoff to ioc-hunter / threat-hunt): <retro window>
Cleanup (handoff to ir-runbook): <if live infection>
Verification-loop: ...
References
- MITRE ATT&CK — https://attack.mitre.org/. Technique mapping.
- CAPE Sandbox — https://github.com/kevoreilly/CAPEv2. Open-source dynamic analysis.
- abuse.ch MalwareBazaar — https://bazaar.abuse.ch/. Sample repository, signature database.
- YARA — https://virustotal.github.io/yara/. Pattern-matching framework.
- Yara-Rules / signature-base (Neo23x0) — https://github.com/Neo23x0/signature-base. Community rules.
- MalAPI.io — https://malapi.io/. API-to-technique mapping for static analysis.
- VirusTotal — https://www.virustotal.com/. Public hash lookup and sandbox; mind upload policy for confidential samples.
- Hybrid-Analysis — https://www.hybrid-analysis.com/. Falcon Sandbox, free tier for research.
- MITRE TRAM — https://github.com/center-for-threat-informed-defense/tram. NLP tool for TTP extraction from reports.
- Florian Roth — Yara Style Guide — https://github.com/Neo23x0/YARA-Style-Guide. Practical YARA best practices.
Categories
- blue
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.