After exhausting our understanding of a file with static techniques, dynamic analysis is the next logical step in examining malware. It allows us to see what it attempts to do, where it wants to go, and who/what it tries to interact with.
If you haven’t done so now, it is paramount that you build yourself a secure malware analysis environment: even if you’re investigating “benign” malware from a textbook (as we are in this example), treat your malware like you would a firearm: as if every one of them was loaded. Failure to do so could put your computer and data at risk.
This post will investigate another file from Practical Malware Analysis, this time using a Windows 7 VM from OALabs. The VM is intentionally not updated with all of the latest patches and has protective capabilities like antivirus and Windows Defender turned off; we want to give any malware analyzed the best shot to work so that we have our best shot at analyzing it. The host machine and hypervisor, however, are fully patched.

It’s important to start off with some static analysis in order to get our bearings with this new file. VirusTotal tells us the file is certainly some form of backdoor trojan (“Trojan/Win32.Poison”). Microsoft Threat Intelligence states that “This family of backdoor trojans can give a malicious hacker unauthorized access and control of your PC. They try to hide by injecting themselves into other processes.”

PEView doesn’t give us much except that the file is likely packed. The import table only shows kernel32.dll and something called “ExitProcess”.

Running Strings is much more helpful, yielding what looks to be a few registry key paths(marked with green), a domain (marked with blue), and several file names(marked with red). The registry paths are locations where the file might establish persistence, whereas the filenames might be what it names itself as. The domain is likely where it will attempt to reach out for C2 traffic.

Static analysis has provided us with expected activity and some places, filenames, and domains to look and search for while we perform dynamic analysis. In preparation, there will be a few tools we’ll use to observe the malware:
- ApateDNS — ApateDNS spoofs DNS responses in an effort to convince malware to function like it is not in a virtual machine. It allows us to see any DNS requests it sends out, providing us with clues to its intended activity and indicators of compromise (IOCs).
- Process Explorer — Process Explorer is what you always wanted your “Ctrl + Alt + Delete” Windows Task Manager to be. It provides in-depth insight into all active processes running on a system. One can use Process Explorer to validate legitimate and kill malicious processes, recognize process replacement, and analyze documents (ex. PDFs, .docx).
- Process Monitor — procmon allows us to monitor registry, file system, network, and other similar activities. Because it gives insight into so many events at once, running procmon for even more than a few minutes can significantly slow or crash your VM. We’ll turn it on right before we execute the malware.
- Regshot — Regshot is an open source tool that allows you to compare registry snapshots. Like the diff command, Regshot will tell us if anything has changed in the registry since we ran the malware.
- Wireshark — Wireshark is an incredibly powerful packet capture tool. Any and all network activity is captured by Wireshark, meaning we can connect the dots between certain packets as well as dig in to single packets.
Let’s begin by taking a snapshot of our registry keys with Regshot. This gives us a baseline of what we have in our environment pre-malware.

Now let’s boot up our ApateDNS. I’m going to put the DNS Reply IP (e.g. the place where DNS replies will appear to come from) as 8.8.8.8 (Google’s Public DNS). Some malware make checks to determine if it’s in a VM, so putting 127.0.0.1 or similarand preventing a connection out to the internet could tip the malware off that it’s actually in a simulation.
Finally, we’ll run Wireshark, Process Explorer, and procmon. We’ll stop and clear out Wireshark and procmon, only activating them immediately before the malware executes so we have a high signal-to-noise ratio.
Fire in the hole…anddddd nothing.

We see no proper network traffic of any kind on ApateDNS or Wireshark. Very few processes are created for the file as seen in procmon, and no major registry key changes occur.
When analyzing malware, it’s important to note the system and version you’re attempting to run it on. Just like with legitimate programs, malware may be built to work on one or a few versions, but not all. By all accounts, it looks like this piece of malware won’t run properly in Windows 7.
Take two: Let’s try analyzing this with a Windows XP VM.

Immediately after detonating the malware in an XP VM, we see some promising WireShark connection attempts over DNS to practicalmalwareanalysis.com (something we also saw during strings). This is followed by some non-SSL traffic over port 443 (https).

ApateDNS logs further verify these DNS connection attempts to practicalmalwareanalysis.com. If this were a real investigation, we’d be aware of C2 traffic to domains that are still live, which would give us an incredibly useful IOC for threat hunting.

Let’s check ProcMon and Process Explorer to see if we notice any odd activity. By filtering on any CreateFile operations during the time that the malware ran, we find the file vmx32to64.exe created in System32. That’s another string we found during static analysis. Let’s dig deeper.

The most recent file created in System32 was the file created from the evil.exe malware. What does the file do?

As it happens, if we compare the hashes of each file in PowerShell (back to the Win7 VM), we find that both the original file (evil.exe) and the created file found in System32 (vmx32to64.exe) are the exact same file. It looks like the malware wants to maintain persistence and survive a reboot by stashing a copy of itself in C:. We should expect to see some register keys created to fit that narrative.

(Un)fortunately, it doesn’t look like the malware was successful in placing register keys that would help it survive or activate after a reboot. We find nothing in RegShot to suggest any change. I would expect to see some registry key change that would fit one of the strings we originally saw, maybe with file name AppData, VideoDriver, or WinVMX32.
Let’s check Process Monitor as one last place.

Speak of the devil. It looks like evil.exe has created a mutex of itself in the form of WinWMX32. It did this so that if it tries to run again, and it can find (or can’t find) the mutex in question, it stops and doesn’t continue to infect the same machine. This provides us with another wonderful IOC that we could use to identify compromised machines.
If this piece of malware was found with a client environment, we would’ve been able to have determined the malware’s type (Backdoor Trojan), how it’s reaching out via C2 (non-standard SSL channel over HTTPS port 443), and some good IOCs to scan for in network logs and across hosts:
- domain: practicalmalwareanalysis[.]com
- mutex: \BaseNamedObjects\WinVMW32
- filepath: C:\Windows\system32\vmx32to64
- filehash: EB84360CA4E33B8BB60DF47AB5CE962501EF3420BC7AAB90655FD507D2FFCEDD
In my next post, we’ll get into some more advanced analysis techniques.
Happy Hunting!

