Malware Analysis — Part 7: Dynamic Analysis Part 1 — Behavioral Monitoring

Previous: Part 6 — Static Analysis Part 2: Strings, YARA, and IOC Extraction

What Is Dynamic Analysis?

Dynamic analysis is the process of executing malware in a controlled environment and observing its behavior in real time. Where static analysis reads the file, dynamic analysis watches it run.

This distinction matters because of the fundamental limitation of static analysis: modern malware is designed to hide from it. Packing, encryption, obfuscation, and anti-disassembly techniques all make static analysis harder or impossible. But when malware runs, it must eventually do what it was designed to do — and when it does, your monitoring tools capture everything.

Dynamic analysis can reveal:

• Files created, modified, or deleted
• Registry keys written (persistence, configuration)
• Processes spawned (child processes, injected processes)
• Network connections attempted (C2 check-ins, data exfiltration)
• Mutex names created (single-instance enforcement)
• Services installed (persistence)
• Memory modifications (injection into other processes)
• Anti-analysis behaviors (VM detection, sleep calls)

The Tradeoffs

Dynamic analysis has limitations you must understand:

Environment-dependent behavior: Malware can detect it's running in a VM (missing registry keys, too little RAM, VM-specific processes) and go dormant. A sample that does nothing in your VM might do everything on a victim's machine.

Time-based triggers: Some malware is configured to activate only on specific dates, after a delay, or only after receiving a command from a C2 server that you're not connected to.

Configuration-dependent behavior: Many malware families receive their configuration from the C2 server. Without a live C2, they might show only initial beaconing behavior.

Only observes, doesn't explain: Dynamic analysis shows you what the malware does but not always why or how. Understanding the mechanism often requires reverse engineering (Parts 10–11).

These limitations are why static and dynamic analysis are complementary — neither alone is sufficient.

Preparing the Monitoring Stack

The most important rule in dynamic analysis: every monitoring tool must be running before the malware executes. If you start Process Monitor after the malware has already run, you've missed everything that happened at startup — which is often the most important activity (persistence installation, initial payload drop, first C2 contact).

The order of operations for every dynamic analysis session:

1. Restore FLARE-VM to baseline snapshot
2. Start INetSim on REMnux
3. Start Wireshark on REMnux (capture Internal-Lab interface)
4. Boot FLARE-VM from baseline
5. Start Process Monitor (on FLARE-VM)
6. Start Process Explorer (on FLARE-VM)
7. Take Autoruns baseline (on FLARE-VM)
8. Start TCPView (on FLARE-VM)
9. Verify DNS resolves to INetSim (ping any domain)
10. ← EXECUTE THE MALWARE HERE →
11. Observe and document for 5–15 minutes
12. Terminate the sample or let it run out
13. Take Autoruns post-execution snapshot
14. Export Process Monitor log
15. Export TCPView log
16. Save Wireshark capture (PCAP)
17. Take memory dump (for Part 9)
18. Restore FLARE-VM to baseline snapshot

This sequence ensures you capture everything the malware does from the first instruction to the last.

Tool 1 — Process Monitor (Procmon)

Process Monitor is arguably the most powerful behavioral analysis tool available for Windows. It captures every filesystem, registry, network, process, and thread event on the system in real time.

Download: Free from Microsoft Sysinternals docs.microsoft.com/sysinternals/downloads/procmon

FLARE-VM installs it automatically.

What Process Monitor Captures

Setting Up Process Monitor

When you launch Procmon, it begins capturing immediately. Before running your sample:

1. Clear the buffer: Press Ctrl+X to clear any events captured during tool startup.

2. Verify capturing is enabled: The magnifying glass icon in the toolbar should be active (blue). Press Ctrl+E to toggle.

3. Consider enabling boot logging: For malware that persists and runs at startup, you can configure Procmon to capture events before it even loads: Options → Enable Boot Logging. The log is written to disk and loaded the next time Procmon starts.

The Filtering Challenge

Process Monitor captures everything — and on a running Windows system, everything means millions of events per minute from hundreds of system processes. An unfiltered Procmon session for a 10-minute analysis generates hundreds of thousands of events that are almost impossible to analyze manually.

