When analyzing malware dynamically, it's important to run your sample in a safe environment, like a VM. With dynamic analysis, you'll get more artifacts in memory, be able to monitor network activity, plus examine the scope in which the program infects the system. Having a VM open to the net allows you to view any calls that it would be making. Ex: C&C, malicious urls, or any downloads it may be requesting. Traffic analysis can be advantageous for obtaining insight into the behavior of the malware.
In chapter 3 of PMA, they discuss the idea using a Linux VM to emulate internet services (ex: dns, http, https, smtp, irc, etc.), when requests are sent to it by a second VM, that is simultaneously running the malicious program. This second VM has to have its DNS settings changed, to be specifically sent to the Linux VM's IP address. That way, any requests that are made by the malware on the second VmM, would not be sent out to the worldly internet, but instead, sent directly to our fake DNS, which is the first Linux VM. (Well technically, you can configure InetSim to reach out to actual web addresses, but for this lab, we're not getting into that).
The type of dynamic analysis presented in PMA's chapter three, is more like a sandbox, than it is a regular dynamic analysis of malware. Normally you'll run malware inside of a VM, open its connections to the world, then monitor its activity that way, instead of created a "false" internet.
For Clarity:
First VM = A linux VM Running Kali Linux, because Inetsim is installed by default. Inetsim will simulate as a DNS server. A dummy DNS, so to speak.
Second VM = Running Windows Server 2008, with its DNS requesting network settings changed to have the DNS requests sent to the IP of the Linux VM, (to the Interim program). So when the malware runs on this VM and starts making calls to a DNS server, the malware is actually having its requests sent to the Linux VM.
Why am i going over this? Well based on just what the book provides, i would have never been able to set up this simulated environment, with the two running VM's. I wouldn't have been able to dynamically monitor the malware's infection process, or networking behaviors. But thanks to Mr. Sam Bowne, and the instructions he provides for his students on his college website, i was able to follow along and ended up with the simulated environment as shown below. Normally in my blog posts, i write out the step by step instructions of what i'm doing, but since i'm going along according to Mr. Bownes instructions, i'd just be parroting what he has already written up. Just google Sam Bowne, CNIT Proj 3, and you'll see an assignment that will give you an end result of the screen shot i have below:
 |
| Nmap showing the available connecting ports from our WS2008 to Inetsim on our Kali VM :) |
Before we been our dynamic analysis, i'd like to go through some static steps first, just as a refresher for myself, and to compare results afterwards.
Lab 3-1
1. What are this malware's imports and strings? (static steps first)
Firsts things first, lets run a scan on this binary in VT, to see how popular it is, out in the wild:
53 out of 56 AV's identified this a malicious file. Not only will VT tell us what AV tools have identified this malware, but it will also tell us what the imports are, and what Packers (if any), were used:
Down here at the bottom in the red box, we can see that this binary imports the ExitProcess from the kernel32.dll library. We can double check by looking at its imports in Dependency Walker (in the future, when one tool shows the results we needed, i won't double check with another tool, simply because i don't want to fill up this post with a bunch of screen shots):
As you can see, there is our single ExitProcess import from Kernel32.dll.
Just to be sure about obfuscation, i scanned this file in PEiD to see if it identified any packers, and it did. The results were identified as "PEncrypt 3.1 Final -> junk code."
Now to view what strings may be viewable in this executable, (assuming a packer hasn't hidden some strings from us), we can use PEstudio:
Since PEstudio is just a great tool, not only did it list a bunch of ASCII strings found inside this program, but it also lists the 'blacklisted" strings, that PES considers to be common strings used amongst malicious programs. We se an interesting URL, we see some attempts to configure some Autorun keys in the registry, and an odd looking executable called vmx32to64.exe. Well, it could be a normal looking executable for all i know. I don't have the experience required in order to delineate what executables look normal and which ones don't. I'm just guessing, and hoping that PMA made it simple for me :).
Ok, so these were the basic steps in static analysis, mainly done as a refresher for myself. And to partially see if there will be any differences in the results between a static and dynamic, (i know there are plenty more results to be found in dynamic, i just would like too see some for myself).
Before i begin, in order to get malware running in a safe environment first, double clicking the executable may not always be the way in which to initiate its malicious ways. It may not run unless certain commands are entered into a shell, start after a restart, execute on an un-patched program like adobe.
If it's an .exe, simply double clicking it may suffice, since an .exe is already compiled to execute. But it's a little more tricky to get a .dll to run. I have a very basic understanding of how a DLL injection occurs. So however the malicious .dll has made it onto your system, once its there, it will then implant itself into the registry. So now whenever a new process is created and calls one of these malicious .dlls, it will begin loading the unintended malicious .dll.
In the book, PMA, it suggests to look at the export table that exists in the .dll, (statically first), to see what type of functions it will be calling. Example: The Install function, or the Uninstall function. This is the example given in PMA. These functions tell us what the .dll intends to call these functions when loaded by a process, or in other words, when a process calls the .dll, it will become malicious once installed. (I think this may be correct, i'm not exactly sure). And as you can see above from our static analysis, the import function "exit process" is in the kernel32.dll library. Fortunately, the program we're examine right now, is an .exe, from Lab03-01, and all we have to do is double click it to get it to run.
Tools and programs used in this lab:
1. A VM running Kali linux, with Inetsim installed on it.
2. A second VM simultaneously running with Windows Server 2008 (not R2 version). The programs installed on this OS are as follows:
- The Lab Files from PMA
- PEview
- Pestudio
- Process Monitor
- Process Explorer
- Wireshark
2. What are the malware's host based indicators? The changes to configure settings in the registry to auto start the malware during the boot process. There are certain registry keys that are great for maintaining persistency. You'll see it attach itself to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VideoDriver registry key, for persistency. This key path is present in the strings output, with the VideoDriver string separate. I'm not sure why they are listed separately. The program that this key was created by is called the "vmx32to64.exe", which is located in the System32 pathway. (Just view the listed string from question #1. I don't want to paste the same screen shots twice).
These are some of the host based indicators. Since we were running ProcMon, we can verify these strings with the events that were captured with ProcMon, by the malicious Lab03-01.exe. Specifically i want to see when the program vmx32to64.exe was created and when attempts were made to create a registry key. Wanting these bits of information we'll need to add filters to ProcMon, that will deliver the time stamps of when and where these occurrences took places. Hit the magnifying glass in ProcMon and add Lab03-01.exe as a filter, then 'RegSetValue' and 'WriteFile', as additional filters that will list these two functions that exist for Lab03-01. Why these two functions? Well 'RegSetValue' is a function that is called when a new value is set for a new registry key. And 'WriteFile' is a function that is called when a program writes to a filesystem. Don't get angry that i'm not going through the step by step, I'm omitting those details because they have already been provided by Mr. Bowne at https://samsclass.info/126/proj/p4-lab3-1.htm. And yes, the lab solutions at the end of PMA are listed, but honestly, are not enough to accomplish capturing these artifacts like you can when following along with Mr. Bowne's web page. Here are the capture events of Lab-03-01.exe:
If you navigate to the path location of where the vmx32to64.exe is located, and generate an md5 or sha checksum, you can use that as a host based signature to locate any files hat may be associated with the malicious program. You will see the checksum for the vmx32to64.exe program matches the checksum for the lab03-01.exe. See below:
 |
