I was reading a mailing list thread where an individual was trying to determine if a machine he was looking at was compromised. He said that he ran the Volatility malfind plugin (thanks MHL for the awesome plugin), but seemed like he struggled with what to do after he ran it. I wanted to write this post in hopes that it may help some people that may be faced with the same situation.
I’m going to use the 2012 GrrCON dfir challenge. I know this image is old and played out, but it shows nicely how this can be done. I also have not written any blog posts on it after creating the challenge so here is my one post on it
I would like to first say that when you are faced with attempting to find evil, regardless of the data type, you should start by trying to find what you already know. There had to be a reason that this machine was dumped on your lap so do your best to locate that reason in the evidence provided. It can make your analysis much faster then blindly poking at things, hoping to find something.
What if that known thing started out as an AV hit for a PIVY mutex vs an outbound connection to a known bad ip address. There are a couple of ways we can go about locating the malicious process. The first way would be to use the Volatility plugin handles with the -t Mutant option.
Looking at the output we can see our suspicious mutex located in PID 1096.
Another way we can go about finding the offending process would by locating the mutex string in memory. We first need to locate the string in memory prepended with the byte offset to that location and send that to a file. We can accomplish this by running the following command.
Now that we have our strings file we can again take advantage Volatility. Using the strings plugin we can find which process that string is located in. The plugin basically matches the physical memory offset to the virtual offset within the offending process.
Once the command finishes you should see the following output:
So now we have that we have a PID to work off of, our first course of action would be to determine what that process actually is. Using the pslist volatility plugin we can quickly determine that it is explorer.exe and that there is only a single explorer.exe process.
Now for the fun. Knowing that explorer.exe doesn’t typically initiate outbound network connections and that there is not a rogue explorer.exe process running, we can begin start to wonder if malicious code was injected into that process. We will use the malfind plugin to see if there may be indications of this. The plugin will search the process space for pages where the attributes are set to page execute, read, write and display the findings. It can be very easy to spot the malicious code if there is an MZ header displayed by the plugin, but this is not always the case as malware can strip the header before it is loaded or maybe the header was paged out.
This command will produce the following output.
Note: There was much more output, but I was unable to locate an MZ header.
So we have indications of malicious code being injected into the explorer.exe process but no MZ header to specifically locate the malicious file. It may seem like we’re done at this point, but we still have more options. We can use that vaddump plugin to dump the regions in memory that are associated to the explorer.exe process.
Now using the strings command we can search for our mutex in the various pieces of data that were dumped.
Looks like we have 2 different memory regions that contained our mutex.
Running strings against what we’ve discovered we can see that in fact this is our malicious code.
We can confirm that this is poison ivy by running the following yara rule against one of the outputted files.
There are many additional ways to go about doing this, but this is one way that seems to work for me. I hope this helps someone out there and if you have any questions or comments please let me know.