This month's sample can be retrieved here: 882ced9c6987b919fdbbbe5221cbfbe2
Filename: free-zoo-video.45262.exe
MD5: 882ced9c6987b919fdbbbe5221cbfbe2
This sample was an interesting one to analyze. I initially had some trouble trying to get this running in my dynamic lab environment. When I would open the executable, it would run for about 30 seconds and it appeared to just die.
I started Regshot on a clean snapshot in my VMWare environment. I ran the executable file and let it run for about a minute. After that, I took our second snapshot in Regshot to see what changed. This must have been the cleanest result I have ever seen from the output of Regshot.
I thought to myself, either this file isn't being run from where it needs to be run from, or it knows it's being analyzed. My initial instinct is to jump into static analysis and figure this out, but alas, I'm on dynamic duty this time so I'm going to try a different method.
I ran the file again while watching the process with Process Monitor. I was trying to get a feel for things it might be looking for or wanting. It seemed to read a ton of registry keys. Some of them were related to winsock and TCP/IP parameters. I thought to myself, maybe this thing wants some network connectivity.
I configured my lab host to go out to the real Internet. I will caution you here to make sure this is controlled. Some analysts will even recommend against this but I have found it can reveal things when having trouble with a sample such as this. If you do this make sure you have complete control over the access it has and have the ability to remove it's access should anything bad start to happen.
Ahh, looks like we are getting closer. After providing this thing some network connectivity it attempted to do more. Unfortunately it crashed pretty quick after execution.
Did I mention this sample was a real pain? I resorted to removing VMWare tools from my lab machine in order to see if it realized it was being analyzed. This is fine because I can always revert back to snapshot to get the tools back. That's the beauty of virtual environments! After rebooting I double clicked the file again and bingo. Looks like we are running now.
I ran Regshot again for the first shot. Seeing how this sample seems pretty aware of stuff, I didn't want to keep it running in case it realized I was using it. So instead of keeping Regshot running, I choose to take the first shot and save. I can stake a second shot if it runs and compare it with the loaded first shot.
After about 30 seconds I got a Java pop up which can be seen the screen shot below:
I decided to open Process Explorer and see what is going on. I noticed that I now have three new processes running. Mt2.exe, MVawia.exe and Mt1.exe. These are showing in fuchsia color in Process explorer, which by default means they are packed. Another interesting note is that it says Adobe Player Setup. I don't have automatic updates going so that is indeed interesting.
I started by taking a look at Mt2.exe. I looked on the strings tab and it shows UPX0 and UPX1 near the top. This would be a good indicator that this binary is packed with UPX. It could be there to throw us off, but it could be legit as well. I didn't see any TCP/IP connections from this binary so I decided to move on to the next new process.
Moving on to Mvawia.exe. Viewing the strings tab on this guy I also see UPX0 and UPX1. We can assume that this sample is packed as well. One thing different about this one was the existence of TCP/IP connections. It added and removed a ton of connections, this thing is busy.
I now took a look at Mt1.exe. Like the others, the strings of this file show UPX0 and UPX1 as well. There were no network connections on this file either. I also wanted to mention that one nice feature of Process Explorer is that when you are on the Strings tab, you can choose to view the strings from Image (on disk) or in memory. When the sample is run in memory, it has to be unpacked, so if you choose that option, you will often find more strings that are readable which may give you more clues as to what this thing is doing or capable of. Another thing that was interesting is that there was a child process to this one called ctfmon.exe.
Ctfmon.exe is a real Windows application. It is generally used to monitor active windows and assist functions for alternate input devices such as text to speech or others. The odd thing here is that it is running as a child process of these rather than then ctfmon.exe which is generally a child of explorer.exe.
While I was writing this section and letting the processes run, I noticed a command line pop up for a second and disappear. I also noticed that a new child process of one of these binaries was the Windows help center. Unfortunately my egress filtering (which I forgot to turn off while giving this sample access to the Internet) stopped whatever it was going to do. I quickly shut that off and decided to let it run a little longer and see if it would happen again.
As if on command after I wrote that last sentence, an IE windows popped up taking me to www.restasis.com, an ad for a Prescription Eye Drops for Dry Eyes. Soon after that the Restasis site popped up another window to show me their fancy new commercial, but oh no! I need the latest Adobe Flash to view it. OK, I'll bite.
I installed the Flash player, but I don't see any video! How rude! I closed the window out and decided to let things run on their own for a little longer. One thing I forgot to show is that the IE instance was loaded under an svchost.exe process rather than a child of explorer.exe. Another sign that we got something funky going on.
I let things run a bit longer and nothing was really happening. It could very well be that I was not waiting long enough. However, I decided I wanted to launch IE manually and see if anything changed there. Ahh! MSN wants me to install a new Adobe Flash player now. Before I could click to install, a popup from www.vuwl.com/pop.html came up. I choose to run the new Flash player and let IE run by itself for a bit.
Nothing seemed to be going on so I decided to do some light browsing and see if I see anything else that is odd. I browsed to www.google.com and nothing really seemed odd. I decided to try a bank site. I went to www.suntrust.com and this site wants me to run adobe flash player as well. I'll allow it. I may come back to this later and watch network traffic as I enter my, wink wink, real credentials.
I tried to go to another bank. I decided to Google for M&T bank. I click the link to go to their online banking page but I was redirected to glimpse.com which wanted me to run some Adobe Flash content.
I decided to try one more site before leaving. I navigated to bankofamerica.com and wouldn't ya know, I need to allow Flash content there as well.
At this time I decided to take my second snapshot with Regshot to see what has changed. I choose to load the 1st shot from my desktop where I saved it.
I then took my second shot and hit the compare button. The bad thing about browsing around while doing a regshot is that there is going to be a lot of noise in the file. We have some indicators in which to sift through the data for though.
At this time I think I have seen enough on the real internet. I'm going to fire up Lenny Zeltser's new distro REMnux to launch a sniffer and see what I can see on the wire. My current theory is that this is a click fraud or similar sample, but with the basic dynamic analysis that I'm doing, I can't tell if that is the only capability.
I set the IP address to of my Windows host to my host only networking in VMWare. I set the default gateway as my REMnux box which will be running fakeDNS to start as well as wireshark to see what this sample may be requesting. You start fakeDNS in REMnux by typing fakedns. This will prompt you for your sudo password which is malware for this distro.
You start wireshark in REMnux by typing wireshark. This will also prompt you for your sudo password as the alias is really sudo wireshark. Again, type malware. Go to the capture menu and choose start capture, or you can also hit control + E.
I see a ton of traffic already. The first DNS request I see is for alljplanet.com. Of course our fake DNS server gave up a good response and then I see a request on port 80. You will see a RST, ACK in the response though, because we are not listening to port 80.
I'm going to take a sidebar here for a second. Some may ask why didn't I just fire up DNS server, web server, mail server, IRC server etc. for the sample before I started my analysis. One thing I recently learned from a very, very wise man (Lenny Zeltser) in his SANS 610 course is to give the sample a little bit at a time. This way you can control what it is doing at a granular level and mold your lab as you progress in your analysis. I used to just throw the kitchen sink at samples, but then I would dread sifting through the data overload. Thus, I recommend and have started following this advise as it has allowed me to filter what I am seeing to more relevant data.
Back to the regularly scheduled program :)
I noticed in our fakeDNS responses a number of DNS queries.
I'm guessing at this point that we want port 80 traffic on these due to what I have seen thus far. What I'm going to do at this point is fire up a netcat listener to see if I can glean any information out of the requests. I know I could use Apache, or some other web server, but I'm going to start with netcat since it is so easy to use.
To do this, I bring up another xterm window and type sudo nc -l -p 80. This tells netcat to listen (-l) on port 80 (-p 80). This should show any request that comes to port 80. (Don't forget sudo! You need to use this because you are opening a privileged port and that needs root access)
We did get a successful capture of what was going on. As you can see in the following screen shot, we have HTTP Post to the site alljplanet.com. The data is not in clear text. Our next job would be to figure out what the data contains. Another interesting thing to note is that the user agent here is saying it's IE 6.0 when I am running IE 8.0 on my lab machine. It is also saying that the Windows version is Windows NT 5.0 which corresponds with Windows 2000, when I am running Windows 5.1 which is XP. These are all indicators of compromise (IOC), which could be use to search for or detect/block on in your systems and IDS/IPS devices.
At this point the requests seemed to have slow down a bit. I tried to kick start them by opening the browser and going to some of the sites that I tried when it had a live connection to the Internet to see if that would get things moving. It did not seem to help. I decided to let it run it's course.
After waiting for a bit, I decided to kill the netcat listener and start it again. One thing about the Linux netcat is that it tends to hang after one session. The Windows version allows for a -L which will continue to listen for other sessions.
It looks like the data in the post for every site is the same. My first guess is that application/x-www-form-urlencoded is encoding the values of what is being posted so I'd like to decode that to see if I can see what is being sent.
I'm feeling stronger now that this sample is doing some sort of click fraud. I don't know all of the sites that are being called, but one interesting request made is for netflix.com which could be evidence of pretending to click an ad but it could be something else as well. Again, these requests aren't being seen on the Windows GUI while I am on it. The requests are coming from an IE instance that is running under svchost.exe rather than under explorer.exe process as it should be.
That is about all the time I can devote to this sample at this time. I'm pretty sure that it is a click fraud sample at least. As I mentioned before, it may have other capabilities, but I do not see evidence of these through dynamic analysis alone. I would probably revert to static analysis at this point, but that is Jamy's job this time. Check out his post and see what he found.
