Deconstructing the Blueprint: A Step-by-Step Guide to Dynamic Malware Analysis

May 17, 2026

Step inside the isolated sandbox. Learn how to securely configure host-only virtual environments, trick malicious code using FakeDNS, and capture runtime footprints with Process Monitor and Wireshark.

Let’s be honest—running live malware on your daily driver is an absolute nightmare scenario. But for a security researcher, detonating a fresh malicious executable is just another Tuesday. The secret to doing this without destroying your network lies entirely in the art of the Dynamic Analysis Sandbox.

Dynamic analysis is the process of observing a malware specimen while it is actively executing. Unlike static analysis, where you merely stare at dead code or hashes, dynamic testing lets you witness its behavior in real time.

Below is a technical breakdown of how to build an isolated lab, trick a specimen into thinking it's connected to the live internet, and extract its forensic footprint.

Step 1: Architecting the Isolated Network

Before you even think about double-clicking a suspicious binary, you must ensure your environment is locked tight. The golden rule here is host-only isolation.

For this demonstration, our lab structure relies on two separate virtual environments working in tandem within VMware:

  1. The Victim Machine: A standard Windows instance where the malware (brb.exe) will be executed.
  2. The Analyst Machine: An isolated Linux distribution (in this case, REMnux) serving as our network gateway and monitoring hub.

Both machines must have their network adapters explicitly changed from NAT or Bridged mode to Host-Only. This cuts off any structural pathways to your local physical network and the public internet.

Mapping the IPs

To establish seamless communication between our twins, we need to explicitly declare their IPs on our isolated internal range:

  • Run ifconfig inside your Linux environment to locate its assigned IP (e.g., 192.168.80.128).
  • Jump to the Windows environment, open your Network Connections panel, access the IPv4 Properties of your adapter, and assign a static configuration (e.g., 192.168.80.64).

The Crucial Pivot: In the Windows adapter settings, change the Default Gateway and Preferred DNS Server to match the exact IP of your Linux analyst machine. This forces all traffic leaving the Windows box to route directly into our monitoring platform.

To verify the connection, perform a reciprocal ping test from both command lines. If you experience dropped packets, simply toggle the virtual network adapter disconnect switch and reconnect to flush the virtual DHCP cache.

Step 2: Preparing the Spyglass (Setting Up Monitoring Tools)

Malware moves lightning fast. If you run it blindly, you will miss vital systemic mutations. Before execution, we line up our monitoring array on the Windows victim instance:

  • Process Hacker / Process Explorer: For real-time tracking of process trees, memory strings, and sudden process terminations.
  • Process Monitor (ProcMon): Part of the Sysinternals suite, this captures every single registry alteration, file creation, and thread activity.
  • RegShot: A registry snapshotting tool. We take a baseline snapshot ("First Shot") before detonation, and a secondary snapshot ("Second Shot") after to easily compare the delta.

Step 3: Simulating the Wide Web with FakeDNS

Most modern malware requires a Command and Control (C2) handshake before it drops its primary payload or runs its routines. If it detects a completely dead connection, it will simply go dormant to hide its true intent.

To bypass this protection mechanism, navigate to your Linux workspace and launch FakeDNS:

fakedns

This utility listens to incoming traffic routed from your Windows sandbox. When the malware sends out a query looking for its home server (such as an NSLOOKUP request for a foreign domain), FakeDNS intercepts it and sends back a forged response pointing directly back to our lab gateway.

Now, when you run nslookup google.test inside the Windows terminal, it will report a successful resolution right back to your analyst console.

Step 4: Detonation and Behavioral Capture

With our nets cast and the background noise cleared out, it’s time to activate the sample.

  1. Clear out your active logs inside ProcMon and start a clean capture session within Wireshark on your Linux machine to record raw network packets.
  2. Double-click the target malware (brb.exe).
  3. Allow the binary to run unimpeded for 3 to 5 minutes to ensure all embedded persistence triggers have time to fire.
  4. Safely kill the process tree via Process Hacker and pause your data captures.

Step 5: Sifting Through the Forensic Evidence

Now comes the fun part: decoding the footprint left behind by the malware.

Network Stream Analysis

Opening your active Wireshark logs will immediately reveal what the malware attempted to do. Look past the typical automated Windows internal traffic until you find out-of-band queries.

In this instance, the infected host made a direct DNS call looking for its C2 repository, which was intercepted by our FakeDNS server. Following this connection up via a TCP Stream Follow, we can see that the malware tried to contact a web server to grab an ads.php configuration file while passing complex, encoded arguments (P, C, I) containing unique identifiers from our host machine.

To analyze these strings deeper, you can copy the raw payload data out as a hex stream into tools like VS Code or HexEditors (wxHexEditor) to look for structural keys.

HTTP Request Detected: GET /ads.php?p=[Encoded Data] HTTP/1.1

Registry and System Tracking

Saving your ProcMon trace logs as a comma-separated format (.CSV) allows you to process the events inside visualization suites like ProcDot.

When we refresh our map graph, the systemic mutations become completely clear:

  • File Creation: The executable dropped a temporary configuration blueprint (brbconfig.tmp) right into the local AppData Roaming profile.
  • Persistence Vector: The malware explicitly altered the Windows Registry run keys, constructing a brand new auto-start parameter labeled brbBot targeting its own path. This guarantees that even if the machine restarts, the malware maintains control.

Step 6: Post-Analysis Sanitization

Once your data is safely exported and your notes are compiled, never leave your sandbox sitting active.

Always shut down the victim machine completely and revert back to a clean, pre-detonation snapshot. This purges the temporary run keys, cleans out the dropped configurations from your virtual directory, and perfectly prepares your clean canvas for the next dynamic investigation.

← All posts