Frequently, while following up a Windows investigation, I will add certain filenames or other string values to my case wordlist and subsequently find these strings embedded in binary data of one type or another in unallocated space. Close examination of the surrounding data structures has shown that these are often old MFT entries, INDX structures, or registry keys or values. The thing that makes these things very interesting from a forensic perspective is that all of them but registry values incorporate Windows timestamps. (All timestamps referenced in this article are 64bit Windows filetime values.) Even registry values often follow closely after their parent keys in the registry, which do have associated timestamps. Once I'd noticed these key facts, it occurred to me that it would be useful to use the timestamp values to work backward to other associated data, and hence the genesis of this article.
The creation of a tool to automatically search through a disk image for Windows timestamps associated with all of the above record types, regardless of whether they're associated with currently allocated filesystem space, and timeline them all (possibly cross-referencing them against other entries to determine their relative position within the filesystem or registry), would make a great Gold Paper... Anyone?
My approach to this problem started with the use of an EnCase EnScript created by Lance Mueller back in January of 2008. This EnScript allows the user to specify a date/time range, and then searches the selected files or disk areas for 64bit values which would fit within that range if interpreted as a Windows timestamp. Having a fairly narrow timeframe of interest will obviously be useful to minimize false positives. Once the results have been identified, it's necessary to examine each one to determine whether it's one of the record types of interest.
- The detailed structure of NTFS Master File Table entries goes a bit beyond the scope of this blog posting. Salient points are that individual MFT records are a fixed 1024 bytes in size, they begin with the four signature characters 'FILE', and they contain within each of any associated Standard Information Attributes, 8.3 Filename Attributes, and Long Filename Attributes, four Windows timestamps: File Created, File Modified, MFT Changed, & File Read, in that order. (8 or 12 timestamps total, depending on whether or not the full filename fits in the 8.3 format) Guidance used to make several EnScripts (written by Howie Williamson) available which would bookmark and completely parse out all of the various record attributes. I've put in an inquiry as to why these seem to no longer be online. [Update: Guidance's response was that these scripts were provided as part of training, and "may contain little or no help documentation", so they do not publish them. As this is definitely not the case for the specific EnScripts I'm referring to, I've urged them to reconsider this decision.] Let's hope that they put them back up. Also, they may provide them in response to direct requests by customers [Ask for the StepMOM EnScript. They call it that because it's the Mother of all MFT EnScripts].
- The INDX structure is how NTFS stores content information for Folders/Directories. Full INDX records are typically 4096 bytes long, begin with the four signature characters 'INDX', and following their header, contain a listing of both 8.3 and long filenames, along with an associated set of File Creation, File Modified, MFT Modified, and File Read timestamps for each. (4 or 8 timestamps total per file.) Guidance had another EnScript, also by Howie Williamson, which parsed INDX records as well. I've queried whether it can be re-released too. [Update: this script, "Index buffer reader", was apparently included in the Example folder in the most recent version of EnCase] The structure of the individual INDX record entry is as follows. (Note: To use the provided MFT references to locate the actual MFT records, multiply the value by 1024, and use it as an offset from the start of the MFT.)
- MFT Reference of Index Entry (8 bytes) [NOT actual MFT entry number]
- Size of index Entry (1 byte) [This size seems to include padding at the end of the record. The next one starts immediately following it.]
- Filename offset (1 byte) [not sure what this refers to]
- Flags (1 byte)
- Padding (4 bytes)
- Parent MFT Reference (8 bytes) [NOT actual MFT entry number]
- File Create Time (8 bytes)
- File Last Modified Time (8 bytes)
- MFT Last Modified Time (8 bytes)
- File Last Accessed Time (8 bytes)
- Allocated Size of File (8 bytes)
- Real Size of File (8 bytes)
- File Flags (1 byte)
- File Name Length (1 byte)
- Filename (variable)
- Registry keys are often found in unallocated space as well. The overall structure of registry hive files is discussed in detail in Peter Norris' MSc Thesis, The Internal Structure of the Windows Registry. The most salient bit for the purposes of this article is the NK Cell Template on page 137, in the Appendices. This table details the structure of the NK record. Essentially we have:
- Cell Size (4 bytes)
- Record signature 'nk' (2 bytes)
- Flags (2 bytes)
- The last written time of the registry key (8 bytes)
- 60 bytes we don't really care about for the moment, including the following fields.
- Spare (4 bytes)
- Parent (Cell Index) (4 bytes)
- SubKey Counts (Stable) (4 bytes)
- SubKey Counts (Volatile) (4 bytes)
- SubKey Lists (Stable) (Cell Index) (4 bytes)
- SubKey Lists (Volatile) (Cell Index) (4 bytes)
- Value List Count (4 bytes)
- Value List List (4 bytes)
- Security (Cell Index) (4 bytes)
- Class (Cell Index)
- Max Name Length (2 bytes)
- User Flags (1 byte)
- Debug (1 byte)
- Max Class Length (4 bytes)
- Max Value Name Length (4 bytes)
- Max Value Data Length (4 bytes)
- Work variable (4 bytes)
- 2 bytes containing the length of the key name
- Class length (2 bytes) [we don't care about this value for the moment either]
- The name of the registry key (variable)
- Padding (optional)
So in essence, if we find a timestamp with Lance's script, we can then search back a few hundred characters, and see if we encounter 'FILE', 'INDX', or 'nk'. If we do, then we determine whether the data can be interpreted as a record of the specified type, and if so, parse out the data.
On a complete side note, I find it somewhat disappointing that many forensic professionals seem unaware of the plethora of redundant timestamps that are present in NTFS. I hope that the next time there's some question as to whether a file's timestamp has been altered, you will all think to go check the long and 8.3 filename timestamps, as well as the timestamps on the long and 8.3 names inside the INDX entries of it's parent folder, to say nothing of the various unallocated timestamps that were the purpose of this article. They may fail to match up for reasons other than deliberate alteration, but if they do match, I consider that a fairly good indication (though by no means a guarantee) that they were not modified after the fact. In any case, a non-matching timestamp can be a springboard for additional inquiry.
As always, please feel free to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy.
