M-unition -

Incident Response with NTFS INDX Buffers – Part 1: Extracting an INDX Attribute

By on September 18, 2012

By William Ballenthin & Jeff Hamm

On August 30, 2012, we presented a webinar on how to use INDX buffers to assist in an incident response investigation. During the Q&A portion of the webinar we received many questions; however, we were not able to answer all of them. We’re going to attempt to answer the remaining questions by posting a four part series on this blog. This series will address:

  • Part 1: Extracting an INDX Attribute
  • Part 2: The Internal Structures of a File Name Attribute
  • Part 3: A Step by Step Guide to Parsing INDX Records
  • Part 4: The Internal Structures of an INDX Structure

Part 1: Extracting an INDX Record

An INDX buffer in the NTFS file system tracks the contents of a folder. INDX buffers can be resident in the $MFT (Master File Table) as an index root attribute (attribute type 0×90) or non-resident as an index allocation attribute (attribute 0xA0) (non-resident meaning that the content of the attribute is in the data area on the volume.)

INDX root attributes have a dynamic size in the MFT, so as the contents change, the size of the attributes change. When an INDX root attribute shrinks, the surrounding attributes shift and overwrite any old data. Therefore, it is not possible to recover slack entries from INDX root attributes. On the other hand, the file system driver allocates INDX allocation attributes in multiples of 4096, even though the records may only be 40 bytes. As file system activity adds and removes INDX records from an allocation attribute, old records may still be recoverable in the slack space found between the last valid entry and the end of the 4096 chunk. This is very interesting to a forensic investigator. Fortunately, many forensic tools support extracting the INDX allocation attributes from images of an NTFS file system.

Scenario

Let’s say that during your investigation you identified a directory of interest that you want to examine further. In the scenario we used during the webinar, we identified a directory as being of interest because we did a keyword search for “1.rar”. The results of the search indicated that the slack space of an INDX attribute contained the suspicious filename “1.rar”. The INDX attribute had the $MFT record number 49.

Before we can parse the data, we need to extract the valid index attribute’s content. Using various forensic tools, we are capable of this as demonstrated below.

The SleuthKit

We can use the SleuthKit tools to extract both the INDX root and allocation data. To extract the INDX attribute using the SleuthKit, the first step is to identify the $MFT record IDs for the attributes of the inode. We want the content of the index root attribute (attribute type 0×90 or 144d) and the index allocation attribute (attribute type 0xA0 or 160d).

To identify the attribute IDs, run the command:


istat -f ntfs ntfs.dd 49

 

The istat command returns inode information from the $MFT. In the command we are specifying the NTFS file system with the “-f” switch. The tool reads a raw image named “ntfs.dd” and locates record number 49. The result of our output (truncated) was as follows:

....
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: Resident size: 72


Type: $I30 (144-6) Name: $I30 Resident size: 26

Type: $I30 (160-7) Name: $I30 Non-Resident size: 4096

 

The information returned for the attribute list includes the index root – $I30 (144-6) – and an index allocation – $I30 (160-7). The attribute identifier is the integer listed after the dash. Therefore, the index root attribute 144 has an identifier of 6, and the index allocation attribute 160 has an identifier of 7.

With this information, we can gather the content of the attributes with the SleuthKit commands:

 

icat -f ntfs ntfs.dd 49-144-6 > INDX_ROOT.bin

icat -f ntfs ntfs.dd 49-160-7 > INDX_ALLOCATION.bin

 

The icat command uses the NTFS module to identify the record (49) attribute (144-6 and 144-7), and outputs the attribute data into the respective files INDX_ROOT.bin and INDX_ALLOCATION.bin.

EnCase

We can use EnCase to extract the INDX allocation data. To use EnCase version 6.x to gather the content of the INDX buffers, in the explorer tree, right click the folder icon. The “Copy/UnErase…” option applied to a directory will copy the content of the INDX buffer as a binary file. Specify a location to save the file. Note that the “Copy Folders…” option will copy the directory and its contents and will NOT extract the INDX structure.

 

