A suspicious attachment lands in a shared mailbox. You have the file, a hash, and maybe twenty minutes before someone asks whether it is worth escalating. Do you open it in a disassembler, or drop it into a sandbox and watch what it does? The question is slightly wrong. Static and dynamic analysis answer different questions, and the quickest analysts switch between them instead of picking a side.
Static analysis: reading the file cold
Static analysis means examining a sample without executing it. You start with the basics that take seconds: file type, size, hashes, and whether the file is signed. From there you can walk the PE headers, look at section names and entropy, and dump strings to spot URLs, registry paths, ransom note fragments, or the function names of a known packer.
Imports are especially telling. A tiny executable that imports CreateProcess, WriteFile, and WinHttpSendRequest but almost nothing else is sketching out a story for you. Embedded resources, overlay data, and oddly large sections often hide a second-stage payload or a configuration blob, sometimes lightly obfuscated with a simple XOR key you can recover in a few minutes.
Its strengths are speed, safety, and scale. Nothing runs, so nothing can escape; you can triage thousands of files with automated extraction and YARA rules on a modest machine. Its weakness is that anything obfuscated, packed, or encrypted will simply refuse to talk. Static analysis also cannot tell you what a sample did on the one host that got hit last Tuesday.
Dynamic analysis: letting it run and watching
Dynamic analysis executes the sample in an instrumented environment and records what happens. That environment should be a disposable virtual machine: snapshotted before the run, isolated from production, with no shared folders, no clipboard sharing, and network access either simulated or tightly controlled.
What you are looking for is behavior. A dropper might write a file to a temporary directory, register a scheduled task, add a Run key, and then reach out to an address over HTTPS. Memory instrumentation catches code that was packed on disk but unpacked in RAM. A full memory dump often gives you a clean copy of the payload plus its configuration, which is exactly what static analysis could not reach.
Dynamic analysis produces IOCs you can act on immediately: domains, IP addresses, file paths, mutexes, registry keys. It also produces false comfort. A sample that sleeps for ten minutes, checks whether it is running in a VM, or waits for a specific command from its operator may show you nothing at all during a five-minute run.
What each approach answers best
- Static: What is this file, how was it built, and does it resemble something we already know?
- Static: Are there embedded URLs, keys, or staged payloads I can extract without risk?
- Static: Can I write a detection rule for a distinctive byte sequence or string?
- Dynamic: What did it actually do — which processes, files, keys, and network destinations?
- Dynamic: What does the unpacked payload look like once it is running in memory?
- Dynamic: How does it behave when it thinks nobody is watching closely?
Neither column is optional. Static without dynamic leaves you guessing at intent; dynamic without static leaves you with a pile of telemetry and no structure.
A triage workflow that uses both
- Hash and reputation first. Before opening anything, check the hash and filename against internal and public reputation sources. A known-good signed installer ends the ticket.
- Run the cheap static pass. File type, strings, imports, section entropy, embedded resources, and your YARA ruleset. Automate this so it costs you nothing.
- Make a call. If the file is clearly benign or clearly a known family, stop and document. If it is ambiguous, packed, or script-based, move to execution.
- Detonate in an isolated VM. Snapshot first, keep the network contained, and capture process, file, registry, and network activity. Give it longer than feels necessary.
- Pivot back to static with new data. Feed the memory dump, dropped files, and extracted config back into your static tools. This is where packed samples finally become readable.
- Write detection, not just notes. Turn the behavior and the artifacts into rules and hunting queries while the details are fresh.
Rule of thumb: if a sandbox run is clean and the static profile still looks hostile, trust the static profile and dig further.
Traps worth avoiding
A clean sandbox run is not a verdict
Absence of behavior is evidence about your environment, not the sample. Check for long sleeps, VM detection artifacts, and missing dependencies such as a live command-and-control server or a specific document viewer.
Strings lie, structure rarely does
Attackers plant decoy strings and fake compiler metadata. Correlate what you read with what the binary imports and how its sections are laid out.
Containment comes before curiosity
Only analyze samples you are authorized to handle, on hardware and networks that can be wiped. A second machine for static work and a separate host for detonation keeps a bad day from becoming a bad week. If a sample touches personal data or raises legal questions about handling, involve the right people on your side before proceeding.
Make it a loop, not a rivalry
The two techniques feed each other. Static work tells you what to watch for during execution and gives you a baseline of imports, strings, and structure. The run tells you which of those clues mattered, and hands you unpacked code to read properly. Analysts who treat this as a loop get faster with every sample: the static pass gets sharper because they know what behavior tends to follow, and the dynamic run gets more targeted because they already know what the file is pretending to be.
Start with the cheapest question you can answer, escalate only as far as the evidence demands, and always finish by writing down what you found in a form a detection rule can use.
Photo: ApexDigitalAgency / Pixabay
