After I posted on the lack of NTFS $FILE_NAME data provided by the major GUI forensic tools, there were several great comments left for that post that described a variety of tools from people like Harlan, David Kovar and Mark Menz. While these are great tools from three forensic gurus, I’m still a bit perplexed why the major GUI software tool makers don’t just deal with parsing this data head on.
I’ve had at least one person tell me that EnCase could do this with an EnScript. Of course, EnCase can do a lot of things with EnScripting. The rub is that I don’t want to use an EnScript for something that should be part of the standard GUI column view along with the $STANDARD_INFORMATION time stamp values. For example, I want to be able to quickly view the $FILE_NAME information for the files stored in particular folder or volume for timeline purposes. One of the primary reasons we use GUI forensic tools like EnCase and FTK is that they serve as overall file system examination tools. We can use them to examine our evidence from a high level and then decide which of the more specialized tools we wish to employ to drill down on specific artifacts.
I don’t expect EnCase or FTK to do everything for me. That’s why we have people like Craig Wilson, Rob Lee, Harlan Carvey, Mark McKinnon, Lee Whitfield, Paul Sanderson, Kristin Gudjonsson and all of the rest of the fantastic forensic tool developers out there who make great tools for specific purposes that compliment the major GUI tools. However, I do expect them to parse basic $MFT record information which includes $FILE_NAME time stamps.
Since I made my original post, I discovered that the fine people over at Technology Pathways are doing this at least with a free version of their Pro Discover tool. Pro Discover Basic is a very basic GUI forensic tool, but it does what every major GUI tool should do which is to parse both the $STANDARD_INFORMATION and $FILE_NAME time stamps in glorious column form.
EnCase doesn’t do this at all. FTK is sort of…kind of…starting to move in this direction. If you look in the comments section of my previous post on this issue, you’ll see that a couple Access Data engineers were nice enough to drop by and explain that FTK 3.1 parses this data….sometimes. I say “sometimes” because it doesn’t do it as part of the normal column view and it reportedly only shows the data to the examiner if the $FILE_NAME values are different form the $STANDARD_INFORMATION values. I have no idea why Access Data is making it this complex. I absolutely do not want this level of hand holding from my forensic tools. I want to be able to see for myself what the time stamp values are for a given file. Concealing basic time stamp information from me because they think it’s…I guess…not important isn’t helpful.
If the Guidance Software and Access Data think that having the extra $FILE_NAME columns in their standard GUI file system view would somehow confuse the examiner or clutter the interface, then they can make them turned off by default and require the examiner to “opt in” to see them.
What am I missing here?
Forensic 4cast Awards
The Forensic 4cast awards are upon us! If you haven’t voted yet, you still have time before the awards presentation at the SANS Forensics and Incident Response Summit on July 8th. You can also attend the award ceremony for free even if you aren’t attending the summit. Lastly, the fine people over at Disk Labs have sponsored the actual awards which are pretty amazing looking.
Nor sure if you are missing anything major, but there are some aspects of GUI strategy or philosophy that may be important.
ReplyDeleteOne says: only tell me what's wrong or an anomaly. This one is used in places like jumbo jets (a.k.a. the dark cockpit) where there is danger for information overload, and a clear risk that vital information is missed.
(This seems to be what AccessData does, at least partly -- don't show the $FILE_NAME fields, unless they don't tally with those in $STANDARD_INFORMATION.)
Another says: give me everything (of a certain type), and I'll make sense of it myself. You have to give me sorting capability, filtering capablity, and data field selection, and all the usual refinements also ... of course.
The anomaly approach to forensics analysis -- look for things that are/seem abnormal or unusual -- would probably go well with a 'dark GUI'. But that assumes that all anomalies *are* identified. In this particular case, I think any timestamp anomalies would need to take directory timestamps (those in the INDEX data) into account as well.
The 'give me all' approach is considerably more flexible, but it also makes some very serious requirements of the GUI. For instance, a 'give me all' analyst would insist on being able to get the full timestamp resolution. (EnCase only give you down to seconds, and also sorts columns not on actual field contents, but on displayed time). That kind of analyst would also insist on being able to decide if information is raw (for timestamps, in binary form and/or UTC), adjusted (exactly what TZ correction applied?), filtered (reducing resolution to seconds instead of 100ts of ns), and perhaps even if the data is NULL (which probably can't happen for timestamps), or absent (such as no $STANDARD_INFORMATION attribute present!).
I don't think any forensic analysis platform manages to do the 'all' approach today: all users have to buy the unusually unstated selection policy applied by the software manufacturer.
Fabulous comment! Thank you so much for taking the time to leave it.
ReplyDeleteThere's also the analogy of combat aircraft and avionics. There has been a lot of effort put into making cockpit controls more pilot friendly so that they get the information that they need (the HUD being a fantastic innovation in this area) and aren't overwhelmed with a lot of information while they concentrate on getting their mission done.
The rub is that $FILE_NAME fields are basic forensic information. I don't necessarily want my primary GUI tools parsing everything in the main GUI view and overwhelming me with information. There's a time and a place for things to be scripted inside of these tools and to bring third party tools into play. Parsing basic time stamp information for an NTFS $MFT record is something that I want to have the option to enable.
I understand that having $FILE_NAME columns in the main GUI forensic view is going to add more clutter. In some cases they will provide no additional benefit which is why I have no issue with making these columns "off" by default and requiring the examiner to enable them.
But I want to see this information and do so with a lot less effort than what I have to do right now.
You hit the nail on the head about the EnScript approach of Guidance Software. Not only is it cumbersome to run the EnScripts, but viewing the parsed data is not always that easy. Worse, keeping track of EnScripts can be a full time job. And once you get all your favorite EnScripts catalogued and accessible from a central location, an interim upgrade to EnCase breaks up some of the EnScripts and you're stuck. Or you move to the 64-bit platform and discover that some of your EnScipts no longer work, while Guidance support advises to run the 32-bit version of EnCase on a 64-bit platform--yeah that suggestion surely justifies the expense of upgrading your systems...
ReplyDeleteYou can do some very powerful things with EnScripting as guys like Howard Williamson and Lance Mueller have shown us all over and over again.
ReplyDeleteOnce upon a time, I thought I'd learn to script with EnScripting and even took an excellent EnScripting course taught by Howard Williamson. However, I ultimately decided that if I was going to spend time learning a scripting language, it would be something like Perl which has broader value. I haven't done that yet, but I would love to carve out the time to do that someday.
While I make a lot of use of EnCase, I can easily see a day when I decide to just stop using it in favor of something less expensive that does as good of a job or better with file system forensics. My next blog post will be on this topic.