Malware Analysis – #1

See here on my post on creating your own Malware Analysis lab!

I created an account on VirusShare to download some malware samples. I downloaded the first one so let’s dive in and see what we can discover!

The SHA256 for my download was: 2db4caf14befbe99a9cf51ed7f7c3cade9df666c45579baaffc9e5a53c0b773c.

  • I downloaded the zip and compared the sha256 hash once downloaded to confirm it matches.
  • Next, I booted up a python webserver to transfer this over to my Windows testing machine.
  • Unzip the zip file and I renamed the file to hmm.exe
  • Start up a procmon on my local windows machine and Wireshark on my REMnux box. I already have the networking configured for DNS and returning web services (see my blog post in the link at the top of this one for more info)

Static Analysis

Before I go all willy-nilly and just boot the executable up, let’s see what we can determine from it statically. I opened the file with pestudio. The initial indicators tab throws up some immediate flags:

indicators tab

Looking in the strings column, we can see several long base64 encoded strings to avoid detection.

Next I analyzed the file with peID to determine how the file was packed / compiled and saw the following:

Basic .NET 32-bit application

With this in mind, I booted up dotPeek by JetBrains and navigated to the Root Namespace we have for C# source code files that are randomly named and the functions / strings inside these files are also obfuscated:

odd naming convention for files
Snippet of one of the files, note many of the variables have random strings.

Inside of zcom.Resources, there are two base64 strings. The first one appears to be more source code. The second one returned random chinese characters so it wasn’t useful to read but I am sure it gets shuffled around with the code in order to become legible again:

Dynamic Analysis

Let’s go ahead and run this file and see what it does. I have a clean Wireshark open on my REMnux box, and procmon and ProcessHacker open on the Windows box.

Immediately upon launching, we get a new tmp8CA2.tmp.exe launch in Process Hacker. This is located in %TEMP% and has a date modified of 2/16/2007 12:00 AM. I also noticed another System.Web.exe in this folder with the same date and time, so it could be a clone.

My DNS server captures a few DNS records as well:

DNS records

Wireshark has lit up, this process is sending tons of packets. One of which, is trying to get an IP.php from one of the urls we saw:

Web Request

It seems to have hung on this point, continually trying to download the IP.php file that it cannot actually reach. I tried to see if I could cURL or wget the file myself but both webservers were down. I killed the process at this point, turned off Wireshark and Procmon capture and now let’s save the output from wireshark and procmon.

We need to ensure the procmon file is exported with no Sequence ID and Thread ID is included. Also check All Events when saving. See here for more info. I also saved the wireshark file as a wireshark/tcpdump pcap file instead of pcapng. Use wget on windows and python web server on linux to send the file over.

Booting up procdot, load the procmon log file into Procmon and wireshark pcap into Windump.

Procmon Analysis

The only call made to was a GET /IP.php, which in our case the application always received a dummy PHP. It also tried doing the same from, probably a mirror site. Both URLs were offline so not exactly sure what that endpoint did.

The graph is far too long to display here, so I will just use bullet points to describe the general flow

  • Thread 3340, process “hmm.exe” creates several files such as zCom.resources, tmp8CA2.tmp, dncrnse9.tmp, dncrnse9.0.vb, dncrnse9.cmdline
  • Next it creates a new process, “vbc.exe”, PID 4504
  • PID 4504, “vbc.exe”
    • creates a new process “conhost.exe”, which writes and deletes several temp files.
    • It spawns a cvtres.exe which is used to compile resource files into compiled objects. This data is written out to the tmp8CA2.tmp.exe, it also writes a bunch of data to dncmse9.out
    • then deletes its own process and all the temp files created from the initial “hmm.exe”
  • Back to 3340, “hmm.exe”, The process sets some registry keys:
    • The following are located in HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\
      • ProxyBypass to 1
      • IntranetName to 1
      • UNCAsIntranet to 1
      • AutoDetect to 0
  • PID 2772 “Explorer.EXE” sets a registry key AppID to the full path of “hmm.exe”
  • PID 3624 launches the “tmp8CA2.tmp.exe” executable that was created from “vbc.exe”,
    • it’s first action is to delete “hmm.exe” off of my desktop. It then creates System.Web.exe in the same %TEMP% directory and sets an autostart registry key aspnet_state_perf to this executable.
    • More registry keys:
      • HKLM\SOFTWARE\WOW6432Node\Microsoft\Tracing\tmp8CA2_RASAPI32\
        • EnableAutoFileTracing to 0
        • EnableFileTracing to 0
        • EnableConsoleTracing to 0
        • FileTracingMask to 4294901760
        • ConsoleTracingMask to 4294901760
        • MaxFileSize to 1048576
        • FileDirectory to %windir%\tracing
      • It queries the above keys several times
    • Now we start the network requests.
      • rwkeith<dot> (dead URL)
        • HTTP request for /IP.php
        • It also sends a bunch of TCP requests to port 127
        • And ICMP packets with abcdefghijklmnopqrstuvwabcdefghi in the data


With the URLs it tries to access being either dead or useless, this file is mostly harmless, in its current state. It appears to be a Trojan / Backdoor Dropper where it unpacks itself to an alternate location, deletes the original file and then sets itself to autorun on startup through the registry. Here’s the caveat: If the bejnz or rwkeith servers ever come back up with that requested IP.php it would basically activate and take control of every machine that has been lying dormant with this trojan, as it constantly tries to connect to those servers.

We can alsorun the SHA256sum through VirusTotal which provides essentially all the same information we just discovered through our own analysis (in reality, this is the first step you should take, but I already knew from the get go that it was malware).

Now it’s time to reset our windows box back to our last good snapshot and prepare for the next analysis!


No comments available.

Leave a Reply

Your email address will not be published. Required fields are marked *