Effective filtering is what separates good analysts from tool-runners.

Process Monitor Filters

Access filters via Ctrl+L or Filter → Filter...

Filter by process name (most useful):

After you know which process your malware runs as (from Process Explorer), filter to show only that process:

Process Name | is | malware.exe | Include

If the malware injects into another process:

Process Name | is | svchost.exe | Include
Process Name | is | malware.exe | Include

Exclude noisy system processes:

Process Name | is | System | Exclude
Process Name | is | svchost.exe | Exclude  (if not infected)
Process Name | is | MsMpEng.exe | Exclude  (Windows Defender)
Process Name | is | SearchIndexer.exe | Exclude
Process Name | is | WmiPrvSE.exe | Exclude

Filter by path (find file drops):

Path | contains | \Temp\ | Include
Path | contains | \AppData\ | Include
Path | contains | \ProgramData\ | Include

Filter by result (find failures that indicate evasion attempts):

Result | contains | ACCESS DENIED | Include
Result | contains | NOT FOUND | Include

Malware often checks for specific files, registry keys, or processes before executing. Failed queries for things like debugger processes or VM-specific registry keys are strong indicators of anti-analysis behavior.

Reading Process Monitor Events

Each event row contains:

• Time: Timestamp with millisecond precision
• Process Name: Which process generated the event
• PID: Process ID
• Operation: What was done (CreateFile, RegSetValue, TCP Connect, etc.)
• Path: What was targeted (file path, registry key, network address)
• Result: Success, failure, or specific error
• Detail: Additional context (bytes written, flag values, etc.)

High-value operations to look for:

Saving and Analyzing Procmon Logs

During analysis, Procmon accumulates events in memory. Save the log before restoring the snapshot:

File → Save → Native Process Monitor Format (PML)

The PML format preserves all Procmon features including filters and can be reopened in Procmon for later analysis. You can also export as CSV for processing in Python or Excel:

File → Save → CSV (Comma-Separated Values)

Analyzing Procmon output with Python:

import csv

with open('procmon_output.csv', 'r', encoding='utf-8') as f:
    reader = csv.DictReader(f)
    
    for row in reader:
        # Find registry persistence locations
        if 'RegSetValue' in row['Operation']:
            if 'CurrentVersion\\Run' in row['Path']:
                print(f"Persistence detected!")
                print(f"  Process: {row['Process Name']}")
                print(f"  Path: {row['Path']}")
                print(f"  Detail: {row['Detail']}")
        
        # Find file drops in suspicious locations
        if 'WriteFile' in row['Operation']:
            path = row['Path'].lower()
            if any(x in path for x in ['\\temp\\', '\\appdata\\', '\\programdata\\']):
                print(f"File drop: {row['Path']}")

Tool 2 — Process Explorer

Process Explorer is an enhanced Task Manager that shows the complete process tree — which processes spawned which other processes — along with detailed information about each process.

Download: Free from Microsoft Sysinternals (included in FLARE-VM)

What Process Explorer Reveals

Process tree view: Shows parent-child relationships. When malware spawns cmd.exe to execute commands, you'll see the parent (malware.exe) and child (cmd.exe) relationship clearly. When malware injects into svchost.exe, the injected code creates threads in that process — visible in Process Explorer.

Suspicious process indicators (highlighted in different colors):

• Purple: Packed or compressed executables
• Red: Processes that have exited since you opened Process Explorer
• Cyan: New processes — recently created
• Dark red/maroon: Processes with deleted parent (orphaned)

Per-process detail: Right-click any process → Properties to see:

• Full path of the executable
• Command line used to launch it
• Environment variables
• Loaded DLLs (including injected ones)
• TCP/IP connections from this process
• Process security (token, privileges)
• Strings from process memory

Finding Injected Code in Process Explorer

When malware injects code into a legitimate process, that process loads a DLL that doesn't belong there. Look for:

1. In Process Explorer, select a suspicious process (e.g., explorer.exe)
2. Press Ctrl+D to open the DLL view
3. Look for DLLs loaded from unusual paths (\Temp\, \AppData\, with no path at all, or with names that look like random strings)
4. DLLs without a valid publisher/signature are especially suspicious

