Auteur Sujet: [FireEye]Incident Response with NTFS INDX Buffers – Part 2: The Internal Structures of a File Name Attribute  (Lu 2871 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne igor51

  • Admin
  • Mega Power Members
  • *****
  • Messages: 10419
Incident Response with NTFS INDX Buffers – Part 2: The Internal
Structures of a File Name Attribute



 

   

By Jeff Hamm & William Ballenthin

Last week on
      M-Unition, Willi and I published the first post in the         href="/content/fireeye-www/en_US/blog/threat-research/2012/09/striking-gold-incident-response-ntfs-indx-buffers-part-1.html">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       href="http://www.integriography.com/">analyzeMFT.py
      (http://www.integriography.com/) and       href="https://github.com/williballenthin/INDXParse">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).


   


                href="https://www.fireeye.com/content/dam/legacy/ammo/NTFS-Post-2.png">          class="alignnone size-full wp-image-3452" title="Image"
          src="https://www.fireeye.com/content/dam/legacy/ammo/NTFS-Post-2.png"
          width="681" height="340" />

Conclusion


   

Filename attributes are a structure of NTFS that contain
    forensically relevant metadata. Investigators should use filename
    attribute timestamps to augment their timelines and identify
    anomalies. Dead-box forensic tools also use these attributes to
    reconstruct the folder structure with which a suspect or victim
    interacted. Reviewing and understanding the binary structure of
    these key artifacts enables you to grok existing techniques, and
    potentially develop novel solutions to finding evil. Furthermore,
    NTFS indices use the same structure as filename attributes to store
    information - we'll readdress this in Part four of this series.


    Please note we have updated last week's post to include a fourth
      tool, Mandiant Intelligent Response® (MIR). The MIR agent v.2.2
      has the ability to extract INDX records natively. We recommend
      reviewing the         href="/content/fireeye-www/en_US/blog/threat-research/2012/09/striking-gold-incident-response-ntfs-indx-buffers-part-1.html">revised
      post to learn how to use MIR with INDX records.


Source: Incident Response with NTFS INDX Buffers – Part 2: The Internal
Structures of a File Name Attribute

Tags: