11 - Example - Dynamic Malware Analysis

I've finally managed to analyze a piece of malware dynamically as well as statically and thought I'd share my experience about the same. I downloaded this malware from this site. This site and many others contain plenty of live malware you can download for educational purposes. I did a dynamic analysis of the malware by following the procedure I listed out in a previous blog post and drew a few conclusions. Those were:

--- The malware in question was a 6 part malware
--- 3 of those at least seemed to be 'spam' malware, which registered on sites and posted links to porn sites
--- 1 seemed to install TOR
--- The last bit of malware seemed to delete system files and crash the OS itself [Thanks to snapshots; this isn't as painful as it could be ;)]

So what I'll do in this first sample though, is take just 1 part of this 6 part malware and analyze it[static and dynamic].. independently. The name of this malware was aolsbm.1.exe. Its MD5 is 5a2be07ad750bed86be65954fb9d7d21. You can search for this on the site previously mentioned or on Offensive Computing if you want to try it out yourself. I do strongly recommend you do this, otherwise there really is little point reading further as it is a 'Hands On reversing' series after all :). That immediately meant that it was mostly a Windows executable. I copied the executable into my WinXP VM and set up all my tools as per the procedure I listed out earlier. I tried analyzing it without having a valid Internet connection; but quickly found out that this malware needed one as it was trying to create an account on some site online. So I restored an old snapshot, copied the malware onto it again, connected the VM to the Internet and then re-ran the malware.

Note that whenever you let malware do something online, you must be in a position to stop what it is doing, if it is something dangerous. In this case the worst thing it could do is post spam on a website. While this is not something good...it is not too dangerous and we can let it run at least once to see how things work. The other thing is that prior to letting the malware connect to the Internet, I had run the malware multiple times in a 'non internet' environment and studied as much as I could about it. Only if things absolutely do not work..and you cant understand what the malware is doing...should you allow Internet connectivity. So in a nutshell...I first follow the 'Without Internet' part of my procedure and only then go to the 'With Internet' part. Lets move on.

Now after running the malware you would have numerous logs available to you from the numerous tools. Please refer to a previous blog post to understand the purpose of each tool. The first and simplest thing I did was compare the Autorun state of the machine, before and after the malware was run. This can be done using the 'Compare' feature of Autoruns. The first line there said it all with a new registry entry added for aolsbm.1.exe. This means the malware will run each time the machine is restarted.

I then looked at ProcessExplorer to see if aolsbm.1.exe was still running. It was running and was purple in color. This meant that the executable was packed by default and unpacked in memory. A packed executable usually reveals much less information than an unpacked one with respect to hard coded strings or the API's that it uses internally. So its a good idea to try and unpack it if you can. ProcessExplorer though has a feature where you can look at hard coded strings for the process of the exe on disk as well as memory. The strings on disk hardly gave anything away about the process apart from a few APIs that it used..right at the end. This fits into our theory of packed executables not revealing anything.

Looking at the unpacked version though in memory gives us a wholly different picture. A few key things that I found were -
--- Microsoft Visual C++ Runtime Library
--- Visits by a browser to aol.com and other related sites
--- Numerous form fields like Username,Password,Birthyear,Birthmonth etc...giving us a feel that there is some registration that is happening.
--- Something about lifestream..which on googling is found to be AOL's social networking platform
--- Numerous strings related to logging in and logging out of some site
--- Embedded IE being used [Not clear what this is..but lets look at this later]
--- A lot of long randomly spelt domain names ending in .com
--- Numerous API's that are used in the program [GetProcessHeap, TlsFree, CreateFileA] and many many more. All these are clues about what may be going on inside. For e.g Tlsfree could mean there is something related to SSL inside this executable..maybe it makes an SSL connection somewhere.

There is plenty more that can be deciphered by carefully reading what all is found but we'll go on..as you understand the purpose of strings on disk and memory. As a little exercise do compare the outputs of process strings on disk and memory. It'll be very clear as to why packed executables are so difficult to analyze :)

Lets now see if the malware left any other traces of itself on disk. We already know it made 1 registry entry to ensure it started on each reboot. Lets look at the logs from Capturebat to see what else...if anything..it did. Now the log is big at 348K so we will want to first try and look at only what the process aolsbm.1.exe did. We can then look at the complete log for any further information. You can use find or grep to get only the lines that contain aolsbm.1.exe. Here's 1 way you can do it - grep.exe aolsbm.1.exe c:\malware_outputs\aolsbm\capture.txt > c:\malware_outputs\aolsbm\capture_aolsbm.txt

We can reduce the lines we need to look at even further by looking only at unique lines. Here is how this can be done - cat c:\malware_outputs\aolsbm\capture_aolsbm.txt | uniq -u > c:\malware_outputs\aolsbm\unique_capture_aolsbm.txt

Look at the size of the file unique_capture_aolsbm.txt now. Its just 32K :) [Strangely though, this isnt completely unique, there still seem to be duplicate lines, but it'll do for now]. Of course there will be times when you need to look at the whole file, but to start off this is good enough. I'll mention a few interesting observations from this file now:
--- 2 files that are written to: c:\Windows\lgo and C:\soft20110729_AOL.log. Interesting..the 2nd file at least; it seems to be like a log by the name of today's date. Maybe a log of all the things the process did?
--- Plenty of writes into the Temporary Internet Files folder. This clearly means a browser was used (mostly IE) and it accessed the Internet and wrote a lot of things into this folder. That means the Internet was definitely accessed.
--- It created many cookies as well for the aol.com domain. Look into the cookies folder on your system.
--- The Autorun registry key right at the top [This confirms it]

Lets quickly look at the output for Regshot now. Regshot also gives us the exact values that were set for each change made..thus bloating the file up. It is however a good double check tool. Scroll right down to the FilesAdded section and beyond...it will more or less confirm what we've already said so far was changed on the system.

Lets finally look at what Wireshark says about Network traffic. We've been saying it talks to the Internet..rt? Here's a few interesting things I found:
--- The file size is 392K which means there is something going on :)
--- There's a request made to google.com; this is probably just to check if Internet is working. It can't be anything else IMO coz google.com is not a malicious site
--- Once that comes back there are requests made to funny sounding domains for the file .sys.php. One of these domains sends a 404 back but one sends a 200 Ok back. Further traffic is then sent to this site.
--- After a few packets there is traffic destined to aol.com and various other sites, including lifestream [remember?]
--- An SSL connection is made and a lot of data exchange is done. Probably even a login is done over this connection, we cannot see this obviously as its all encrypted. Remember we saw Tls API's in the memory strings? This confirms that as well.
--- If you run the malware multiple times you will see many domains being contacted...which means that the selection of the domains.. the logic to do that is also present somewhere in the executable.

Well.. that was a lot of stuff. We didn't use all the tools to their fullest capacity but that's okay. ProcessMonitor for example is extremely verbose and can give us even more info at a much lower level, but we don't need it just now. Remember, the purpose of dynamic analysis is to gain an understanding of what the malware is doing..at a high level. It is primarily through static analysis via a debugger that you will understand how exactly it does the things that it does. And static analysis is more complex :)

That does it for dynamic analysis. Do set up a virtualized environment yourself and play around with this piece of malware which can be found here. Do be careful though and don't violate any rules ;). I've also analyzed this same executable in OllyDbg [static analysis] and that is what we will look at the next time. While performing static analysis you'll find that its extremely useful to know what the exe does..before diving into the code heads on.

Bye for now :)