By Jeff Hamm & William Ballenthin

Last week on M-Unition, Willi and I published the first post in the NTFS INDX Buffers series. The first post explained how to extract an INDX attribute using various tools. In part two of the series, we detail the binary structure of a file name attribute. The file name attribute is used to track an INDX buffer's content.

Part 2: The Internal Structures of a File Name Attribute

A filename attribute in the NTFS file system tracks metadata associated with a single filename of one file. Multiple filename attributes can exist for any file - such as a short file name alias. This metadata includes the filename, timestamps, physical file size, and the logical file size. Filename attributes are always resident in the $MFT (Master File Table) as a sub-structure of an $MFT file record. These attributes have a dynamic size in the $MFT because path components in NTFS range from 1 to 255 characters.

The Master File Table

To understand the role of the filename attribute, we first need to review the structure of the $MFT. The $MFT is a special NTFS file that organizes the rest of the files on the file system. It is made up of metadata and defines the relations between all directories and files. In some sense, the $MFT file is the essence of the NTFS file system.

NTFS structures the $MFT into small segments, called records - each of which describes one file or directory. When these records correspond to files, a record indicates where to find the data content of the file. When these records correspond to directories, the record tracks the contents of the directory. In both cases an $MFT record stores metadata in attributes.

Examples of attributes include standard information attributes (type 0x10), filename information attributes (type 0x30), and data attributes (type 0x80). While an $MFT record is 1024 bytes in length, attributes are variably sized. They sit consecutively within an $MFT record.

Filename Attributes

Filename attributes are a particular type of $MFT record attribute. They track information associated with a single filename for one file. In NTFS, a file may have more than one filename. For example, most files have an 8.3 filename (such as "DOCUME~1") in addition to a Unicode filename (such as "Documents and Settings"). This means each $MFT record often has more than one filename attribute.

The attribute stores modified, accessed, changed, and created/birth (MACb) timestamps that relate to the filename value. These timestamps are updated independently from the standard information attribute timestamps, which change when a user accesses or modifies the contents of a file. Filename attribute timestamps change when the filename for a file is updated, such as when a user renames a file from "Secret Plans of World Domination.docx" to "Nothing to See Here.docx".

Forensic investigators are encouraged to review filename attribute data because it offers alternate and additional data points for interesting files. Because the filename attribute contains its own set of MACb timestamps, and there may even be many filename attributes for one interesting file, an investigator may generate a much more robust timeline of actively. "Time-stomping", or modifying MACb timestamp information for anti-forensics, is easy for standard information attribute timestamps. However, filename timestamps are tricky to persuasively modify because the Windows API does not expose the necessary functions. Forensic investigators often review all timestamps as a set to identify anomalies, and filename timestamps are critical in this process.

Besides timestamps and filenames, a filename attribute contains a file offset to the $MFT record of the containing directory. An investigator may use these pointers to reconstruct the directory hierarchy of a file system. For example, both analyzeMFT.py (http://www.integriography.com/) and MFTINDX.py (https://github.com/williballenthin/INDXParse) use this technique to process an $MFT and report the contents of a file system. Figure 1 and Table 1 list all data tracked in a filename attribute.

The following figure lists a detailed binary layout for a filename attribute. The source for this fragment of C code is the Sleuthkit (http://www.sleuthkit.org).