Next I started up Regshot to take a baseline of the system. For this I used the option '1st shot and save."
I then started Process Explorer, TCP View, and Capture Bat and launched the malware specimen. The below screen shots will describe the results of each tool.
Process Explorer shows us that this piece of malware spawns the processes; mshta.exe, cmd.exe, at.exe, at.exe, etc.The malware quickly spawned and terminated several at.exe processes over and over.
TCP View shows us the mhsta process going out on UDP port 1052
Capture is a command line tool that that runs and displays changes made to the system as they happen. It is a tool that you must be actively monitoring at all times or output to a text file to detect changes made. In this case it caught several changes including the malware application launching a cmd prompt and deleting the same cmd prompt.
Next I used Reg Shot to take another shot of the VM. I then compared it to the first shot to reveal changes made. This showed several interesting things, including the malware adding itself to Internet Explorere as a Browser Helper Object (BHO).
While continuing to explore this specimen, the program broght up a very official looking window 'labeled Microsoft security essentials alert," that reported that process monitor was a trojan. A similar message appeared when I attempted to run task manager. The malware would not let either utility actually load. This may fool some users, but in this case I do not have security essentials installed on my virtual machine. This malware also terminated Process Monitor, for me how very helpful ;-) The screen shot below shows this very official looking window.
Next I decided to see what the AT scheduled tasks were all about. The various AT jobs have mshta.exe go out to crazyraccoonshow.com with 21 different jobs. Each job is set to run at different times, but on the same daily scheule. So, next I decided to try one of my favorite utilities, Fileinsight. Fileinsight is a graphical utility that is free from McAfee labs that includes a light weight debugger, script editor/viewer, and a graphical version of wget for windows.
Fileinsight was unable to get any results from the site. The web sites seem to to be either looking for specific mshta properties or the site has already been taken down, as I was unable to pull any content.
Since I already tried to pull the web code with File Insight, I next loaded up wireshark on my VM and my virtual machine copy of REMnux. I like REMnux a lot due to the fact that it has most analysis tools for Linux bundled into a pre-built environment.
Note: REMnux is a custom Linux distribution maintained by Lenny Zeltser, available at zeltser.com.
After starting Wireshark, and starting two of AT tasks, I began to see a lot of DNS lookups to various hosts such as update.celtro.dns1.us. Since this still did not tell me anything particularly useful, I set my windows VM's gateway to the IP address of my REMnux machine and then turned on the fakedns script on REMnux. I then went back to Wireshark and noticed that now that the malware was able to resolve DNS entries, it was attempting to communicate outbound with HTTPS to the same URL's, only the destination ports were cycling upward starting at 1045 and incrementing up by 1 each time it did not get a response. I also noticed that the malware was attempting to create another session using a random TCP port to port 80. This was interesting, but again didn't yield a whole lot of information, so next I setup a netcat listener using the command: nc -l -p 80
For those unfamiliar with Netcat, it is a generic listener. In this case the command I issued launched netcat and set it to listen (-l) on TCP port 80 (-p 80).
I did this to see if this traffic was really encrypted or if it was just using the source port pf 443 as a way to hide in normal traffic. I continued to wait to see if the malware process would eventually reach my listener. After noticing nothing in my netcat window, I decided to connect to my listener via telnet. My netcat listener was in fact receiving my telnet transmission. After several minutes I was still not seeing data on Wireshark. At this point I realized that the malware was doing a series of HTTPS requests followed by a series of HTTP requests.
Unfortunately since I was unable to decode what this particular malware was doing in it’s network communications, I stopped my analysis. I had found out that this particular malware was a fake AV tool that probably holds your system for ransom. This was sufficient information for me. Another thing to note on the behavior; this malware did not seem to be very persistent as I was able to terminate it without it automatically restarting.
At this point, our dynamic analysis is essentially over, if you wanted to keep your results to further analyze the logs, etc., you would need to copy the log data from your analysis tools to your host machine. I suggest copying the text and pasting it to a new document on your host machine, as transfering any files off of your infected VM is a risk. After you have obtained any needed data, you should revert your VM to your snapshot to ensure that you are back to a clean state.