So in a case I was working on, I was able to put this theory to the test. I had a RAM dump from what was believed to be an infected system. I then used Memoryze to process the dump and Audit Viewer to review the data.
So what would you look for? Well, like I have said many times, you cannot approach any investigation with some sort of idea of what you are looking for. You cannot expect to fire up a RAM dump and simply spot the anomaly. It's not realistic and will likely never ever happen. So in this case, I had an idea of what I was looking for. Before opening the RAM dump, I was able to review the volatile data I had extracted from the suspect system, and found a series of files with MACB times around the time the incident was reported to have occurred. Now, that in an of itself is a huge issue which is outside the scope of this post...so...back to our story.
With my list of files that I was looking for (which was about 15 files), I opened the RAM dump by reviewing the dlls and sorted each by the frequency. And after a bit of searching, I found the one file I was looking for injected into IEXPLORE.exe.
So, this is a great example of how what I was looking for and found was not a huge spike in data point. So now, I have the name of the injected dll, and the PID it was injected into. Now, that might be such a big deal with a process like IEXPLORE.exe, but, what if the process was something a bit more populous on the system like svchost, or lsass? Then having the specific PID is very important.
So next, I could go to my forensic image, extract the dll and do some reversing to figure out what this thing is doing and why it's there.
Good times!
No comments:
Post a Comment