Dynamic Analysis Basics
Static reading only takes you so far; sometimes you have to let it run and watch what it touches.
What you will learn
- -Instrument a lab VM to record process, file, registry, and network activity
- -Detonate a sample and read its behavior from your monitoring tools
- -Fake internet so the malware reveals its command-and-control intent
A can hide every string and import from , but the moment the sample runs, it has to unpack itself in memory, drop its files, and reach for its . is watching all of that happen. You run the sample in an instrumented VM and record what it does: which processes it spawns, which files and keys it writes, which it tries to reach. The catch is that you only this data if your monitoring is running before you double-click, not after.
Set up the watchers first. Detonate second. If you launch the sample and then scramble to start Procmon, you've already missed the 's first move.
The monitoring stack
On a Windows analysis VM, four free tools from the Sysinternals suite plus a sniffer cover most of what you need.
- Process Monitor (Procmon) every file, registry, and process operation in real time. It's noisy, so you filter hard.
- Process Explorer shows the live process tree, so you see what spawned what.
- Autoruns lists every location, which you diff before and after to catch what the sample added.
- Wireshark or
tcpdumpcaptures the network traffic the sample generates.
Start Procmon, then immediately set a filter to include only your sample's process name and its children. Without that filter you're staring at 50,000 events a second of normal Windows chatter. Filter first, then run.
$Procmon.exe /BackingFile C:\\analysis\\run1.pmlFake the internet so the sample talks
If the VM has no network, the tries to reach its C2, gets nothing, and often just exits or sleeps. You learn little. The fix is a fake internet: a second VM on a host-only network running INetSim or FakeDNS, which answers every query and serves fake , FTP, and SMTP responses. The malware thinks it reached its , and you capture the it asked for and the exact request it sent.
$sudo inetsim --config /etc/inetsim/inetsim.conf$sudo tcpdump -i eth0 -w /root/run1.pcapPoint the analysis VM's DNS at the INetSim box, keep both machines on the same host-only network, and make sure that network has no route to the real internet. Now when the sample resolves evil-c2-domain.top and POSTs a , you've got the domain, the URI, the , and the , all without ever giving it a real path out.
A fake internet only helps if the real one is unreachable. Confirm the analysis segment has no default route before you run anything. If you let the sample reach the actual internet, you may the operator, pull down a live second-stage payload, or become a in someone's . Verify isolation every session, not just the day you built the lab.
Read the behavior
After a run of 60 to 120 seconds, revert the VM and read your captures on the host. Line up three sources: Procmon for local activity, Autoruns diff for persistence, and the pcap for network.
The story usually reads like this. The sample writes a copy of itself to %APPDATA% or C:\ProgramData, adds a HKCU\...\Run key or a scheduled task pointing at that copy, spawns a child process (often cmd.exe or powershell.exe), then makes a DNS query and an HTTP to its C2. Each of those is an indicator you write down: the dropped file path and its hash, the persistence key, the process lineage, and the domain plus URI it beaconed to.
$strings run1.pcap | grep -iE 'host:|user-agent:|post |get 'In your isolated lab, start Procmon with a filter on your sample's process name, start a tcpdump capture on the analysis segment, then detonate a known test sample for 90 seconds. Afterward, list three concrete indicators you observed: one file or registry write, one process the sample spawned, and one network destination it tried to reach.
Why must you start Procmon and your packet capture before running the sample rather than after?