We get a special guest technical blog post straight from Tim Mugherini.
NTFS: “New Technologies File System”
Default file system of all modern versions of Windows. Version 3.1 is the current version on Windows XP and above. The Master File Table ($MFT) is the heart of the NTFS file system and contains the metadata about all the files and directories on the file system. Each file and directory has at least one entry in the $MFT.
By default, Each MFT entry is 1024 bytes in size (defined in boot sector) with the first 42 bytes containing 12 defined fields and the remaining unstructured space being used by attributes. It is these attributes that can be useful during analysis but only if we understand the effects of the operating system, software, and user behavior on these values.
There are some limitations. The MFT will expand as needed and NTFS does NOT delete MFT entries after they have been created. But an entry will be re-allocated for use if the file has been deleted. Upon file deletion, the entry’s “in-use” flag is set to 0x00 and the entry will become available. Entries are reused in sequential order and once re-allocated, the attribute data is overwritten.
Loving the Hex: Overview of NTFS Master File Table Attributes
The $STANDARD_INFORMATION ($SI) attribute has a type identifier of 16. There are four 64-bit (MACE) timestamps in this attribute that represent the number of one-hundred nanoseconds since January 1, 1601 UTC. Many of the values stored in the $SI attribute are displayed in explorer.exe when viewing the properties of a file or folder.
The $FILE_NAME ($FN) attribute has a type identifier of 48 and contains the file name (encoded in UTF-16 Unicode), parent directory reference, and additional MACE timestamps. Rob T. Lee has done a fair amount of work on cataloging the differences in behavioral changes of both the $SI and $FN time attributes. So if the behavior of $MFT time attributes are known, we can use them to assist in identifying malicious files.
The Sleuth Kit: FTW
The Sleuth Kit (TSK) is a collection of forensic command line tools for *nix and windows, and can analyze most common file systems.
Let’s search a dd (raw) image for a suspected malicious file called malicious.dll with the TSK tool “fls”.
# fls -f ntfs -r Image001.dd | grep malicious.dll
++ r/r 1618-128-1: malicious.dll
This returns the $MFT record number which is 1618. Using “icat” we can now carve the $MFT entry out.
# icat -f ntfs Image001.dd 0 | dd bs=1024 skip=1618 count=1 | xxd
I have shortened the output to display just the entry header and marked up some attributes of interest.
Now we can view specific attributes for this entry by specifying the type. For example, to view $SI (type=16) for entry 1618 (offset 56 as defined by bytes 20-21 above).
# icat -f ntfs Image001.dd 1618-16 | xxd
The first thirty two bytes represent the creation, modified, entry, and accessed times (8 bytes each). Note three of these attributes appear to be the same (February 11, 2010 7:30 AM). The entry date is different, however (March 2, 2011 7:15 AM). This is the date the #MFT entry was created and is usually the same as the creation (born) date (an exception would be in a soft delete of a file). Bytes 32-35 represent the attribute flags outlined earlier (i.e. read only, archived, etc...).
Similarly, to view $FN (type=48) for entry 1618.
# icat -f ntfs Image001.dd 1618-48 | xxd
Bytes 0-7 of the $FN time attribute, are the parent reference (or in this case the system32 folder). The next 32 bytes are the first four $FN Time values which match the $SI Entry date. The last 28 bytes in the above example represent the file name.
Stop: A Quick Side Note on File Deletion
If a file is recycled then the file name will change to $.ext, and its location will be in .\Recycle.Bin\\ folder. The $MFT record will still be marked active until the recycle bin is emptied and the $SI Entry Date will represent the date the file was moved to the recycle bin even after removed from the Recycle Bin.
If a hard delete of the file occurred. Then the $MFT record is immediately marked inactive and the file name and all time attributes remain unchanged (until over written by a new entry).
Practical Use: Exporting and Parsing the $MFT
While using TSK is useful to view a $MFT entry for a specific file, it might be useful to parse all entries into a friendlier format for further analysis. If you have identified a malicious file, doing so could help identify all other files and folders associated with the time of compromise.
First we must carve out the entire $MFT from a volume or image with “icat”.
sudo icat Image001.dd 0 > MFTOut.csv
Once, we have the $MFT we can use David Kovar’s analyzeMFT.py to parse every record into csv format.
analyzeMFT.py -f MFT -o MFTOut.csv –a
The following is an example of rogue AV (ISe6d_2229.exe) I discovered on a user’s Windows 7 laptop. By parsing the $MFT I was able to discover the other file locations associated with the time of infection. The following output was sorted by the $FN Entry Time (note: times are in UTC by default).
In this case I used this information to identify the prefetch file associated with the infection and used prefetch parser to parse the contents and obtain the location of the payload for dynamic analysis.
Anti-Forensics: Manipulating of the $MFT Times
It is possible to manipulate the $SI timestamps. Vinnie Liu demonstrated this with the Metasploit Timestomp project in 2005. The following, is an example of doing the same with Windows PowerShell.
Let’s use the TSK “istat” tool to obtain the metadata of our malicious file in a visually friendlier way.
# istat –f ntfs ntfs1.dd 1618
If the $SI Entry Modified date mirrors the creation date, then the above output might indicate possible timestamp tampering (an exception would be file deletion). Additionally, the $FN Attributes initially mirror the $SI Creation date. They can change but it is more difficult to manipulate $FN Attributes but not impossible.
Changing the system time prior to file creation would certainly get you there but there would still be indicators of the initial compromise. Thus changing the time attributes post file creation would be ideal. Changing the system time, altering the $SI attributes, and then leveraging some of the behavioral effects on the $FN Time attributes (i.e. moving and renaming the files) would change all the time attributes.
This could still be detectable, however. New Features in analyzeMFT.py (v 1.5 and above) not only look for differences between $SI and $FN Time attributes but also look for usec abnormalities.
• -a (anomaly detection) adds two columns:
• std-fn-shift: Y = $FN create time is after the $SI create time
• Usec-zero: Y = $SI create time has usec = 0
The following examples demonstrate both abnormalities.
Coming to a Lab Near You: Super Timelines
$MFT $FN Attributes + Super Timelines = WIN
Utilities such as Log2Timeline and the Sleuth Kit Mactime allows for the creation of a Super Timeline by leveraging the bodyfile format. Multiple timeline sources (i.e. event logs, registry, prefetch etc...) can be combined for complete forensic picture of an incident or compromise.
To date this has not been possible with both the $SI and $FN attributes from the $MFT however. Mark McKinnon was kind enough to let me check out his MFT_Parser utility which does support this functionality. The full file path for each $MFT entry is listed as is both the $SI and $FN time attributes. This is very useful for detecting stomping while looking at super timeline. Dave Hull has a great post on the subject here.
Mark as released this utility for Windows as beta for PDC listeners (*nix and mac support is also on its way). The Windows version can be found here.
The syntax for the cli is as follows:
mft_parser_cl.exe <$MFT File>
For Example: mft_parser_cl.exe $MFT pdc001 MFTOut C would output everything on the volume in the following formats:
IR and Malware Analysis WIN!
This is one forensic technique (Timeline Analysis) that focuses on one object ($MFT) in one layer (Metadata) of one type of file system (NTFS) during one type of malware analysis (Static) that is typically done during one phrase (Detection/Analysis) of incident response. It is something you can add to your Incident Response and Malware Analysis toolkit.