Malware Analysis Fundamentals: From Sample to Indicators in 60 Minutes
Most analysts encounter a suspicious file before they encounter a reverse engineer. The binary landed in a phishing attachment, EDR flagged something on a workstation, or a threat feed dropped a hash that matched an internal system. The question is always the same: what does this thing actually do? Full reverse engineering — disassembly, decompilation, manual code analysis — takes hours and requires deep expertise. But extracting actionable indicators takes sixty minutes and a handful of free tools. This post covers the workflow every security analyst should own before calling in a specialist.
Static vs Dynamic Analysis: When to Use Each
Static analysis examines a file without executing it. You look at structure, strings, metadata, and code — nothing runs on your machine. Dynamic analysis executes the sample in a controlled environment and watches what it does: network connections it makes, files it writes, registry keys it touches, processes it spawns.
Static is safer and faster. It will not detonate a payload, trigger a C2 callback, or cause collateral damage. Start here to understand what you are dealing with before you run anything.
Dynamic catches what static misses. Packed or obfuscated samples reveal almost nothing from static inspection. When the binary unpacks itself in memory and executes, dynamic analysis captures the real behavior.
The golden rule: never run a malware sample on bare metal. Always use an isolated VM with no shared folders, no clipboard integration, and no network access to production resources. Snapshots before detonation, rollback after. A sample escaping to your analysis workstation or pivoting to internal systems is an incident inside your incident.
Static Analysis: Tools and What They Reveal
Start with basic file identification. Malware frequently ships with a misleading extension or no extension at all.
# Identify true file type regardless of extension
file suspicious.bin
# Compute hashes for threat intelligence lookups
md5sum suspicious.bin
sha256sum suspicious.bin
strings extracts printable character sequences — URLs, IP addresses, registry paths, function names, error messages, and hardcoded credentials all appear here before you open a disassembler.
# Extract strings of minimum 8 characters, both ASCII and Unicode
strings -n 8 suspicious.bin
strings -n 8 -e l suspicious.bin # Unicode (little-endian)
# Grep for common IOC patterns immediately
strings suspicious.bin | grep -E "(https?://|[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|HKEY_)"
exiftool reads embedded metadata. Office documents often expose author names, template paths, and creation timestamps that tie a sample to a campaign or infrastructure.
exiftool suspicious.docm
pestudio (Windows) is the single best starting point for PE analysis. It scores strings by risk, maps imports and exports, identifies suspicious sections, checks against VirusTotal, and highlights anomalies — all in one pane. For Linux analysts, pefile in Python covers the same ground programmatically.
import pefile
pe = pefile.PE("suspicious.bin")
for entry in pe.DIRECTORY_ENTRY_IMPORT:
print(entry.dll.decode())
for imp in entry.imports:
print(" ", imp.name)
YARA lets you write pattern-matching rules against file content. When you have a known malware family, a community rule set catches variants without any tool running the sample.
# Scan with a YARA rule file
yara -r malware_rules.yar /path/to/samples/
# Quick rule to find samples with suspicious import combinations
# rule SuspiciousImports { strings: $a = "VirtualAlloc" $b = "WriteProcessMemory" condition: all of them }
Unpacking: Getting Past Obfuscation
Packers compress or encrypt the original code and wrap it in a stub that unpacks at runtime. Static strings analysis on a packed sample returns almost nothing useful — you see the packer stub, not the payload.
Detect It Easy (DIE) identifies the packer or compiler used. This single step tells you whether static analysis is going to be productive or whether you need dynamic techniques.
die suspicious.bin
# Output: PE64, Packed: UPX 3.96
Common packers like UPX can be unpacked trivially:
upx -d suspicious.bin -o unpacked.bin
strings unpacked.bin | grep -E "(https?://|cmd.exe|powershell)"
Custom packers require dynamic analysis to catch the moment the real payload is written to memory.
Dynamic Analysis Setup
FlareVM (Windows) and REMnux (Linux) are purpose-built analysis distributions. FlareVM installs on a Windows VM and adds every analysis tool you need. REMnux is a Linux distribution focused on analyzing artifacts collected from Windows systems.
Inside your isolated VM, configure four tools before detonation:
- Process Monitor (procmon): Captures every file system, registry, and process/thread event in real time. Apply filters to reduce noise before starting capture.
- Wireshark: Capture all network traffic with a filter for the analysis VM’s IP. You will see DNS queries, HTTP requests, and any C2 traffic the sample generates.
- Regshot: Takes a registry snapshot before and after execution. The diff shows every key created, modified, or deleted — persistence mechanisms appear immediately.
- FakeNet-NG: Simulates common network services (DNS, HTTP, SMTP) inside the VM so network-dependent malware executes its full routine even without real internet access.
# On REMnux: capture all traffic from the Windows analysis VM
tcpdump -i eth0 host 192.168.56.101 -w /captures/malware_run1.pcap
Behavioral Analysis: What to Watch
During execution, focus on four categories:
Network connections: What domains does it resolve? What IPs does it connect to? What ports? C2 beacons often have regular intervals and fixed packet sizes. Note User-Agent strings — many families use hardcoded or malformed values.
File writes: Malware dropping a second-stage payload writes a file. Common locations: %TEMP%, %APPDATA%, C:\Windows\System32, or root of C:. Unexpected writes to startup folders indicate persistence.
Registry modifications: Watch for writes to HKLM\Software\Microsoft\Windows\CurrentVersion\Run and equivalent HKCU keys. These are the classic persistence locations. Also watch for COM hijacking attempts and service installations.
Process spawning: A Word document that spawns cmd.exe, powershell.exe, or wscript.exe is executing code. A process injecting into svchost.exe or explorer.exe is attempting to hide. Process Monitor’s process tree view makes parent-child relationships immediately visible.
Extracting IOCs
After static and dynamic analysis, compile your indicators of compromise:
File Hashes:
MD5: d41d8cd98f00b204e9800998ecf8427e
SHA256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Network:
IPs: 203.0.113.45, 198.51.100.12
Domains: update.maliciousdomain[.]com
URLs: hxxps://update.maliciousdomain[.]com/gate.php
Host:
File: C:\Users\Public\svchost32.exe
Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdate
Mutex: Global\{A1B2C3D4-E5F6-7890-ABCD-EF1234567890}
Service: WindowsUpdateSvc
Mutex names are particularly valuable — they are how malware prevents double-infection, and they are unique per family or campaign. A mutex IOC produces very low false positives.
Sandboxing: Automated First Pass
Before any manual work, submit the hash to VirusTotal and run the sample through an automated sandbox. ANY.RUN provides an interactive sandbox where you can watch execution in real time, click through dialogs, and see process trees, network connections, and dropped files annotated automatically. Cuckoo Sandbox is the open-source option you can self-host — useful for sensitive samples that should not leave your environment.
Sandboxes miss evasive samples that detect VM artifacts, delay execution, or require specific environmental conditions. Treat sandbox output as a starting point, not a conclusion.
Writing a Malware Report
A useful malware report has two parts that serve two audiences.
Executive summary (three to five sentences): What is the malware family if known? How does it arrive? What is the business impact — credential theft, ransomware, lateral movement capability? What is the recommended action?
Technical indicators section: Structured IOCs in a format your SIEM and EDR can consume directly. Include hashes, network indicators with defanged notation (hxxps://, [.]), host-based artifacts, and YARA rules if you authored any during analysis. Timestamp your analysis environment details — OS version, tool versions — so the report can be reproduced.
The goal is not to write a paper. The goal is to give every analyst on your team and every detection tool in your stack everything they need to find and stop this sample in the next sixty minutes.
OpenArmor’s open-source tooling integrates malware analysis workflows directly into detection pipelines — automating IOC extraction, enriching indicators against threat feeds, and pushing detections to connected SIEM and EDR platforms. The analysis fundamentals here remain manual by design: understanding what the tools do underneath is what separates an analyst who can adapt when automation fails from one who cannot.