/analyzing-malware

name: analyzing-malware
description: Analyze suspected malware safely — containment, static triage, sandboxed detonation, unpacking, capability and C2 extraction, IOC production, and YARA rule authoring. Use when handed a suspicious file, hash, or sample, when triaging an alert artifact, or when producing detection content from a specimen.
verified: 2026-07-27

Analyzing Malware

The analysis is the easy part. The part that goes wrong is containment: a sample detonated on a machine that can reach production, or an IOC published that burns an active investigation. Get the environment right first.

When to Use

• Triaging a suspicious file, attachment, script, or dropped binary
• Determining a sample's capability, persistence, and command-and-control
• Extracting indicators for hunting and blocking
• Writing YARA or behavioural detection from a specimen
• Supporting an incident with sample-derived intelligence

When NOT to Use

• **Writing malware, droppers, loaders, or evasion code** — out of scope for

this skill regardless of framing

• **Pure RE of a benign binary** — use `analyzing-binaries`
• **A raw shellcode blob with no PE/ELF header** — use `analyzing-shellcode`
• **The sample's network capture** — use `analyzing-network-traffic`
• **Sweeping a whole web source tree for planted webshells** (not one recovered

sample) — use `hunting-web-backdoors`

• **Writing a YARA signature for the family** — use `writing-yara-rules`
• **The wider incident** — use `responding-to-incidents`
• **Turning findings into deployed rules** — use `engineering-detections`
• **Pivoting sample IOCs into related infrastructure, actor tracking, or a

finished intel product** — use `producing-threat-intelligence`

Containment: Do This Before Anything Else

| Control | Requirement | | --- | --- | | Host | Disposable VM or dedicated bare-metal, snapshot taken before execution | | Network | Isolated segment; simulated services (INetSim/FakeNet-NG) by default | | Shares | No host folder sharing, no clipboard sharing, no mounted host drives | | Credentials | No real accounts, no domain join, no password manager | | Handling | Sample stored in a password-protected archive, extension neutered (`.bin`, `.mal`) | | Egress | Real internet only with an explicit decision and a plan for attribution leakage |

Live C2 contact tells the operator you are looking. On an active incident, do not resolve the C2 domain, submit the hash publicly, or upload the sample to a multi-scanner service until the incident lead approves it — public submission is a disclosure.

Static Triage — No Execution

# Identity, always first
sha256sum sample && file sample && du -h sample
# Fuzzy and import hashes for clustering against known families
ssdeep sample; tlsh sample   # Debian tlsh-tools ships /usr/bin/tlsh;
                             # built from upstream it is tlsh_unittest
python3 -c "import pefile;print(pefile.PE('sample').get_imphash())"

# Structure
pecheck sample                  # or: rabin2 -I / readelf -h
capa -v sample                  # capability detection mapped to ATT&CK — start here
floss sample                    # deobfuscated + stack strings, better than `strings`

# Packing and embedded content
binwalk -E sample               # entropy
binwalk -Me sample              # extract embedded objects

`capa` is the highest-value single command in this workflow: it turns a binary into a list of behaviours mapped to MITRE ATT&CK and MBC, which tells you whether deeper analysis is warranted at all.

**Document-borne and script-borne samples:**

oleid doc.xls && olevba --deobf doc.xls        # OLE macros
oledump.py doc.doc                              # stream-level inspection
msodde doc.docx                                 # DDE payloads
rtfobj doc.rtf                                  # embedded objects in RTF
pdfid file.pdf && pdf-parser -a file.pdf        # /JS /OpenAction /Launch

# Obfuscated scripts: normalize before reading
box-js payload.js
# PowerShell: decode -EncodedCommand, then unwrap the layers
echo '<base64>' | base64 -d | iconv -f UTF-16LE -t UTF-8

Most script malware is three layers of encoding around ten lines of logic. Deobfuscate mechanically rather than reading the obfuscated form.

Dynamic Analysis

Snapshot, detonate, observe, revert. Never analyze twice from a dirty state.

Baseline snapshot
  → start Procmon / Sysmon / inotify + tcpdump + INetSim
  → detonate with the right launcher (rundll32, wscript, mshta, Office)
  → observe 3-5 minutes, then interact (click, wait past sleep timers)
  → collect artifacts and memory
  → revert

What to collect and what each answers:

| Artifact | Tool | Answers | | --- | --- | --- | | Process tree | Sysmon E1, Procmon, `execsnoop` | Injection, LOLBin abuse, child spawns | | File and registry writes | Procmon, `inotifywait` | Drops, persistence, config | | Network | `tcpdump`, Wireshark, INetSim logs, mitmproxy | C2 endpoints, beacon interval, protocol | | Memory | DumpIt / `procdump`, then Volatility | Unpacked payload, injected code, keys | | Persistence | Autoruns, `systemctl list-units`, cron, LaunchAgents | Survival mechanism |

**Recover the unpacked payload from memory** rather than fighting the packer:

# After the sample unpacks itself, dump and carve
vol -f mem.raw windows.malfind          # injected/RWX regions
vol -f mem.raw windows.dumpfiles --pid <pid>

Watch for **sleep and evasion gates**: many samples idle for minutes, check for a domain-joined host, count CPU cores, or look for analysis processes. If nothing happens, patch the check or hook `Sleep`/`NtDelayExecution` with Frida before concluding the sample is inert.

Capability Model

Structure findings against ATT&CK rather than as a narrative:

• **Initial execution** — how it was launched, what it needed
• **Defense evasion** — packing, injection, AMSI/ETW patching, signed-binary proxying
• **Persistence** — run keys, services