FTK

We can use the Forensic Toolkit (FTK) to extract the INDX allocation data. Using FTK or FTK Imager, the INDX allocation attributes appear in the file list pane. These have the name “$I30” because the stream name is identified as $I30 in the index root and index allocation attributes. To extract the content of an index attribute, in the explorer pane, highlight the folder. In the file list pane, right click the relevant $I30 file and choose the option to “export”. This will prompt you for a location to save the binary content.

Mandiant Intelligent Response®

The Mandiant Intelligent Response® (MIR) agent v.2.2 has the ability to extract INDX records natively.  To generate a list of INDX buffers in MIR, run a RAW file audit. One of the options in the audit is to “Parse NTFS INDX Buffers”. You can run this recursively, or you can target specific directories. We recommend the latter because this option will generate numerous entries when done recursively.


To display a list of parsed INDX buffers, you can filter a file listing in MIR by choosing the “FileAttributes” are “like” “*INDX*”. The MIR agent recognizes “INDX” as an attribute because the files listed in the indices may or may not be deleted.

 

Results

Regardless of which method is used, your binary file should begin with the string “INDX” if you grabbed the correct data stream. You can verify the results quickly in a hex editor. Ensure that the first four bytes of the binary data is the string “INDX”.

Conclusion

This example demonstrates three ways to use various tools to extract INDX attribute content. Our next post will detail the internal structures of a file name attribute. A file name attribute will exist for each file tracked in a directory. These structures include the MACb (Modified, Accessed, Changed, and birth) times of a file and can be a valuable timeline source in an investigation.

We’d love to get your feedback and incorporate it into our next blog post. Please write your comments below.

 

Category: The Lab

Comments

    1. By Gordon Robertson on November 1 at 4:11 pm

      In article 1 on the INDX buffer you refer to the Master File Table as $MFT. From what I have read, $MFT refers only to file record 0 in the MFT, It is a metafile and as such is only one record in the Master File Table.

      The $ sign was retained by Microsoft for metafiles although I notice it used internally in metafiles for attributes. That makes it confusing when $Bitmap the file record gets confused with $Bitmap the attribute. In a similar manner, it seems incorrect to use $MFT the file record with reference to the entire Master File table.

      This is not a meaningless whine. I think we should strive to keep definitions consistent. Another example is with item ID lists where a pointer to an item ID list, a PIDL, is referred to as the item ID list structure. A pointer is not a structure, it’s an address indicator.

      Microsoft admits the difference but continues to use PIDL as a structure name whereas it means a pointer to an item ID list structure. If Microsoft is going to allow sloppiness it encourages it in the entire field.

    2. By Gordon Robertson on November 1 at 4:27 pm

      In a recent comment I made a mistake with reference to the use of $MFT. I claimed that Microsoft reserved the $ sign for metafiles. I should have said it reserved the $ sign for system metafiles.

      The first set of MFT file records are preceded by the $ sign, and although some are listed in the root directory they are inaccessible to the user. That is typical of system files. It makes no sense that the $MFT system file, which is file record 0 in the MFT should be the entire MFT.

      I have played with the flags in various file record attributes and made hidden, system files visible to the user. I have not tried that with files like the one marked $MFT but I would be interested to see if making $MFT visible allows loading into a hex editor of just file record 0 in the MFT or the entire MFT. One should be able to ascertain that from the file size.

    Leave a Comment

Get M-Unition in Your Inbox:

Follow @mandiant

Follow @mandiant on twitter.

Career Opps @ Mandiant

We’re growing fast, but we’re as demanding as ever. Our clients come to us in their hours of need, so we need the best. That means more than just the right education and the right experience in information security.

As Mandiant continues to grow, we are able to offer certain positions in multiple locations. For details on the location(s) of each opening, please refer to the position descriptions.

Click here to view available positions.