A sample lands on your desk at 2 a.m. A ZIP pulled from a phishing report, or a hash your EDR flagged on a finance workstation. Do you load it into a disassembler or detonate it in a lab VM? The framing is usually wrong. Static and dynamic analysis aren't competing methods; they answer different questions, and good analysts bounce between them constantly. The trick is knowing which one gives you the answer you need right now.

What Static Analysis Actually Gets You

Static analysis treats the file as data: bytes, structure, strings, code. Nothing executes. That makes it cheap, safe, and scriptable, which is why it scales to thousands of samples without a lab.

• Identity and metadata: hashes for pivoting, compile timestamps, file size, whether the binary is signed and by whom.
• Structure: PE headers, section table and per-section entropy, imports and exports, embedded resources, the manifest.
• Strings: URLs, IP addresses, registry paths, mutex names, user agents, error messages, and occasionally a PDB path that leaks the build directory.
• Code: decompiled functions, control flow, crypto constants, hardcoded keys, and the logic that ties it all together.

A few habits separate a fast read from a slow one. Run strings with a minimum length (-n 8) to cut noise, and remember Windows binaries need UTF-16 extraction, so add the -el flag or use a dedicated tool. High entropy in one section plus a nearly empty import table, often just LoadLibrary and GetProcAddress, is the classic packed-sample signature; stop reading and pivot. Timestamps deserve caution too: a compile date far from the file's creation date, or a path like C:\Users\dev\Desktop\build, tells you something about the builder, not the campaign. For encrypted string tables, tools such as FLOSS attempt automatic recovery; otherwise you're reading the decryption routine yourself, which is often the most valuable ten minutes you'll spend.

Where Static Analysis Falls Short

Modern malware is built to make reading useless. Once a sample is packed, the code you see is a stub, and the real payload only exists after unpacking in memory. Configuration frequently doesn't live in the file at all: C2 domains, campaign identifiers, and encryption keys arrive from the server after the first callback. You can stare at a clean import table for an hour and learn nothing about where the sample phones home.

Scale is the other problem. A 90 MB Go binary or a .NET assembly with a thousand generated methods will consume an afternoon. And plenty of behavior simply isn't visible statically — which process got injected into, what files were dropped, whether the sample checked for a virtual machine before doing anything at all. Reading code is inference. You can be confident a routine decrypts a string, but not that it's ever called, or with what input.

What Dynamic Analysis Adds

Dynamic analysis runs the sample in a controlled environment and records what it does. Instead of guessing intent, you observe behavior:

• Process activity: a Word document spawning powershell.exe, rundll32, wscript, or mshta; injection into explorer.exe; full command lines.
• File system: dropped payloads, ransom notes, renamed documents, staging in %TEMP% or %APPDATA%.
• Persistence: Run keys, new services, scheduled tasks, WMI subscriptions, startup folder shortcuts.
• Network: DNS queries, HTTP requests, TLS SNI values, beacon intervals, uploaded data, and the infrastructure static analysis couldn't see.
• Anti-analysis behavior: long sleeps, debugger checks, sandbox usernames, hardware fingerprints, a hardcoded list of AV product names.

Managed sandboxes handle most of this automatically. For anything unusual, an instrumented VM with Procmon, Wireshark, and a simulated internet service gives you a much cleaner picture.

Sandbox Limits and Evasion

Sandboxes are fast, but they're predictable, and malware authors know exactly how they work. Common tricks include sleeping for several minutes before doing anything interesting, waiting for a specific date or an operator command, requiring a human to click through dialogs, or refusing to run unless the right parent process or a file from the victim's machine is present.

That means "no activity" is not proof of anything. Adjust the environment and run it again: longer timeouts, a newer Windows build, interactive clicking, patched sleep calls. Keep the lab genuinely isolated while you do it — host-only networking or a simulated internet, no shared folders, no clipboard sharing, snapshots before every run, and never on the machine you use for email or browsing.

Building a Combined Workflow

The two approaches feed each other, and the real gains come from the loop between them:

1. Triage statically. Hash it, identify the file type, read the headers and imports, pull strings. If it's a packed dropper, note that and move on. Cost: seconds per sample.
2. Run it dynamically if it's unfamiliar or the static picture is incomplete. Capture a baseline of the clean VM first so you can subtract normal noise later.
3. Take runtime artifacts back to the disassembler. This is where cases get solved. You saw a domain in the PCAP, so find the routine that builds it. You saw a DLL loaded from disk, so locate the LoadLibrary call. You watched a 30-second loop, so check whether it's a beacon and what it sends.
4. Verify, don't assume. If you think you've found a persistence mechanism, confirm it in the runtime log. Dynamic output is noisy — legitimate installers write hundreds of registry values — so separate signal from setup scaffolding.
5. Document as you go: hashes, IOCs, a short timeline, and the reasoning that connects observation to conclusion.

Putting It Into Practice

If you're triaging thousands of files, static comes first because it's the only thing that scales. If you have one sample and the question is "what does this do to a host?", run it. If you're writing detections, you need both: static artifacts for file-based rules and process lineage, dynamic behavior for network and registry logic. Neither is a substitute for the other, and a sample that looks harmless in one view often looks very different in the other.

A few habits matter more than tool choice. Always record the environment alongside the results, because a screenshot of a beacon proves little if you can't say what else was running in that VM. Re-run ambiguous samples after tweaking timeouts, and treat every conclusion as provisional until a second method agrees with it.

Where formal incident response, evidence handling, or regulatory notification is involved, follow your organization's procedures and bring in someone qualified rather than improvising.

Photo: Yan Krukau / Pexels