Module 5 · Malware Triage

Last updated: April 29, 2026

When an alert fires and the SOC ends up holding a suspicious binary — extracted from a phishing attachment, pulled off an infected endpoint, or flagged by EDR — somebody has to decide quickly: is this actually malicious, what does it do, and how bad is the exposure? That is malware triage. Not full reverse engineering (that takes days per sample) but a fast, structured assessment that answers the operational questions in under 30 minutes. This module walks through static triage, behavioural triage in a sandbox, the tools that matter, and the decision points that mark when to escalate to a dedicated reverse engineer.

Triage vs reverse engineering

Reverse engineering is a deep discipline: disassembly, control-flow graphs, identifying crypto constants, recovering C2 protocol. It is expensive and slow. Triage is the fast first-pass that determines whether reverse engineering is worth doing, and extracts actionable indicators (IPs, domains, hashes, filenames, registry keys) so the SOC can hunt for other affected hosts while the RE work proceeds.

Triage answers: “Is it malicious? What family? What does it do at a high level? What indicators do we hunt on right now?”

Safety first — the workspace

Never open a sample on your workstation. Never. The setup:

• Isolated VM — Flare-VM or REMnux image, snapshotted clean. Revert after each sample
• Host-only networking or NAT’d to an internet-simulated environment (INetSim, FakeNet). Never your production network
• No sensitive data on the analysis host — no corporate credentials, no VPN profiles, no browser sessions
• Separate email for vendor sandbox submissions — VirusTotal, Hybrid Analysis, Joe Sandbox
• Password-protected ZIPs when storing or sharing samples (convention: password is infected)

Before any hands-on work, acknowledge that the sample may exhibit anti-analysis behaviour: sandbox detection, timestamp checks, VM-fingerprinting. A tidy-looking benign result can be a decoy.

Phase 1 — Hash and lookup

First and cheapest step:

# Hash it
sha256sum sample.exe
md5sum sample.exe

# Look up on VirusTotal (hash-only, does not upload)
# API: GET https://www.virustotal.com/api/v3/files/{sha256}

A VirusTotal hit with 20+ engine detections and a recent first-seen date ends triage immediately: it is known malicious, pull the family name, extract IOCs, hunt. If no hit — continue.

Do not upload samples to public sandboxes by default. Uploads go into vendor corpora and are visible to threat actors who monitor them. Many APTs specifically watch VirusTotal for their own implants to detect that a victim is investigating. Use hash-only lookups until you have decided the sample is not targeted, or use a private sandbox tier.

Phase 2 — Static triage

Static analysis looks at the file without running it. Fast, safe, and often decisive.

File type identification

file sample.bin
# sample.bin: PE32 executable (GUI) Intel 80386, for MS Windows

# Or in Python
pip install pefile
python -c "import pefile; p=pefile.PE('sample.exe'); print(p.OPTIONAL_HEADER.SizeOfImage)"

Strings

The single highest-signal static check. Prints human-readable strings embedded in the binary:

strings -n 8 sample.exe | less        # ASCII only
strings -el -n 8 sample.exe | less    # little-endian Unicode (common on Windows)

# What to look for:
# - URLs / IPs / domains (C2 candidates)
# - Registry paths (persistence hints)
# - Process names (target injection candidates)
# - User-Agent strings (HTTP-based malware)
# - Command-line flags (CLI-driven tooling)
# - Error messages in foreign languages (origin hints)
# - Crypto constants ("AES", "RC4", hardcoded keys)
# - Specific AV product names (AV-aware malware)

Heavily obfuscated samples show few strings. That itself is a signal — legitimate software usually leaks lots of strings from linked libraries.

Entropy and packers

High entropy in a PE section often indicates packing or encryption. Check with pefile or detect-it-easy:

die -info sample.exe
# PE32
# Compiler: Microsoft Visual C/C++(2019)[-]
# Packer: UPX(3.96)[NRV,brute]

# Entropy per section (7.0+ = likely packed/encrypted)
python -c "import pefile; p=pefile.PE('sample.exe'); [print(s.Name, s.get_entropy()) for s in p.sections]"

UPX is trivially unpackable (upx -d sample.exe). Custom packers require more work — note as signal, re-examine strings on the unpacked binary.

Imports and sections

The Import Address Table (IAT) shows Windows APIs the binary declares intent to use:

pedump --imports sample.exe
# or CFF Explorer / PE-bear GUI

# Red-flag API combinations:
# - VirtualAllocEx + WriteProcessMemory + CreateRemoteThread (process injection)
# - CryptAcquireContext + CryptEncrypt (encryption — ransomware candidate)
# - WinINet APIs (HTTP C2)
# - WS2_32.dll + socket + connect (raw networking)
# - AdjustTokenPrivileges (privilege manipulation)
# - SetWindowsHookEx (keylogging)
# - SfcIsFileProtected / NtQueryInformationProcess (sandbox/AV evasion)

A heavily-suspicious IAT combined with benign-looking metadata is a strong positive signal.

YARA scanning

YARA rules match patterns (bytes, strings, regex) in files. Run your ruleset plus public rule repos against the sample:

yara -r rules/ sample.exe
yara -r ~/yararules-community/ sample.exe

# Good public rulesets:
# - Yara-Rules/rules (github)
# - Florian Roth's signature-base
# - Elastic/protections-artifacts

A YARA hit from a reputable rule gives you family attribution in seconds, which jumps you straight to IOC extraction from threat intel.

Phase 3 — Behavioural triage in a sandbox

When static signals are ambiguous or you need dynamic IOCs (C2 URLs generated at runtime, mutex names, registry keys written), run the sample in a sandbox.

Public sandboxes

