# Static Triage > Use as the first analysis pass on a suspicious file — extracting strings, hashes, imports, and packing indicators without running it, to decide what it is and what to do next. - Skill: `jihedbfr-art/static-triage` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/static-triage` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/static-triage/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/static-triage --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose Before you run anything or crack open a disassembler, you triage a sample statically — reading the file itself for what it reveals. Static triage is fast, safe (no execution), and often tells you most of what you need: is this known, is it packed, what does it import, what strings does it leak. This skill covers that first pass, which decides whether a sample needs deeper analysis and steers where to look. ### When to use it The opening move on any suspicious file, after it's in an isolated lab (the building-a-malware-lab skill). It's triage, not full analysis — the goal is a fast verdict and a direction, not a complete reverse-engineering. ### Procedure 1. **Hash it and check reputation first.** Compute the hash and look it up — if it's known malware, you may not need to analyse it at all, just respond. If it's unknown, you know you're doing real work: ``` sha256sum sample # then look up the hash (VirusTotal etc.) ``` Handle the sample per lab hygiene; don't upload confidential samples to public services without authorisation. 2. **Identify the file type** — don't trust the extension. A `.pdf` may be a PE, a `.doc` may be a script. `file` reads the actual format: ``` file sample # real type, not the extension ``` 3. **Extract strings** — one of the highest-value, lowest-effort steps. Strings leak URLs, IPs, domains, file paths, registry keys, commands, and error messages that reveal behaviour and indicators: ``` strings -n 8 sample # ASCII strings -e l -n 8 sample # UTF-16 (common in Windows malware) ``` 4. **Inspect the PE structure** (for Windows executables) — imports reveal capability (network functions, crypto, process injection APIs), the compile timestamp and sections give context, and anomalies (few imports, odd section names, high entropy) suggest packing: ``` # pefile / PE-bear / CFF Explorer: imports, sections, entropy, resources ``` 5. **Check for packing/obfuscation.** High entropy, very few imported functions, unusual section names (UPX0, or random), and a tiny import table point to a packed sample — meaning static strings/imports are hidden and you'll need unpacking (that skill) or dynamic analysis: ``` # entropy per section; capa to infer capabilities despite obfuscation capa sample # maps to ATT&CK capabilities from static features ``` 6. **Form a verdict and direction** — known/unknown, packed/not, likely capability — and decide the next step: respond (if known), unpack, run in the sandbox, or disassemble. ### Cheatsheet ``` 1. HASH + reputation sha256sum -> lookup (known? -> respond, skip analysis) 2. FILE TYPE file sample (don't trust the extension) 3. STRINGS strings -n 8 sample ; strings -e l -n 8 sample (UTF-16) -> URLs/IPs/domains, paths, reg keys, commands, errors 4. PE STRUCTURE imports (capability), sections, entropy, timestamp, resources network/crypto/injection APIs in imports = capability hints 5. PACKING signs high entropy | few imports | odd section names | tiny IAT -> strings hidden -> need unpacking / dynamic analysis capa sample infer ATT&CK capabilities from static features output: verdict (known/unknown, packed?) + DIRECTION (respond / unpack / run / disasm) ``` ### Reading the triage - **A known-malware hash** = you may skip analysis and go straight to response (IoCs, remediation) — the fastest, highest-value outcome. Check reputation first. - **Rich, readable strings** (URLs, commands, IPs) = the sample isn't packed and is leaking its behaviour and indicators; extract them and you have much of your analysis for free. - **Sparse strings + few imports + high entropy** = packed/obfuscated; static analysis is limited, so plan to unpack or run it dynamically. The absence of readable content is itself the signal. - **Imports revealing capability** (network APIs, `VirtualAllocEx`/`WriteProcessMemory` for injection, crypto) = a strong hint at what it does before you run it. - **`capa` results mapping to ATT&CK** = inferred capabilities even under some obfuscation — a good bridge from triage to understanding. - **A clear direction from triage** (respond / unpack / sandbox / disassemble) = the point of the pass; you rarely need full RE on everything. ### Pitfalls - **Running before triaging.** Static triage is free and safe and often tells you enough; jumping to execution skips the cheapest information. Triage first. - **Trusting the extension.** Malware disguises file types; use `file` to see what it actually is. - **Missing UTF-16 strings.** Windows malware often stores strings as UTF-16; an ASCII-only `strings` run misses them. Check both encodings. - **Assuming no readable strings = nothing there.** Sparse strings usually mean packing, not benign — it's a signal to unpack or run dynamically, not to dismiss. - **Uploading sensitive samples to public services.** Reputation lookups are valuable, but confidential/targeted samples may tip off the attacker or leak data; follow lab and authorisation rules. ### References - Practical Malware Analysis (static analysis chapters) - capa, pefile / PE-bear / CFF Explorer documentation - The building-a-malware-lab, unpacking-basics, and dynamic-analysis-sandboxing skills - MITRE ATT&CK (capa maps to it) ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.