Thursday, April 15, 2010

An Aside Note on Last Access Time Values

Dave Hull had brought to my attention that Windows Vista and Windows 7 has the Last Access Time attribute disabled by default. I verified that Windows Server 2008 also has this feature disabled. To enable via the registry (note a restart is necessary):
This did not prevent me from manipulating the $MFT attributes with PowerShell, but I did notice some strangeness when accessing files via explorer.exe. Specifically, the Last Access time does not always get updated even with this setting enabled. After some searching around I found this article on Microsoft TechNet. To quote the relevant sections;
The Last Access Time on disk is not always current because NTFS looks for a one-hour interval before forcing the Last Access Time updates to disk. NTFS also delays writing the Last Access Time to disk when users or programs perform read-only operations on a file or folder, such as listing the folder’s contents or reading (but not changing) a file in the folder. If the Last Access Time is kept current on disk for read operations, all read operations become write operations, which impacts NTFS performance.
NTFS typically updates a file’s attribute on disk if the current Last Access Time in memory differs by more than an hour from the Last Access Time stored on disk, or when all in-memory references to that file are gone, whichever is more recent. For example, if a file’s current Last Access Time is 1:00 P.M., and you read the file at 1:30 P.M., NTFS does not update the Last Access Time. If you read the file again at 2:00 P.M., NTFS updates the Last Access Time in the file’s attribute to reflect 2:00 P.M. because the file’s attribute shows 1:00 P.M. and the in-memory Last Access Time shows 2:00 P.M.
I was able to confirm this behavior by altering the system time prior to accessing a file. I thought it was noteworthy since the Last Access Time may not be completely accurate. While the forensic impact of this could be debated, it should at least be considered during an investigation.

Wednesday, April 7, 2010

Tampering with Master File Table Records

I have been spending some time reading File System Forensic Analysis by Brian Carrier which is considered by many to be the primary resource on the subject of file system forensics. Consequently, I began thinking of ways to tamper with the metadata stored within the Master File Table (MFT) of NTFS formatted drives. In NTFS everything is a file and the MFT stores information on these files. Analyzing the MFT is one way of establishing a forensic timeline of all file and folder changes on the system being investigated.

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/10
set-date -date 07:30:00
rename-item malicious.dll notmalicious.dll
Now we have the following export from the MFT.

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:      System
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
The system time has changed to ?2010?-?02?-?11T04:00:00.000000000Z from ?2010?-?04?-?07T18:49:38.251360400Z.
Other 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.
mkdir HKCU:\software\microsoft\windows\currentversion\policies\explorer
New-ItemProperty HKCU:\software\microsoft\windows\currentversion\policies\explorer -name norecentdocshistory -propertytype DWord -value 1
Stop-Process -name explorer -force
The explorer process reloading will also generate an information event log.
Log Name:      Application
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
The shell stopped unexpectedly and explorer.exe was restarted.
Stopping 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.

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.