agentsclimarketplace

Malware triage

Skill roodlicht/accans-sec-skills/skills/malware-triage

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.From its SKILL.md

Install
npx -y skills add roodlicht/accans-sec-skills --skill malware-triage

Assembled 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.

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-assist plus 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, floss for obfuscated strings, binwalk for 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, floss for stack-encoded). Hosts, URLs, file paths, mutex names, registry keys.
  • Sections / imports / exports: unusual imports (CryptAcquireContext + InternetOpen + WriteFile is a frequent ransomware pattern), .text section 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-hunter feeds.
  • 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. yara CLI or Threatray/Cylance test 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-hunter with 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

Categories

  • blue

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.