Verifying with VirusTotal: Process Explorer can submit process hashes directly to VirusTotal: Options → Check VirusTotal.com. Each process shows a detection ratio.

Tool 3 — Autoruns

Autoruns shows every location in Windows where programs can be configured to run automatically at startup or login. It is the definitive tool for finding persistence mechanisms.

Download: Free from Microsoft Sysinternals (included in FLARE-VM)

Why Autoruns Matters

When malware wants to survive a reboot, it must write itself somewhere that Windows will execute automatically. Autoruns covers all of these locations:

• Registry run keys (most common):
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
• Startup folders
• Scheduled tasks
• Services
• Browser extensions
• DLL hijacking locations
• Boot execute entries
• Winlogon entries
• AppInit DLLs
• Many more (Autoruns covers dozens of persistence locations)

The Autoruns Baseline Technique

The most effective way to use Autoruns for dynamic analysis:

Before executing the malware:

1. Launch Autoruns
2. Let it fully scan (wait for the status bar to complete)
3. File → Save → Save as autoruns_baseline.arn

After executing the malware (wait 3–5 minutes for persistence to install):

4. Press F5 to refresh Autoruns
5. File → Save → Save as autoruns_postinfection.arn

Compare the two:

6. In Autoruns: File → Compare → select autoruns_baseline.arn
7. New entries added by the malware appear in green
8. Entries deleted by the malware appear in red

This diff immediately shows you exactly what persistence mechanisms the malware installed, without having to manually review every entry.

Autoruns VirusTotal Integration

Like Process Explorer, Autoruns can verify each autostart entry against VirusTotal:

Options → Scan Options → Check VirusTotal.com

Autoruns will submit each entry's hash and display detection ratios next to each item. Entries with high detection ratios that you didn't put there are strong infection indicators.

Tool 4 — TCPView

TCPView shows all active TCP and UDP connections and listening ports on the system, updated in real time, with the process responsible for each.

Download: Free from Microsoft Sysinternals (included in FLARE-VM)

Reading TCPView During Analysis

TCPView columns:

• Process: Which process owns the connection
• PID: Process ID
• Protocol: TCP or UDP
• Local Address: IP and port on this machine
• Remote Address: IP and port of the remote host
• State: TCP connection state (ESTABLISHED, TIME_WAIT, etc.)

What to watch for:

When malware establishes a C2 connection, you'll see it appear in TCPView as an ESTABLISHED connection from the malware process to a remote IP.

Even if INetSim intercepts the traffic, TCPView still shows:

