Static Malware Analysis

Static analysis examines a malware sample without running it, making it the safe first stop of analysis: you inspect the file, its strings, imports, structure, and code to deduce what it does. It’s safe (you don’t run dangerous code) and gives a full picture, though obfuscated or packed malware (see Obfuscation and Packing) limits what’s visible without running. It’s reversing (see Static Analysis) applied to malicious samples.

Initial triage (without opening the code)

# sample identity
sha256sum sample ; md5sum sample          # hash -> search VirusTotal/MalwareBazaar
file sample                                # type (PE/ELF/script/macro document)
# reputation (don't upload if sensitive -> search only the hash)
VirusTotal, MalwareBazaar, Hybrid Analysis  (search by hash first)
# entropy (high = probably packed/encrypted)
# readable strings
strings -a sample ; strings -e l sample     # ASCII and unicode
floss sample                                # FLARE: extracts OBFUSCATED/stacked strings

FLOSS (from Mandiant) is key: much malware builds its strings at runtime so strings won’t reveal them; FLOSS extracts them statically.

Analyze a PE (Windows, the most common)

# headers, sections, imports/exports
pefile (Python) / PE-bear / CFF Explorer / PEstudio
# what to look for:
- imports (IAT): APIs it uses -> behavior
    VirtualAlloc/WriteProcessMemory/CreateRemoteThread -> code injection
    InternetOpen/WinHttp/socket -> networking (C2)
    CryptEncrypt/CryptAcquireContext -> encryption (ransomware?)
    RegSetValue/CreateService/schtasks -> persistence
- anomalous sections (high entropy, odd names, RWX) -> packing
- compilation timestamp, digital signature (valid? stolen?)
- embedded resources (another PE inside -> dropper)

The imports tell the story: a sample importing VirtualAllocEx + WriteProcessMemory + CreateRemoteThread almost certainly injects code into another process.

Decompile and read the logic

Ghidra / IDA           disassemble + pseudo-C (see rev-static)
# locate: the string/config decryption routine, the C2 logic,
#   the encryption algorithm (ransomware), the persistence
# capa.dev (Mandiant): identifies the binary's CAPABILITIES automatically
capa sample            # -> "encrypts data", "communicates over HTTP", "injects code"...

capa is very useful: it automatically maps the binary’s capabilities to MITRE ATT&CK by reading its code, giving you a summary of what it does without reading the whole disassembly.

Malicious documents and scripts

# Office with macros (VBA)
oletools: olevba sample.doc           # extract and deobfuscate VBA macros
# PDF
pdfid / pdf-parser                     # embedded JavaScript, automatic actions
# scripts
obfuscated PowerShell/JS/HTA -> deobfuscate (base64, concatenation, see mal-obfus)

Extract IOCs (static)

# from the binary/strings/decrypted config:
C2 domains/IPs/URLs, user-agents, mutexes, paths, registry keys,
file names, encryption keys, versions/campaigns

For the defense

Static analysis feeds detection: YARA rules (YARA Rules) and IOCs for the SIEM/EDR come from here.
Capabilities (capa) + imports let you classify a sample fast and prioritize the response.
Sharing IOCs/signatures with the community (threat intel) speeds up global detection.

Testing checklist

Triage: hash, file, VirusTotal/MalwareBazaar, entropy
Strings (strings + FLOSS for the obfuscated ones)
PE: imports/IAT, sections, resources (PEstudio/pefile)
Deduce behavior from imports (injection/network/crypto/persistence)
capa.dev for capabilities → MITRE ATT&CK
Decompile the key logic (Ghidra)
Documents/scripts: olevba/pdf-parser/deobfuscate
Extract IOCs → YARA rules (YARA Rules)