| vmx32to64.exe |
 |
| Lab03-01 |
Another persistent mechanism that malware chooses to enforce, that will also leave a host based signature on a system, are the uses of "mutexes", also known as mutants, for mutual exclusion. Mutexes are used to prevent any two threads accessing the same "critical region", (the same resource) of any variable in a programs code. So if a thread has accessed a resource that is offered in code, it creates at the same time, a mutex object (like the 'CreateMutex' function), to prevent any other thread conflicting with its access time, creating a race condition. This is one of the many 'locking mechanism' an operating system enforces in its coding development.
So why would a piece of malware want to enforce this form of secure coding? Well because it prevents itself from reinfecting certain areas of the Operating System. Once it has infected one spot, a mutex lets the malware know, it has already created a lock here, and won't crash or create a bug in its execution.
The mutex found in this malicious program was called WinVMX32, which can only be discovered via a dynamic analysis, with Process Explorer. (I don't want to get into it know, but a mutex can act as a digital fingerprint that is created by the malware, working against its attempts at staying hidden). Process Explorer will show you the running Lab03-01.exe, and when you click on the lab.exe
, and then click view handles in lower pane, it will show you all the handles this lab program has created, as seen below:
3. Are there any useful network-based signatures for this malware? If so, what are they?
Well aside from the strings listing a URL to www.practicalmalwareanalysis.com, we can use process explorer to see if it called any networking .dll libraries. In ProcEx, click on the view dll tab, and search within the list of .dll's, lab03-01.exe has used:
As you can see in the red box, lab03-01.exe uses ws2_32.dll, and WSHTCPIP.DLL, which are both used for applications to acquire network functionalities.
Disclaimer******
Inetsim is great for logging the network activity of a malicious program that is attempting to make connections with urls, and/or requests for certain domains. I was following along with Mr. Bownes instructions, and assigned Inetsim's service_bind_address to 0.0.0.0, and the dns_default_ip address to the IP of what my Linux machine is. I would then go on my infected host, and configure its DNS requests be sent to my Kali stations IP. I also chose the "obtain an IP address manually" on my infected host.
(Service _ bind _ address tells InetSim which IP address its services should connect to and dns _ default _ ip is the default IP address returned by the InetSim DNS resolver.)
Mr. Bowne set the server bind address to 0.0.0.0, because 0.0.0.0 means "all IPv4 addresses on the local machine", will be addressable. For whatever reason, i was getting a invalid ssl_version specified at /usr/share/perl5/io/socket/ssl.pm. I'm sure the way Mr. Bowne had his networking configurations set up, he was able to get it to run.
I was not able to get a complete handshake between the malware and Inetsim. I'd get an error like below, and an incomplete log record of the network connections made by my malware, in my Inetsim report:
 |
| when server_bind_address was 0.0.0.0 |
 |
| It does not show a successful request to www.practicalmalwareanalysis.com |
Just to be clear, this was the setup that resulted in the error:
**The IPs used in this post were created on throwaway systems.
Kali Linux = Service_bind_address = 0.0.0.0. Dns_default_ip = 172.16.233.169
WS2008 = Use the following DNS server address = 172.16.233.169. "Obtain an IP address automatically".
Wireshark did however log the outgoing call and port number that was made by the malware to PMA's website, but there was no return, and subsequently no completed handshake:
Here is the beacon call made by the malicious program vmx, that lets it C&C know it has infected the system.
I even tried setting up Inetsim differently, to see if anything would change. I assigned the server bind address the IP of what my Kali host IP was, and set the default dns IP to the same IP, and on my target i pointed the DNS requests to the IP of my Kali host, and this time, assigned IP address information, as seen below:
 |
And still nothing.
This blog post is a bit disheveled, mainly because when you're trying to work with tools solo, you really don't have much guidance, other than google. All in all, the tools provided a good about of dynamic information, i just couldn't get a handshake with Inetsim, so the logging reports were off. I'm sure i'm mistakenly leaving a step out form the instructions Mr.Bowne has listed, so that is why i'm getting this error. Who knows. Sometimes you win, and then sometimes you don't.
