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.