By William Ballenthin & Jeff Hamm
On August 30, 2012, we
presented a href="http://www.mandiant.com/events/webinar/fresh-prints-of-mal-ware-striking-gold-in-incident-response-with-ntfs-indx-">webinar
on how to use INDX buffers to assist in an href="/content/fireeye-www/en_US/mandiant/incident-response.html">
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
href="/content/fireeye-www/en_US/blog/threat-research/2012/09/incident-response-ntfs-indx-buffers-part-2-internal.html">Part
2: The Internal Structures of a File Name Attribute
href="/content/fireeye-www/en_US/blog/threat-research/2012/10/incident-response-ntfs-indx-buffers-part-3-step-step-guide.html">Part
3: A Step by Step Guide to Parse INDX
href="/content/fireeye-www/en_US/blog/threat-research/2012/10/incident-response-ntfs-indx-buffers-part-4-br-internal.html">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 0x90) 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 0x90 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.
href="https://www.fireeye.com/content/dam/legacy/ammo/Copy_UnErase_Pic-1.png"> class="alignnone size-full wp-image-3267" title="Copy/UnErase"
src="https://www.fireeye.com/content/dam/legacy/ammo/Copy_UnErase_Pic-1.png"
width="379" height="88" />
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.
href="https://www.fireeye.com/content/dam/legacy/ammo/File-List_Pic-2.png"> class="alignnone size-full wp-image-3268" title="File List"
src="https://www.fireeye.com/content/dam/legacy/ammo/File-List_Pic-2.png"
width="484" height="58" />
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.
href="https://www.fireeye.com/content/dam/legacy/ammo/Figure-2_Parse-NTFS-INDX-Buffers-Option.png"> class="alignnone size-full wp-image-3431"
title="Parse NTFS INDX Buffers Option"
src="https://www.fireeye.com/content/dam/legacy/ammo/Figure-2_Parse-NTFS-INDX-Buffers-Option.png"
width="559" height="228" />
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.
href="https://www.fireeye.com/content/dam/legacy/ammo/Figure-3_Filtering-in-MIR-for-INDX-Buffers.png"> class="alignnone size-full wp-image-3432"
title="Filtering in MIR for INDX Buffers"
src="https://www.fireeye.com/content/dam/legacy/ammo/Figure-3_Filtering-in-MIR-for-INDX-Buffers.png"
width="427" height="158" />
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".
href="https://www.fireeye.com/content/dam/legacy/ammo/Binary-Data_Pic-3.png"> class="alignnone size-full wp-image-3269" title="Binary File"
src="https://www.fireeye.com/content/dam/legacy/ammo/Binary-Data_Pic-3.png"
width="763" height="750" />
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.