• The process making the connection (confirms the malware process)
• The destination IP and port (the C2 address or INetSim's address)
• The connection state

For malware using non-standard ports:

Legitimate software typically uses well-known ports (80/443 for HTTP, 25/587 for email, 21 for FTP). Malware using ports like 4444, 8443, or random high ports is immediately suspicious.

For malware pretending to be legitimate:

Some malware tries to blend in by using process names similar to Windows system processes (svchost32.exe vs svchost.exe, lsas.exe vs lsass.exe). TCPView shows the full path when you hover over the process name — a svchost.exe running from C:\Windows\Temp\ is not legitimate.

Recognizing Anti-Analysis Techniques

Sophisticated malware actively tries to detect that it's being analyzed and change its behavior accordingly. During dynamic analysis, watch for:

VM Detection

Malware checks for indicators that it's running in a virtual machine:

• Registry checks: VM-specific registry keys (VMware, VirtualBox, Hyper-V leave traces)
• Process checks: Looking for analysis processes (procmon.exe, procexp.exe, wireshark.exe, vboxservice.exe)
• Hardware checks: CPU ID instructions return VM-specific values; number of CPUs (VMs often have 1 or 2); RAM amount (VMs often have less than 4GB)
• Timing attacks: Running timing checks — operations that take a predictable time on real hardware take different time under emulation

What you see in Procmon: Registry queries to VM-specific keys that return NOT FOUND (because it's actually a VM). This is itself an indicator.

Sandbox Evasion

Automated sandboxes typically run samples for 2–3 minutes. Malware authors know this and include:

• Long sleep calls: The sample calls Sleep(600000) (10 minutes) before doing anything interesting
• User interaction requirements: Looking for mouse movement, specific screen resolution, or user input before proceeding
• Process count checks: Real systems have many processes; sandboxes may have few

Countermeasures for analysts:

• Patch the binary to skip sleep calls (requires debugging skills from Part 10)
• Set system time forward to skip time-based checks
• Use a VM configuration that mimics a real user system (multiple monitors, user files in Documents and Pictures, browser history)

Debugger Detection

Malware may check whether it's being run under a debugger:

• IsDebuggerPresent() API call
• CheckRemoteDebuggerPresent() API call
• Checking the PEB (Process Environment Block) BeingDebugged flag
• Timing attacks (debugged code runs slower)

You'll encounter these more in Parts 10 and 11 when using x64dbg.

Documenting Dynamic Analysis Findings

Systematic documentation during dynamic analysis prevents you from forgetting important events and ensures your final report is accurate. Here's a documentation framework:

Real-Time Notes Template

## Dynamic Analysis Session — [Sample SHA256] — [Date/Time]

### Environment
- FLARE-VM: Windows 10 Enterprise, baseline snapshot [date]
- REMnux: 192.168.1.100, INetSim running
- Analysis duration: [X] minutes

### Execution

**T+00:00 — Sample executed:**
- Started: sample.exe from C:\MalwareSamples\Working\
- PID assigned: [PID]
- Parent process: explorer.exe (double-clicked)

**T+00:05 — Process activity:**
- Spawned child process: cmd.exe
  Command: `cmd.exe /c copy sample.exe C:\Users\analyst\AppData\Roaming\svchost32.exe`
- Created file: C:\Users\analyst\AppData\Roaming\svchost32.exe
  (SHA256: [compute hash of dropped file])

**T+00:07 — Registry activity:**
- Set registry value:
  Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  Name: WindowsHelper
  Data: C:\Users\analyst\AppData\Roaming\svchost32.exe

**T+00:12 — Network activity:**
- DNS query: evil-domain.com → resolved to 192.168.1.100 (INetSim)
- TCP connection: 192.168.1.100:80 (malware → INetSim HTTP)
- HTTP GET request: /beacon?id=A1B2C3D4&type=firstrun

**T+05:00 — Ongoing:**
- Periodic HTTP GET every 60 seconds (beaconing)
- No additional file drops observed

### Summary of Behaviors

**Persistence:** Registry Run key
**Lateral movement:** None observed
**Data collection:** None observed
**C2 communication:** HTTP beaconing every 60 seconds
**Network destinations:** evil-domain.com (blocked by INetSim)

### Artifacts Collected
- [ ] Procmon log: procmon_[sample_hash].pml
- [ ] Autoruns before/after: autoruns_baseline.arn, autoruns_postinfection.arn
- [ ] Wireshark capture: capture_[date].pcap
- [ ] Memory dump: memdump_[date].raw
- [ ] Dropped files: [list with hashes]

Practical Exercise — Analyzing calc.exe

To practice these techniques safely before touching actual malware, use calc.exe — the Windows Calculator. It's a real Windows PE binary that you can run, observe, and practice with. It cannot cause any harm.

Where to find calc.exe:

C:\Windows\System32\calc.exe

Practice exercise:

1. Start Process Monitor with no filters
2. Launch calc.exe
3. Close the calculator
4. In Procmon, filter by Process Name = calc.exe
5. Review what the calculator does:
   • What registry keys does it read?
   • What files does it access?
   • Does it make any network connections?

This exercise builds your Procmon reading skills using a completely safe, known file. The techniques are identical when applied to actual malware.

Verification Checklist

• You understand the order: tools running BEFORE malware executes
• Process Monitor configured with basic filters
• You've practiced the Autoruns baseline/compare technique
• TCPView opens and shows existing connections
• You've run the calc.exe exercise and reviewed Procmon output
• Documentation template ready
• INetSim running on REMnux before every analysis session
• Wireshark capturing on REMnux before every analysis session
• Procmon log export tested (File → Save)

Previous: Part 6 — Static Analysis Part 2: Strings, YARA, and IOC Extraction Next: Part 8 — Dynamic Analysis Part 2: Network Traffic and Sandboxes