Based on some of the events of the week, and in light of a follow-up post from Eric, I wanted to follow-up on my last blog post.

Earlier this week, I spent an entire day talking with a great group of folks on the other side of the country...a whole day dedicated to just talking about forensics! Some of what we talked about was malware (specifically, 'bot) related, and as part of that, we (of course) talked about some of the issues related to malware characteristics and timeline analysis. One of the aspects that ties all of these topics together is timestomping...when some malware gets installed, the file times (more appropriately, the $STANDARD_INFORMATION attributes within the MFT) are purposely modified. MS provides open APIs (GetFileTime/SetFileTime) that allow for this, and in some cases, the file times for the malware are copied from a legitimate system file.

So, tying this back to "skillz"...in my previous post, I'd mentioned modifying my own code to extract the information I wanted from the MFT. Interestingly, Eric's post addressed the issue of having the information available, and I tend to agree with the first comment to his post...too many times, some GUI analysis tools get over-crowded and there's just too much stuff around to really make sense of things. Rather than having a commercial analysis app into which I can load an image and have it tell me everything that's wrong, I tend to rely on the goals for the analysis that I work out with the customer...even if it means that I would use separate tools. I don't always need information from the MFT...but sometimes I might. So do I want to pay for a commercial application that's going to attempt to keep up with all of the possible wrong stuff that's out there, or can I use a core set of open-source tools that allow me to get the information I need, when I need it, because I know what I'm looking for?

So, what does the output of my code look like? Check out the image...does this make sense to folks? How about to folks familiar with the MFT? Sure, it makes sense to me...and because the code is open source, I can open the Perl script in an editor or Notepad and see what some of the information means. For example, on the first line, we see:

132315 FILE 2 1 0x38 4 1

What does that mean? The first number is the count, or number of the MFT record. The word "FILE" is the signature...the other possible entry is "BAAD". The number "2" is the sequence number, and the "1" is the link count. Where did I get this? From the code, and it's documentation. I can add further comments to the code, if need be, that describe what various pieces of information mean or refer to, or I can modify the output so that everything's explained right there in the output.

Or, because this stuff is open-source, another options is to just move everything to CSV output, so that it can be opened up as a spreadsheet.

Again, because this is open-source, another option that can be added to the output is to add the offset within the MFT where the entry is found...that's not really necessary, as that offset can be easily computed from the file count, and that may even be intuitively obvious to folks who understand the format of the MFT (and as such may not be necessary for the output).

Now, back to the image. The "0x0010" attribute is the $STANDARD_INFORMATION attribute, and the "0x0030" attribute is the $FILE_NAME attribute. Note the differences in the time stamps. Yet another option available...again, because this is open-source code...is to convert the output, or just the $FILE_NAME attribute information, to the five-field TLN format.

So, one way to approach the issue of analysis is to say, hey, I paid for this GUI application and it should include X, Y, and Z in the output. As you can imagine, after a while, you're going to have one crowded UI, or you're going to have so many layers that you're going to loose track of where everything is located, or how to access it. Another way to approach your analysis is to start with your goals, and go from there...identify what you need, and go get it. Does this mean that you have to be a programmer? Not at all. It just means that you have to have a personal or professional network of friends in the industry...a network that you contribute to and can go to get information, etc.

Remember that scene from Napoleon Dynamite where he talks about having "skillz"? Well, analysts have to have skillz, right?

I was working on a malware exam recently...samples had already been provided to another analyst for reverse engineering, and it was my job to analyze acquired images and answer a couple of questions. We knew the name of the malware, and when I was reviewing information about it at various sites (to prepare my analysis plan), I found that when the malware files are installed, their MAC times are copied from kernel32.dll. Okay, no problem, right? I'll just parse the MFT and get the time stamps from the $FILE_NAME attribute.

So I received the images and began my case in-processing. I then got to the point where I extracted the MFT from the image, and the first thing I did was run David Kovar's analyzemft.py against it. I got concerned after I ran it for over an hour, and all I got was a 9Kb file. I hit Ctrl-C in the command prompt and killed the process. I then ran Mark Menz's MFTRipperBE against the file and when I opened the output .csv file and ran a search for the file name, Excel told me that it couldn't find the string. I even tried opening the .csv file in an editor and ran the same search, with the same results. Nada.

Fortunately, as part of my in-processing, I had verified the file structure with FTK Imager, and then created a ProDiscover v6.5 project and navigated to the appropriate directory. From there, I could select the file within the Content View of the project and see the $FILE_NAME attribute times in the viewer.

I was a bit curious about the issue I'd had with the first two tools, so I ran my Perl code for parsing the MFT and found an issue with part of the processing. I don't know if this is the same issue that analyzemft.py encountered, but I made a couple of quick adjustments to my Perl script, and I was able to fairly quickly get the information I needed. I can see that the file has $STANDARD_INFORMATION and $FILE_NAME attributes, as well as as data attribute, that the file is allocated (from the flags), and that the MFT sequence number is 2. Pretty cool.

The points of this post are:

1. If you run a tool and do not find the output that you expect, there's likely a reason for it. Validate your findings with other tools or processes, and document what you do. I've said (and written in my books) that the absence of an artifact where you would expect to find one is itself an artifact.

2. Analysts need to have an understanding of what they're looking at and for, as well as some troubleshooting skills, particularly when it comes to running tools. Note that I did not say "programming" skills. Not everyone can, or wants to, program. However, if you don't have the skills, develop relationships with folks who do. But if you're going to ask someone for help, you need to be able to provide enough information that they can help you.

3. Have multiple tools available to validate your findings, should you need to do so. I ran three tools to get the same piece of information, of which I had documented the need in my analysis plan prior to receiving the data. One tool hung, another completed without providing the information, and I was able to get what I needed from the third, and then validate it with a fourth. And to be honest, it didn't take me days to accomplish that.

4. The GUI tool that provided the information doesn't differentiate between "MFT Entry Modified" and "File Modified"...I just have two time stamps from the $FILE_NAME attribute called "Modified". So I tweaked my own code to print out the time stamps in MACB format, along with the offset of the MFT entry within the MFT itself. Now, everything I need is documented, so if need be, it can be validated by others.

As an aside to timeline analysis, I've been considering the relative confidence levels inherent to certain data sources, something I had discussed with Cory. One of the things we'd discussed was the relative confidence level of file system metadata, specifically the timestamps in the $STANDARD_INFORMATION attribute versus those in the $FILE_NAME attribute. Brian Carrier addresses some specifics along these lines in chapter 12 of his File System Forensic Analysis book.

So, I've been looking at the output of tools like Mark Menz's MFTRipper and David Kovar's analyzeMFT.py tools. Based on the information in Brian's book and my chat with Cory, it occurred to me that quite a bit of analysis could be done automatically, using just the MFT and one of the two tools. One thing that could be done is to compare the timestamps in both attributes, as a means of possibly detecting the use of anti-forensics, similar to what Lance described here.

Another thing that could be done is to parse the output of the tools and build a bodyfile using the timestamps from the $FILE_NAME attribute only. However, this would require rebuilding the directory paths from just what's available in the MFT...that is, record numbers, and file references that include the parent record number for the file or folder. That's the part that I got working tonight...I rebuilt the directory paths from the output of David's tool...from there, it's a trivial matter to employ the same code with Mark's tool. And actually, that's the hardest part of the code...the rest is simply extracting timestamps and translating them, as necessary.

Also, I didn't want to miss mentioning that there's a tool for performing temporal analysis of the MFTRipper output from Mark McKinnon over at RedWolf Computer Forensics. I haven't tried it yet, but Mark's stuff is always promising.