Dynamic analysis: detonating safely
Run a malware sample inside a sealed, instrumented lab to watch what it actually does — dropped files, persistence, injection, and network callbacks — extract the IOCs, then revert the snapshot every single time.
Dynamic analysis is running a suspicious sample inside a controlled, isolated environment and watching what it actually does — the files it drops, the keys it writes, the processes it spawns, and the servers it tries to reach. Where static analysis reads the code, dynamic analysis observes behaviour, which is often faster at revealing intent and far harder for an author to hide completely.
Build the isolated lab first
Never run malware anywhere it can touch something you care about. The standard setup is a disposable virtual machine on a host-only network, with a second VM or tool acting as a fake internet so the sample gets convincing replies without ever reaching the real one. Take a clean snapshot before you begin so you can roll back in seconds.
- A dedicated analysis VM with no shared folders, no shared clipboard, and no USB pass-through to the host.
- Host-only networking — the sample must have no route to your LAN or the real internet.
- A simulated internet: INetSim or FakeNet-NG to answer DNS, HTTP/S, SMTP and more with fake responses.
- A clean snapshot captured immediately before detonation, so every run starts from an identical state.
Only detonate samples on assets you own or are explicitly authorised to analyse, and never on a network you care about. A single misconfigured adapter can let live malware call home, scan your LAN, or spread — treat isolation as the one setting you verify twice before every run.
Instrument before you detonate
- Procmon (Process Monitor) — every file, registry, and process operation, filtered down to your sample's process tree.
- Process Hacker or Process Explorer — child processes, injected threads, and memory regions that hint at process injection.
- Wireshark plus the fake DNS/HTTP server — captures C2 beacons, requested domains, and user-agents without any real callout.
- Autoruns — diff persistence locations (Run keys, services, scheduled tasks) before and after the run.
Detonate, then read the behaviour
Arm your captures at the clean snapshot, run the sample, let it act for a few minutes, then stop recording and reconstruct what happened. You are building an evidence trail, not just a verdict. Focus on:
- Dropped files — new executables, DLLs, or scripts written to
%APPDATA%,%TEMP%, orProgramData. - Persistence —
Run/RunOncekeys, new scheduled tasks, or newly registered services. - Process injection — a benign process such as
explorer.exeorsvchost.exesuddenly hosting the payload's threads. - Network indicators — contacted domains, IPs, URIs, and distinctive user-agent strings for your IOC list.
- Anti-analysis behaviour — long
Sleepcalls, checks for VM artefacts, or debugger detection that stalls execution.
# Fake internet on the analysis gateway VM (Linux): fake DNS, HTTP/S, SMTP, FTP
sudo inetsim
# All-in-one alternative run on the Windows victim VM itself
# redirects all traffic to local listeners and logs it to a pcap
fakenet.exe
# After the run, pull network IOCs straight from the capture
tshark -r capture.pcapng -Y "dns" -T fields -e dns.qry.name | sort -u
tshark -r capture.pcapng -Y "http.request" -T fields -e http.host -e http.user_agent | sort -uFor a fast first pass, submit the sample to an automated sandbox like any.run, Cuckoo/CAPE, or Joe Sandbox — they run it, record behaviour, and extract IOCs in minutes. Two caveats. First, public submissions (any.run's free tier especially) can expose the sample and its filename to anyone and tip off the author, so keep sensitive or targeted samples on a self-hosted sandbox such as CAPE. Second, treat any verdict as a lead, not gospel: evasive malware often fingerprints sandboxes and stays dormant, so a 'clean' automated report never overrides your own manual run.
The deliverable: revert every time
The output of dynamic analysis is a set of IOCs (domains, IPs, hashes, file paths, registry keys) plus a plain-language behaviour summary a defender can act on. The moment you have extracted it, revert the snapshot — every run must start from a known-clean state, because a reused VM may still be infected and will quietly contaminate your next result.