Date forgery analysis is one of the most common digital forensics investigation tasks we encounter. For instance, the suspect backdates a document and tries to pass it as if it were an older document. In the process, however, he usually makes a mistake, overlooks metadata or surrounding evidence that could be used by a computer forensics expert to reveal what happened. In this post, we will look at such a scenario and one of the artifacts which can be utilized during date forgery analysis.
File systems are used to manage how information is stored on and retrieved from computers. In order to do what they do, they store a lot of information about the files such as the file name, timestamps etc. We will be looking at the “Creation time”, “File altered time” and “File accessed time” fields in the $STANDARD_INFORMATION attribute in the New Technology File System (NTFS). These fields are displayed to the end user by the operating system and are the fields that are typically altered by forgers. I chose NTFS for this post because it is one of the most popular operating systems (used in most Windows systems) and it has high timestamp resolution, which can be quite useful during date forgery analysis — we will talk more about this shortly.
Note: The Master File Table (MFT) in NTFS stores additional timestamps such as the “MFT altered time” field in the $STANDARD_INFORMATION attribute as well as the “File creation time”, “File modification time”, “MFT modification time” and “File access time” fields in the $FILE_NAME attribute. These fields can also be invaluable during date forgery analysis and will be covered in another post.
Example Date Forgery Analysis Scenario
File system timestamps are not designed to be manipulated by the end user — besides legitimate updates performed by the operating system when the files are copied, edited etc. However, a resourceful user can modify these timestamps using various methods. One of these methods — perhaps the most popular — is using software applications designed to alter file system timestamps.
Let’s start with the following sample file:
As seen in Figure 1, the original file has the following local timestamps (Pacific Time):
|Date Created:||1/31/2014 10:29 AM|
|Date Modified:||1/31/2014 10:38 AM|
|Date Accessed:||3/25/2014 2:50 PM|
The Windows Explorer screenshot in Figure 1 shows timestamps with minute-precision. Please see Figure 2 below (screenshot of File Properties dialog box) for the timestamps with second-precision.
Using a timestamp modification tool, I changed the creation date to August 20, 2013 9:27:14 AM. I used SKTimeStamp 1.3.4 during this exercise, but there are numerous tools that do the same.
Looking at the properties of the file, it appears — at least to the untrained eye — that the modification has worked. However, what Windows Explorer displays to the end user is quite limited.
NTFS Timestamp Resolution
In an NTFS file system, timestamps are stored as 8-byte file time values which represent the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 (MSDN Article on File Times). Consequently, NTFS timestamps have 100 nanosecond (0.1 microsecond) precision. When we look at the underlying data, we see that the “Creation time” field for our file was populated as “01CF1EB25D98BDC8” before the modification (see Figure 4 below).
When the 8-byte file time value “01CF1EB25D98BDC8” is converted to a date, the timestamp with full precision is found to be 01/31/2014 18:29:24.0336840 (UTC). See Figure 5 below for the other timestamps with full precision.
Note the underlined 7-digit number following the seconds in Figure 5. These digits represent the 0.1 microsecond resolution stored in the NTFS file system.
After the timestamp manipulation, the updated creation timestamp has lost its resolution beyond seconds (see Figure 6 below). In other words, it was truncated to second-precision.
It was expected that timestamp resolution beyond seconds would be lost since the software I used operates at second-precision (see Figure 7 below). I have tested various additional software tools1 to perform the same timestamp manipulation and found that all of them truncated the altered timestamp to second-precision. Additionally, I found that some of the software tools (e.g. AttributeMagic 2.1) truncated all three timestamps even though I changed only the creation date.
On a related note, even most mainstream computer forensics software do not display timestamps beyond second-precision in their graphical user interface (GUI) — see Anders Thulin’s article on Forensic Focus for his analysis on how computer forensics tools interpret and translate timestamps. Needless to say, even when the timestamps are not fully displayed in the GUI, it is possible for the computer forensics expert to analyze the underlying file system and extract the full timestamps.
Why Is This Significant for Date Forgery Analysis?
When a computer forensics expert reviews a file that was known to have been created and lived on an NTFS file system, seeing a truncated timestamp can be interpreted as a red flag. Considering that the 7 digits beyond the seconds provide 10 million possibilities, the probability of a randomly created file legitimately having no 100-nanoseconds beyond the seconds in its timestamp (i.e. timestamp ending with “.0000000”) would be extremely small. This can be a good starting point in date forgery analysis.
Additionally, analyzing timestamps with full precision can be used for other investigative tasks such as determining which files might have been copied to an NTFS file system from a flash drive. For example, the timestamp resolution for the FAT file system is as follows:
|Creation Time||10 milliseconds|
|Write Time||2 seconds|
|Access Time||1 day|
Consequently, when files from a flash drive formatted with the FAT file system are copied to an NTFS file system, these files are likely to stand out among the other files on the NTFS file system due to the difference in their timestamp resolution. For example, Figure 8 below shows the timestamps of a file created on a FAT-formatted flash drive on 8/11/2014 at approximately 11:27 AM (PDT). The file was then copied at approximately 11:31 AM (PDT) using the standard copy mechanism in Windows Explorer to an NTFS-formatted drive.
Please note the following:
- The UTC timestamps are not shown on the FAT system since FAT stores timestamps in local time.
- Underlined sections on the left are consistent with the timestamp resolution on the FAT file system (i.e. 10 ms for the creation time, 2 seconds for the last modification time and 1 day for the last access time).
- When the file was copied to the NTFS file system, as expected, the creation and last access timestamps of the new copy were updated to reflect the time when the file was copied, while the last modification timestamp was preserved. The updated timestamps have the 100-nanosecond NTFS timestamp resolution while the preserved last modification timestamp appears truncated.
In the context of date forgery analysis, the truncated last modification timestamp of the file in Figure 8 can indicate that the timestamp was altered, or that the file was copied to an NTFS file system from another file system with lower timestamp resolution.
Even though some computer forensics tools and date converters do not display NTFS timestamps to their full resolution, performing forensic analysis at the 100-nanosecond resolution can be beneficial during date forgery analysis. Full resolution timestamps can be obtained in numerous ways such as by reviewing the underlying raw data, or programmatically querying the timestamps.