Recently, I was considering material for an internal knowledge transfer session on timelining, when it occurred to me that the subject matter was likely of broader interest, and so, without further ado...
First, a note about the way I personally use timelines. I find them a great way to identify dated tidbits which one might not otherwise realize are associated with activity of interest, once investigation has been focused down to a restricted timeframe. When I do this, I typically extract all timeline data, and then filter it for times of interest to avoid information overload.
The best general purpose timelining utility of which I'm aware is Kristinn Gudjonsson's log2timeline tool. This great program handles a huge selection of input filetypes, and can output in several standardized formats, most notably; Bodyfile. I consider the output from this utility (when run against a complete image) to be the foundation of an ultimate timeline for the target system. There are a few gaps in the coverage of log2timeline, however, and at least one little-known tweak (which I've requested Kristinn add or at least document in the tool) can enhance its utility to those examiners who, for one reason or another, need to do most or all of their analysis under Windows. The tweak to which I refer is a way to get log2timeline to compile and run under the Windows cygwin environment. There's one prerequisite for log2timeline which won't compile under cygwin no matter what I've tried, the Net::Pcap perl module. (Technically, there are two, but the other one is Gtk2, and that's only required to build the GUI, which I don't use. It may actually be possible to build that, but I haven't tried very hard.) In any case, the Net::Pcap module is only used to add timestamps for packets in network captures, which I've found to be infrequently necessary in my usage. Fortunately, with one simple change, it's possible to disable this functionality, and allow the remainder of the utility to be built successfully under cygwin. All you have to do is remove the file 'lib/Log2t/input/pcap.pm' from your log2timeline source folder after you untar it, but before you begin the build process.
The few sources of timestamp data that I really miss from a log2timeline scan are as follows:
- Filesystem metadata such as NTFS timestamps. However there are a number of other tools which are capable of extracting this information and outputting it in a compatible format, including fls and ils from the Sleuthkit.
- The redundant NTFS timestamps from the long and short Filename attributes are a related but separate category from the above, and can be more difficult to access. I could have sworn you could dump them with the Sleuthkit, but a cursory look back at the documentation only indicates the data is available via the istat command, which doesn't output a compatible format. However, I just did a quick Google search, and it appears that David Kovar has recently added Bodyfile output format support to his analyzeMFT Python script. This script also extracts the timestamps for allocated files, so it's a one-stop-shop for MFT dates. Alternatively, EnCase users with current support can get at this data using the MFT Date and Time Comparator (V2) EnPack.
- NTFS timestamps stored in the INDX structures in the parent folder beneath which a file resides. I'm not currently aware of any forensic tool that can parse through all the NTFS timestamps stored in INDX structures and output the data in a standardized format. The data itself is available to EnCase users via either the 'index buffer reader' EnScript that ships in the Examples folder, or else in the '42 LLC INDX Extractor Enpack' from 42LLC.
- While selected Registry Key last written timestamps are extracted by log2timeline, I sometimes find it useful to have the complete list of timestamp data from the registry. The regtime.pl perl script by Harlan Carvey, which is part of the SIFT Kit, can extract all this data and dump it in Bodyfile format.
- All of the above in unallocated space or physical memory dumps. This is where it gets kind of hairy. As with the INDX data mentioned above, there are tools which can identify and extract the data, but they don't deliver it in nice neat packages. I dealt with this issue somewhat in my previous posting, Dates from Unallocated Space, but a few points are worth revisiting and/or expanding upon.
- (New!) Enscript from Lance Mueller to find classic (.evt) event log entries in unallocated & output as a new .evt file. It doesn't work well on physical memory images, surprisingly, but I posted on Extracting Event Logs or Other Memory Mapped Files from Memory Dumps a few months.
- Enscript from Lance Mueller that can find old registry key names/dates in unallocated (or anywhere else, for that matter), restricted by date.
- Enscript from Lance Mueller that can find a date-restricted windows timestamp anywhere. In this case, however, you're on your own figuring out exactly what the date refers to. Careful examination of the surrounding data can indicate that it's part of a MFT entry, an INDX entry, a registry key, a log entry, a file fragment, or just random bits.
- The INDX Enscripts mentioned above work fine on unallocated space as well.
- Any file which is successfully carved from unallocated space may contain useful dates, so try parsing all such carved files again with log2timeline or possibly exiftool to extract any useful application metadata.
As always, you're welcome to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy. And please do so if you know of something useful that I've missed.
.PNG "DFIR_ICON_(1).PNG"){kind=icon}