This post has been on my mind for some time (I'm cleaning up draft posts), but it does not look like I am going to get to it any time soon. So this is going to be quick and dirty.
I was doing forensic on an intrusion last year and I knew the following:
The computer was compromised and talking to the outside world via DNS.
I had a DD image of the RAM, and dumps of process memory from each of the processes (as well as a lot of other volatile data).
Unfortunately, I did not have any way to know which (or if any) of the processes were the bad guy's, so my process of elimination went like this:
1. Look at the process list.
2. Find associated executables.
3. Look at executable files.
Unfortunately, this server was running a lot of "stuff." So I was still left with a lot of files to look at, but after much work, I found a file that looked weird enough to make me think that it was likely tbe bad process. (Oh, and I should point out that there were no logs and the intrusion (we later determined) was months old.)
So how does one go about figuring out what happened when there's an lack of log data? Well, it turns out that when I analyzed the files by date created, and I find a memory.dmp file.
So I spend a bit of time researching the memory dump file format and I was able to find the file that the attacker used (it caused some nastiness at the time it was executed) which in turn led me to find some other information about the attack in unallocated space.
This was kind of long, but if you aren't looking beyond what you can see (untranslated blog here) in the file system, you are missing a lot of good information.
Saturday, March 8, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment