The MFT file contains a unique record for each file or folder which includes several attributes such as the $Standard_Information Attribute and $File_Name Attribute. Each attribute contains metadata on every file and folder ever created, modified, accessed, or removed within NTFS.
The $Standard_Information Attribute contains metadata which includes the Date/Time values that are commonly referenced by the operating system. These are the values one would see when viewing the properties of a file within explorer.exe on a Windows system. The values are sometimes referred to as M.A.C.E. and include;
Modified Time: Time the folder or file was last modified
Accessed Time: Time the folder or file was last accessed
Creation Time: Time the folder or file was created
Entry Modified Time: Time the MFT entry of a folder or file was last modified (note: cannot be viewed from Windows explorer)
The $File_Name Attribute contains the name of the file. In Windows there will usually be entries in both the 8.3 DOS and Win32 naming format. The $File_Name Attribute also contains similar date/time (MACE) values as those found in the Standard Information Attribute. These values often reflect the creation time of the file or folder and do not change frequently. There are exceptions to this which I discuss later in this post.
Since the attribute values stored within the MFT are commonly used for generating a timeline during the analysis of Windows NTFS file systems, I started playing around with manipulating the metadata within it. If one wanted to cover one's tracks by doing so, it would be useful to use tools already available on the operating system. Such tools would ideally not track or log the commands run on the system. Irony is, the Windows PowerShell fits this description and has these capabilities. Dave Hull has noted this on his blog here.
By leveraging the Get-Item cmdlet in PowerShell, one can change some of the metadata within the $Standard_Information attribute and consequently the values shown in the properties of the file. For example;
(get-item malicious.dll).creationtime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastwritetime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastaccesstime=$(Get-Date "02/11/10 07:30")
To verify this change within the MFT, I used FTK Imager Lite to export the $MFT and AnalyzeMFT to parse and export the contents into CSV format. AnalyzeMFT is a free tool based on a commercial tool called MFT Ripper by Mark Menz. Once exported, the CSV file can be opened in your favorite spreadsheet program for easy filtering. The following screen shot shows the MFT record for the malicious.dll after I using the Get-Item cmdlet to change the dates (note the dates are stored in UTC format).
As you can see from the export, the problem with this tactic is the Std Info Entry Date (MFT Entry Modified Time) remains unchanged. Moreover, the FN Info ($File_Name Attribute) Dates also remain unchanged. Interesting enough, renaming the file will change both these values but doing so will change them to the current system time. The only real option I have been able to find is to change the system time prior to renaming. This can be accomplished by using the set-date cmdlet in Power Shell.
set-date -date 02/11/10Now we have the following export from the MFT.
set-date -date 07:30:00
rename-item malicious.dll notmalicious.dll
Unfortunately, this approach is far from perfect. The MFT Entry Modified Date within the $File_Name Attribute remains unscathed (I have not been able to figure out how to change this). Moreover, by default, a System Informational Event is logged within the Windows Event log of a change to the system time. Note the the date of the event however. There is a similar event logged for the time change.
Log Name: SystemOther considerations, include .lnk files being stored within the MFT due to the "Recent Document History" feature being turned on by default within Windows. This feature would create a malicious.dll.lnk file in the C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent folder on Windows Vista and 7 and consequently create an MFT entry for this file with metadata. This certainly would also be a red flag for the forensic investigator. Thus an attacker may want to turn this feature off prior to performing any tasks on the host. With PowerShell this can be accomplished by using the New-ItemProperty cmdlet to create the appropriate registry values and then by using Stop-Process cmdlet to force the reload of the explorer.exe shell for the current user.
Source: Microsoft-Windows-Kernel-General
Date: 2/10/2010 12:00:00 AM
Event ID: 1
Task Category: None
Level: Information
Keywords: Time
User: User
Computer: CompromisedHost
Description:
The system time has changed to ?2010?-?02?-?11T04:00:00.000000000Z from ?2010?-?04?-?07T18:49:38.251360400Z.
mkdir HKCU:\software\microsoft\windows\currentversion\policies\explorerThe explorer process reloading will also generate an information event log.
New-ItemProperty HKCU:\software\microsoft\windows\currentversion\policies\explorer -name norecentdocshistory -propertytype DWord -value 1
Stop-Process -name explorer -force
Log Name: ApplicationStopping the eventlog service prior to actions being taken on the compromised host may be prudent, but I will save the manipulation of other forensic timeline sources for a later post.
Source: Microsoft-Windows-Winlogon
Date: 2/11/2010 7:34:12 AM
Event ID: 1002
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: CompromisedHost
Description:
The shell stopped unexpectedly and explorer.exe was restarted.
Updated May 3, 2010:
Published a follow-up post on successfully changing the Entry Modified Date within the $File_Name Attribute thanks to an anonymous tip. The followup can be found here.
Nice post. Thanks for the data.
ReplyDeletevery educational post
ReplyDelete