malware-triage

name	malware-triage
description	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.

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

• 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