Memory Analysis For Beginners With Volatility — Coreflood Trojan: Part 3
Welcome back. In order to continue our forensic investigation of the Coreflood Trojan we need a little recap from part 2.
We left off last time looking at handles used by the IEXPLORE process. We checked out the handles because we know IEXPLORE is doing something malicious. This is because we saw it had some code injected in it.
Just to remind everyone, this is what the IAT of the injected module looked like. We can clearly see the imported functions used by the module using the impscan command. Check out my last post if you don’t remember.
Memory Analysis For Beginners: Coreflood Trojan Part 2
After seeing how suspicious IEXPLORER.EXE is I decided it may be a good Idea to continue investigating whatever was injected into memory over there, its always a good idea to use strings.exe which will give us an idea of what’s going on in this injected piece of code. Sometimes developers will leave strings in their code that may tell us something about whatever is running in the code without the need to disassemble it.
Let’s hop over to that VAD section that we discovered in the last article with malfind:
Lets take that base address we see here and use vaddump to dump out that memory section for further analysis:
And the output is a memory dump file. We can use strings on it now (get strings here):
Now that we dumped out the strings found in that memory section let’s see what we got. In the beginning of the text file you will see a lot of garbage, scroll down and look at this:
We can see some clearly suspicious strings. It seems as though there is some sort of regex check for the url submitted by the target user maybe to steal accounts related to that user in those sites. The theory that we’re dealing with a spyware seems very probable.
Another thing we could clearly see in the strings file is a possible search for browsers installed on the target host.
It seems as though other browsers are targets for code injection. Notice how we see explorer.exe here as well. To check the theory that these are code injection targets — lets confirm it using malfind.
And here we have a section with EXECUTE_READWRITE permissions which is always a suspect for code injection.
Lets dump this section and see if we have another piece of information. Maybe we’ll find the same code that was injected into IEXPLORE.EXE here as well? Unfortunately it seems as though this is not a case of code injection as the size of the memory section (after dumping) is too small compared to what we dumped out of IEXPLORE.EXE. Also, strings turned up empty :(. It still could be that some code was injected here or maybe whatever was there was paged…
If we observe our text file we could see something that could also be the output that is generated for the commander if there is a C&C ( A host that can control and send commands to clients containing the malware ). I suspect there is in fact a C&C from what I can see in the rest of the strings here. For example:
These definitely look like some sort of output strings that would be generated for someone who is trying to run commands on a host. It looks like the controlling server would have full control over processes that start and stop on the host.
Lets refocus and try and find how this malware behaves.
As always when dealing with rootkits its good to think about the different things we want to watch out for. The first thing we want to figure out is persistency. How does our rootkit survive a reboot? What runs the malicious file ( if exists ) each time? Its good to look for the persistency method as this can help us immediately to mitigate the threat. As we can see in the strings found in the injected module, something very important shows up:
The runonce key is a classic move for persistency as whatever is written in that key is run on system startup and deleted. The rootkit can write itself to that key each time to make sure it runs as soon as the system starts up. We can see rundll32 it could likely be that this is what is executed in the runonce key and we might expect to a malicious dll on our target host.
Another persistency method that could be used here is AppInit_DLLs.
AppInit_DLLs is a mechanism that allows an arbitrary list of DLLs to be loaded into each user mode process on the system. This could be easily abused by malware to gain persistency by simply placing their malicious dlls in the proper registry location — HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion \Windows key in the registry determine the behavior of the AppInit_DLLs infrastructure ( What will be loaded and how ). Unfortunately, these registry keys are not to be found in memory.
As we have already suspected — above you can see more strings that have to do with dlls and the registry. It could be that these are just logs or debug prints that have to do with the persistency mechanism. It will be a good idea to check out what we can find about dlls in the system32 directory.
And look what we found here a string that looks really suspicious. In the system32 directory a dll file that looks really suspicious. Its not even a dll its a dIl with an I, good job.
I used filescan to see if I could get a hold of the file in memory to dump it out later on and analyze it
And here we go, found the dll.
Next, We can use dumpfiles to dump out the file and investigate it further.
Using pestudio (a portable executable analysis tool — get it here: https://www.winitor.com/) we can extract some futher information about the dumped file. We can see that it is indeed a DLL.
Looks like it is packed as we can see there are sections that indicate a packer was used.
This leads us to suspect that this module is indeed malicious. Moreover, I looked in my system32 directory and there is no module named comsbap.
To summarize, we found the persistency mechanism and we finally have some concrete ideas about this malware. It seems as though it has some spyware capabilities as well as coming with a full shell like mechanism for whoever is controlling these hosts using this malware.
Next time we will dive deeper into the full capabilities of the malware and get some more concrete evidence for what the dll we discovered does and try to analyze exactly whatever is going on here.
It may be a good idea to search for this module and see if it is loaded in any processes. If it’s loaded in a few processes this might have to do with Appinit_Dlls and we would have proof of persistency using Appinit_Dlls. You can try it out yourself and find out.
In the upcoming articles we will try and create a full timeline for whatever is going on in our target host machine, stay tuned.
Thanks for reading and see you next time.
