Memory Analysis For Beginners With Volatility
Coreflood Trojan: Part 2
Hello everyone, welcome back to my memory analysis series. If you didn’t read the first part of the series — go back and read it here:
Memory Analysis For Beginners With Volatility — Coreflood Trojan: Part 1
Just to recap quickly:(if you don’t want the recap skip to the next section) Last time we left off at finding out what the malicious code that was injected into IEXPLORE.EXE process was doing. We used the apihooks command to list all instances of hooking in our host’s machine. Just to remind you, here’s what we found:
As we can see above is our piece of code that was hooked. The module that was hooked is kernel32.dll. The CALL instruction calls a different function that was injected into memory instead of LoadLibraryW. It executes this beautiful malicious piece of code (which you can see for yourself — If you dont remember how, go back to the previous post):
In order to figure out what this piece of code does, my first instinct is to use the vaddump command. This command enables me to dump out a section of memory. I can use it to dump out the module from memory and disassemble it using IDA ( or some other disassembler )
One small problem though: In the previous post I used the malfind command which is supposed to find modules injected into memory. Unfortunately we ended up not seeing any actual module in memory. What we saw was this:
Usually when a module is injected into memory it should have the MZ header which would be a good sign for us that the injected module was not tampered with in memory or that the header was not paged. It could be that the module has had its header cleared out from memory for obfuscation reasons. It’s a pretty good move to make it hard to investigate this malware since it will take longer to reconstruct everything in order for us to be able to disassemble the module.
Fortunately, we can use the impscan command which allows us to retrieve information about API calls made by the code to other modules in order to understand the functionality of the injected code.
impscan works by scanning the process memory for calls to functions like JMP [<address>] or CALL [<address>] which basically tells us that the function address is stored in the <address> ( a pointer to an address ) in memory. These kind of calls are sometimes used for retrieving a function address from the IAT which is an array that contains the addresses of imported functions. What volatility can do with that is follow up on these calls to see what the IAT stores and to which functions it points us to in the other modules loaded in memory.
Now that we know how impscan works lets go ahead and use it, and we’ll specify the IEXPLORE.EXE process id as a command argument since our malicious code is loaded in it and we want to find what it does. Also, we’ll need to provide the base address for the malicious module loaded into memory so volatility will know where to scan for imports.
How do we get the base address of our malicious module?
We’ll combine a hook example from apihooks and a quick search in the vadinfo command output (see previous post for an explanation of the vad) to get the base address of the malicious code.
Now that we have everything we need, lets run the impscan command
We can now see the beautiful list of imported functions. We can also see the IAT column which shows us the address of the element in IAT array and the and on its right side the address of the imported function contained in that array element. impscan also shows us the names of the imported functions, this could help us understand what our code does by the name of the function.
Here’s an example of how to use the impscan command:
As we can see, we can look at the output of the impscan command and compare it to the injected code to find out what each function call is doing. For example , in the exhibit above a call to FreeLibrary is made by the injected code. FreeLibrary frees the loaded dynamic-link library (DLL) module and, if necessary, decrements its reference count. When the reference count reaches zero, the module is unloaded from the address space of the calling process and the handle is no longer valid.
We now have the ability to go through the injected code and understand its functionality. One problem with this method is that it takes a while to go through all this assembly code in order to get the bigger picture. So another way we can use impscan is just to look at the imports and understand what functions the module uses. Just by seeing the function names and not necessarily going through the code logic by reading assembly code we can get an idea of what this malware is trying to do.
Lets highlight some suspicious functions that impscan gave us and follow up on what the malware may be doing using other volatility commands.
There are many interesting functions used by our malicious module. For those of you who already have experience with volatility and forensics, don’t worry ill try and cover everything. But first I want to start with some simple stuff; The Registry.
We can see the malware imported some API to use the Registry. As you all probably know, the Registry contains sensitive information and settings. Some malware strains use the registry for persistency by adding a executable file to run on startup by editing the autorun key. It could be that in this case the malware is trying to steal sensitive information by checking the registry for where some files it may want to exfiltrate are stored.
Volatility gives us a nice command called handles. This command enables us to take a look at the handles used by a process. For those of you who don’t know, Windows uses objects to represent and access system resources, including files, devices, keys and so on. Essentially, an object is accessed by using a per-process handle table in the kernel. Opening an object results in adding a pointer to the object in the handle table. Volatility uses this fact and scans the memory for handles.
We’ll use the handles command with a pipe and filter out the output to contain only Registry keys.
If you are trying this at home, you can probably see a longer list of keys opened, I just cut off a small part of the list that seemed interesting.
So off the top of my head I can say some interesting things about what we can see here. First things first, we can see a key ending with TYPEDURLS. This key could just be regularly used by Internet Explorer (As it should be) but it could also be abused by a trojan to get information about websites used by their victim. This is a good spying technique, especially since the code is injected into Internet Explorer. Another similar key is RUNMRU which lists recently run programs, a hacker that wants to gain insight into a users activity may want to check it out and exfiltrate this info as well.
Another interesting thing is that the DRIVERS32 registry key is used somehow. This may hint at the fact that this malware may have a driver installed on our host as well and may be using it somehow. I also saw some registry keys related to IE Security settings being used, this may be another method of an attacker to lower security measures on the host’s computer and make it more susceptible to other attacks.
Just to conclude this part I want to point out that we didn’t see strong evidence for malicious activity in the registry, there were no custom registry keys used (At least nothing we saw). We can only speculate what this malware is doing in the registry. In the next part of the series I want to use more tools given to us by volatility in order for us to be able to understand exactly what is the goal that the malware is trying to achieve.
Thanks for reading the second part of my memory analysis series!