• Hybrid Analysis (hybrid-analysis.com) — CrowdStrike-operated; free tier with reasonable reports
• Joe Sandbox (joesandbox.com) — strong detection, paid for private
• ANY.RUN (any.run) — interactive sandbox, great for user-interaction-dependent malware
• Cuckoo Sandbox / CAPE — self-hosted, full control, more effort to maintain

Choose based on sensitivity. Targeted-looking samples → private tier or self-hosted only. Commodity-looking → public tier is usually fine.

What a sandbox report gives you

• Process tree — what child processes the sample spawns
• File operations — files created, modified, deleted. Persistence artifacts
• Registry operations — keys written. Run keys, service keys, COM hijacks
• Network — DNS queries, HTTP requests, TLS SNIs, raw IPs contacted
• Process injection — if the sample injected into other processes
• Mutexes created — family attribution signal for known families
• Dropped files — secondary payloads; triage them as well

Local sandboxing with REMnux + FakeNet

For sensitive samples, a local setup:

1. Windows VM (clean snapshot) with sample
2. REMnux VM on same host-only network acting as gateway
3. REMnux runs FakeNet-NG — responds to DNS, HTTP, HTTPS, FTP as if the internet were present. Captures every request
4. Run sample; let it make requests; capture with Wireshark on REMnux
5. Revert VMs after

This gives you the full network behaviour without any traffic leaving your environment and without alerting the attacker via real-network hits to their infrastructure.

Extracting IOCs for hunting

Triage outputs a short list of indicators the SOC can hunt for immediately:

• File hashes — MD5, SHA1, SHA256 of the sample and any dropped files
• Network indicators — domains, URLs, IP addresses, TLS certificates
• Host indicators — file paths written, registry keys created, mutex names, service names, scheduled task names
• Process indicators — specific parent-child patterns, command-line strings
• User-Agent strings — distinctive HTTP patterns

Package these in STIX or a simple Markdown IOC list. Hand to the SIEM team for retroactive search across 90 days of logs. If any other host shows the same IOCs, the incident just got bigger — you found lateral spread during triage.

Family attribution and why it matters

“It is Emotet” or “Qakbot” or “IcedID” tells you:

• What it typically does post-infection (drops Cobalt Strike, credential theft, lateral movement)
• Known TTPs from threat intel reports
• Whether decryption tools exist (some ransomware families have public decryptors)
• Who is likely operating it (affiliates, specific TAs)

Don’t force attribution when signals are ambiguous. “Unknown, probably a Rust-written infostealer based on API usage and strings” is a valid triage output. “Medusa ransomware” without strong evidence is worse than “unknown” because the SOC will anchor on it.

The 30-minute triage flow

T+0   Acquire sample into isolated VM. Hash it.
T+2   VirusTotal hash lookup. If strong hit → skip to IOC extraction (T+20).
T+5   file, strings (ASCII + Unicode), entropy/packer check.
T+10  IAT review. YARA scan.
T+15  Decide: static signals sufficient? If yes → T+20. If no → sandbox.
T+15  Submit to sandbox (public or private). Continue static work.
T+25  Review sandbox report. Extract dynamic IOCs.
T+28  Package IOCs. Family attribution (if confident).
T+30  Deliver triage brief: malicious y/n, family, high-level behaviour, IOC list,
      escalation recommendation.

If you blow through 30 minutes without a clear verdict, escalate to reverse engineering. The point of triage is speed, not completeness.

Escalation criteria — when to call a reverse engineer

• Sample is targeted (few or no VT detections, evidence of your environment in strings/configs)
• Custom protocol or encryption that hunt tools cannot match on without decoding
• Suspected supply-chain implant (signed binary with anomalous behaviour)
• Rootkit or kernel-level activity (driver loads, MBR/GPT touches)
• Anti-analysis stops sandbox cold (sample detects VM and exits cleanly)
• Exec flow depends on specific C2 response that sandbox cannot provide

For most Indian SMEs without in-house reverse engineers, escalation means “send to an RE firm or to CrowdStrike / Kroll / Mandiant under retainer.” Know the handoff process before you need it; set up retainer contracts in the calm, not mid-incident.

Tooling setup — the realistic shortlist

What to have installed on your analysis VM from day one:

• Flare-VM (Windows) or REMnux (Linux) as the base image
• PE tools: CFF Explorer, PE-bear, pefile, detect-it-easy
• Strings & hex: strings, FLOSS (floss by Mandiant — decodes obfuscated strings), HxD
• YARA + community rulesets
• Network: Wireshark, FakeNet-NG, INetSim, mitmproxy
• Disassembly: Ghidra (free, NSA-authored) for when you need to step beyond triage
• Python libraries: pefile, pycryptodome, capstone, r2pipe
• Memory: Volatility 3, for sample-dropped memory analysis

Common pitfalls

• Uploading targeted samples to VT: tips off the attacker. Hash-only until you are sure
• Running samples on your host: one mis-click and you have triaged your own infection
• Trusting sandbox “benign” verdicts: anti-analysis samples look benign in sandboxes. Combine with static
• No IOC pivot: triage ends with “it is bad” but nobody hunts. Always finish with a hunt package
• Skipping unpacking: static analysis on a packed sample finds nothing. Always unpack before concluding
• Over-attribution: one IOC match to a known family report does not prove it is that family

Closing the track

This is the fifth and final module of the Blue Team foundation track. You now have a mental model for SOC structure (M1), the SIEM plumbing that feeds it (M2), the detection rules that run in it (M3), the endpoint telemetry that powers those rules (M4), and the malware triage that runs when a rule fires on a real binary (M5). The deeper modules — memory forensics, threat hunting, full incident response — build on this foundation and are covered in the advanced tiers of the Academy.