Understanding Critical Windows Artifacts and Their Relevance During Investigation: NTFS Timestamps

June 20, 2016 by

Security Ninja

In this article, we will learn about critical Windows artifacts, what they mean, where they are located in the system, what can be inferred from them and how can they help in actual during the investigation. This will be a series of articles and in Part 1, we will learn about the NTFS timestamps which an investigator should know before analyzing any of these artifacts.

NTFS Timestamp basics

NTFS stores four types of time for a particular file namely:

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

• File Creation Time
• Last Access Time
• Metadata Last Modification Time
• Creation Time

For example, I created a sample text file 'Testing' and we can see that the created, modified and access time all are same which depicts the creation of a new file on a system.

After about 3 minutes, I added a line in the file and the modified time is changed as expected. Did you notice anything not obvious in the below time formats? Good if you have spotted that the 'Last Access Time' is not changed (Form Windows 7+ Access Changed will not be recorded.)

Another important point to notes that NTFS stores files in UTC format which means they are not affected by time zone difference and even daylight savings.

So as you can see, there are some general rules though which the timestamp revolved along with a file. Possible Scenarios are listed below

1. File Creation: When a new file is being created, the four timestamps changed.

   

2. File Move: Whenever a file is moved within a local volume, only Metadata time change. Rest all times remain constant. An important point to note here is that while doing a 'cut-paste,' OS retains the creation time of the original file. Below is the file which I 'cut-paste' from Desktop to Documents. As you can see all the three times are inherited.

   

3. File Copy: When a file is being copied over even on a local volume, Creation Time and Access Time are changed. However, Modified Times remain same. This is an important point to note as this scenario can depict whether the file is being copied over to let's say target system by a scheduled task. For example, what I did here is that I copied the same testing file from Documents back to Desktop and as mentioned above, Creation and Access time got Changed.

   

4. File Deletion: When a file is deleted, none of the times were changed.

   Now since we have seen the four most common scenarios, let bring a new Volume + Filesystem to understand the behavior in that case. I will be using a FAT USB and will perform both File Move and File Copy operation.

5. File Move: When we make a file move over a volume, only 'Access Time' is changed. As we can see below, I have just moved the file 'Testing' from Desktop to USB. Only 'Access Time ' got changed but wait, that only a date where the timestamp. It turns out that FAT filesystem does not have an accessed timestamp and can only show you accessed date. Keeping this change, I mind we can easily say that file is being moved over to USB

   

6. File Copy: As stated above, copying a file will change all time's but modification time. So whenever we see a file whose modification time is earlier than the creation time, take it like the file has been copied. For example, in below scenario, I have copied the file Desktop to USB, and it can be seen that modification time is earlier than creation time.

   

Another thing that I would like to point out is that these different time's value are associated with $STANDARD_INFORMATION and can be easily changed by the attacker. When this happens, we say that the file has been time-stamped. There is another set of these timestamps associated with $FILE_NAME and these values cannot be easily changed and can be used to figure out such techniques.

Wait what are these $STANDARD_INFORMATION and $FILE_NAME? Every Object in NTFS is given a FILE record and is saved in MFT. File Record contains attributes that hold metadata about the file. Both $STANDARD_INFORMATION and $FILE_NAME are attributes of a file, and there has to be at least one each for every file. There can be more than 1 $FILE_NAME for a file provided the name is too long to store (more than characters ), and a corresponding MS-DOS-compatible short name is created. Both these attributes are referenced in the MFT, and they have their unique signature value. $STANDARD_INFORMATION( x10 )and $FILE_NAME ( x30 ). $FILE_NAME is not easy to be modified with win32 API and thus, can be used to detect timestamping of a file.

The operations we described above of $STANDARD_INFORMATION can be mapped to $FILE_NAME provided these constraints

• All four type of times are changed in FILE_NAME when a file is moved over a volume
• All four type of times are changed in FILE_NAME when a file is copied.

So we can see that if the $FILE_NAME creation time is after $STANDARD_INFORMATION time, then it is an anomaly.

As stated above attackers can use tools such as 'timestamp' to backdate a file to hide their malicious programs under critical locations like system directories. However, we can use tools such as analyszeMFT.py (https://github.com/dkovar/analyzeMFT) to compare the $Standard_Information and $File_Name Time. It has the following syntax:

analyzeMFT.py -a –f <MFT_File> -o <OUTPUT>

Whenever we see the $File_Name Creation Date is 'after' the $Standard_Information Creation Date, it means the file has been timestamped.

In the next article, we will cover some other interesting artifacts in Windows like prefect file, shim cache, am cache, etc.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

References

• File System Forensic Analysis by Brian Carrier
  
• https://github.com/dkovar/analyzeMFT