"What time is it?"

Most people would have a single answer to this question. But a computer forensics examiner might have a few.

PST, EDT, CST, GMT, ZULU. Modified/Write, Access, Create, Record/Entry Modified. Do these mean anything to you?

Are you looking at the file times using the DIR of a command prompt, or are you looking at the file times using windows explorer, or some other GUI interface?

For an investigator dealing with computer evidence, how important is the time (clock) setting on the suspect computer?
How important is/are file times related to your evidence?

It might make or break any case that relies on placing the suspect at his computer at a specific time.

Also, be aware, that there are a lot of uncontrollable variables which may affect the times maintained for a file. The file system (FAT, NTFS, EXFAT, and any other anomoly that the operating system engineers might dream about). Also, the operating system itself might have an impact on the way file dates are maintained, and to what precision. Right down to the version of the OS might have a slight variance on how times are recorded/updated. And last but not least, which is the main jist of this article, is how your software interacts or maintains the file dates which the OS feeds it.

The way the OS maintains file dates, how it interect with your software, or rather how your software handles the data the OS is feeding it might be important to your case analysis. So you should at least have a crudimentary knowledge of how your software interacts with the OS file dates.

Take for example a case where you used a forensic suite to make an image of the drive. Then you identified file evidence and extracted evidentiary files for additional analysis, or presentation to legal or civil processes. Or in a corporate environment, you simply sit down at a subject computer, identify suspicious file(s) and copy them to your work medium. So far so good. Yes/NO/Maybe?

This suspect data might be: network log data, intrusion data, virus files, other captured network data. Or you are working a case where the evidence might be contained in a file on the suspect computer such as stolen proprietary (keys to the kingdom) data, kitty porn, an altered or stolen document. AND, you “carefully” and “forensically” copy or extract that file to your work drive. Really?

Again, let’s assume at this point, this data is ”carefully” extracted to your work medium thru the use of a forensic suite or a file copy operation. There are many instances where you might be copying, manipulating, analyzing a file which is, or contains evidence. You get the idea (I hope).

Now, let’s get to the timing of things. Here are two websites where you might find definitions of the file times.

https://docs.microsoft.com/en-us/windows/desktop/sysinfo/file-times   Microsoft filetimes defined.
https://cyberforensicator.com/2018/03/25/windows-10-time-rules   Time stamps defined has a really good article and color "graph" explaining timestamps. Which totally confused me.

Informative table Useful Table and article on timestamps. A little confusing, and needs magnification. But good.

The main subject of file time(s) is too complicated for this discussion. Depending on who you talk to, there are really eight(8) or nine(9) timestamps maintained by Windows. But we will only discuss three here. The three that are usually and more easily seen and identified within a normal examination. They are: Modified/Written, Created, Last Accessed time stamps. Otherwise known as the MAC times. To view the additional timestamps you will need to process the data with a good/reliable forensic suite like X-Ways.

As best as I have been able to determine, here are some laypersons (that’s the last time I will be politically correct) definitions of the three.

"Creation Time" (the ‘C’ in MAC time), is usually the time the file was created on that/this medium. More specifically, it is the time when the file was first created or written to the disk in its current location. Note, then, that if the file was copied from another source, "creation time" would be the time the file was copied to this location, rather than the time it was first created possibly years ago in a different folder. (Microsoft documentation roughly defines this as: the time the file was created.)

"Last Write/Modification time" (The ‘M’ in MAC time) may take on many different meanings. Practically speaking, it means when a program last made any changes to the file. Even though Microsoft defines it as last write time, if you consider this to be the last modification time, all the behavior of the operating system relative to this time stamp seems to be correct. Last modification would occur when you re-opened the document, edited it in some way, and wrote the result back to the disk. Or when you “wrote” it to a new location. This is the time Explorer and DIR show you. (Microsoft defines this as: the time that the file was last written to.)

“Last Access Time”: (The "A" in MAC time)
Defined by Microsoft: as Last Access Time

Each file and folder on an NTFS volume contains an attribute called Last Access Time. This attribute shows when the file or folder was last accessed, such as when a user performs a folder listing, adds files to a folder, reads a file, or makes changes to a file. The most up-to-date Last Access Time is always stored in memory and is eventually (sometime) written to disk within two places.

One problem for forensicators is that the last access time is updated on an hourly basis. Meaning, if the current last access is not more than an hour different from that on the drive, it won't be updated. Other problems exist pertaining to data streams.
From Microsoft:
"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."

In plain English, it is the last time the file was accessed in any fashion. Copied, printed, opened, moved, "typed". Generally, the NTFS system resets this "last access time" any time an action is performed on the file. And most activity on a file will cause this time to be reset (within prescribed limits). The examiner must test the operation of each software program used by both the suspect and by himself to determine if any of that software alters last access time. However, last access is ONLY updated on an hourly basis. (What you say!)


Now, another fly in the access ointment. Even though the file access is updated on an hourly basis, it appears (in my own tests) that alternate data stream accesses are updated immediately. See the two time segments below. The first was taken seconds before file accesses. The second was taken after the files were accessed. Guess what, the file date was unchanged, but the data stream access was updated.

Pre access notice the identicle seconds and milliseconds on file and its :data streams this will be important in the next step

dir2_setup.bat               10/23/2019 06:26:40:053a EST A.....
dir2_setup.bat:ads_hash.txt  10/23/2019 06:26:40:053a EST .adata

test1                        10/23/2019 06:26:40:069a EST A.....  test copy #1
test1:ads_hash.txt           10/23/2019 06:26:40:069a EST .adata

test2                        10/23/2019 06:26:51:379a EST A.....  test copy #2 11 seconds later
test2:ads_hash.txt           10/23/2019 06:26:51:379a EST .adata

Post access by a hashing program, notice the file times unchanged (less than an hour), but data stream milliseconds updated. HA you say.

dir2_setup.bat               10/23/2019 06:26:40:053a EST A.....
dir2_setup.bat:ads_hash.txt  10/23/2019 06:39:13:859a EST .adata

test1                        10/23/2019 06:26:40:069a EST A.....
test1:ads_hash.txt           10/23/2019 06:39:13:875a EST .adata

test2                        10/23/2019 06:26:51:379a EST A.....
test2:ads_hash.txt           10/23/2019 06:39:13:875a EST .adata
Here is another example. Can you tell me why, within the two hour access upate period, the last accss of the ADS was updated, twice, but not the primary file last access.
C:\TMP>mdir Signature1.TXT
   Signature1.TXT                    35    12/22/2019 11:57:31:218a EST A.....
   Signature1.TXT:ads_hash.txt      291    12/22/2019 11:57:31:218a EST .adata

C:\TMP>type Signature1.TXT    (not shown for space consideration)

C:\TMP>mdir Signature1.TXT
   Signature1.TXT                    35    12/22/2019 11:57:31:218a EST A.....
   Signature1.TXT:ads_hash.txt      291    12/22/2019 11:58:51:048a EST .adata

C:\TMP>type Signature1.TXT   (not shown for space consideration)

C:\TMP>mdir Signature1.TXT
   Signature1.TXT                    35    12/22/2019 11:57:31:218a EST A.....
   Signature1.TXT:ads_hash.txt      291    12/22/2019 12:06:52:802a EST .adata
Could this time difference be important in a data exfiltration case?

Fly in the ointment (no 2).
If you are using the DIR command be aware of this very important information regarding the Time Zone offset from GMT with relation to the current time (standard, or daylight saving) that the computer is set to, and whether you are running standard time, or daylight saving time, and when (what month) you are currently running the DIR command.

A file with dates and times say on January 1 with a local time of 07:34 AM. will show up correctly in the Explorer GUI listing. However, that same time when viewed using the CMD prompt DIR command shows a time of 08:34. The DIR/CMD prompt does NOT adjust for any Daylight or Standard time offset.

Case in point, see the difference between a DIR command, and a properly designed command line program, which simulates the GUI representation of the time. The file time with DIR is off by one hour. BUT BUT BUT. These commands were run during June. Which means the internal time zone setting of the computer was for Daylight Savings time. If the same DIR command was run on January 1, the displayed time would be correct. Go figure. (yes, you go figure. I know whats happening, do you?). Take my word for it, or not, the Explorer view shows the 07:34 time of the file.

C:\TMP\TEST_USB\D1>dir ZERO_BYTE.TXT
 Directory of C:\TMP\TEST_USB\D1
01/01/2020  08:34 AM                 0 ZERO_BYTE.TXT

C:\TMP\TEST_USB\D1>diskcat ZERO_BYTE.TXT
Started Fri Jun 05 20:48:34 2020 GMT, 16:48 Eastern Standard Time (EST/EDT:UTC-4*)

C:\tmpe\TEST_USB\D1\ZERO_BYTE.TXT       0 01/01/2020 07:34w EST

But you say, on our computers, last access is turned off by default. True, but it can be reset easily by adjusting a registry key:

Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem 
Name:     NtfsDisableLastAccessUpdate 
Type:     REG_DWORD 
Value:    1  (A value of 1 turns last access update off.) 
Value:    0  (Sets last access update to on. Access dates are updated)

BE ADVISED THAT REGARDLESS OF THE SETTING OF THE KEY, PROGRAMS CAN ALTER THE LAST ACCESS UPDATE AT WILL. THE DEFAULT PARAMETER IS MERELY A GUIDE THAT WINDOWS USES TO SET ITS MAC DATE/TIMES.

I tell you personally, if I was in a corporate environment, I would have last access turned on for all my computers. In the case of problems, I would like to know when items were accessed. (like someone copies a sensitive file to a thumb drive). You will see arguments that last access slows down computer operation. Yes, this slowdown will be noticed when hell freezes over.

Speaking of last access. I originally thought that when Windows installed software, it defaulted to set the last access time to a :000 milliseconds. Seems reasonable. But in my tests on my WIN10 machine, in the \WINDOWS directory, of 150,000+- files, I only found 150 with the :000 set. And these were inconsequential unused files. I wondered why only inconsequential files had :000 access milliseconds. Maybe just normal percentage, if my math is correct ( I ran out of fingers), 150 is in fact, 1/1000th of 150,000.

VIRUS CHECKERS
Then I realized, that my popular virus checker, which ran each nite at 2300, altered the access time. I was really dissapointed that the virus checker, DID NOT reset the last access to its original value. In instances, for security reasons, that the last access would become important to see what files may have been touched, or copied the last access would become important. But the virus checker altered that time. I complained to the virus check company but have not yet had any response.
So, at this point, I can't confirm or deny (sounds like a government coverup), that on initial install, Windows pre-sets the last access to :000 milliseconds. I will attempt to locate a machine with last access turned off, and determine if my suspicion is correct about initial install. Bottom line, on last access reset, test it for yourself. DAH!

VIRUS CHECKERS CONTINUED
Another thing which bothers me no end. Is that when I insert a thumb drive into the computer, depending on the type of file on the thumb, the current virus checker, checks certain files on the drive, thus again altering the last access of those files. I've tried to find (if anywhere) in the virus checker setup, where I can turn off or exempt specific drives from being checked. And so far have not had any luck. So be aware, that virus checkers are not access date friends.

Now, let’s look at an example of a file (copy) operation.

Filename                             Create		          Modified/Write        Access
original_source_file_drive1          03/15/2019 10:09:16c  03/15/2019 10:11:29w  03/27/2019 15:07:08a
copy1_file_same_drive                04/15/2019 18:03:19c  03/15/2019 10:11:29w  04/15/2019 18:03:19a
original_source_after_copy1          03/15/2019 10:09:16c  03/15/2019 10:11:29w  04/15/2019 18:03:19a
copied_to_drive2_thumb               04/15/2019 18:09:51c  03/15/2019 10:11:29w  04/15/2019 18:09:51a

Just for reference, after the file was initially copied in step 2. Notice only the access of the source was updated to reflect the file copy time of
04/15/2019 18:03:19a.
The same access time set to the destination copy1_file_same_drive which is expected. The access time of the original was updated to reflect the time of the first copy. (18:03:19a) Which now matches the access time of the copy process.

Line 1 is the file data when it was first extracted as evidence to work on. We are assuming the process which got it to that drive location, maintained its original MAC times. It’s your responsibility to find software which will do this.

Then line two we copied the original evidence to a work folder on our drive. Notice the create time was altered to reflect the time we copied it to our work location, and the access on line 2 was also updated to reflect when this copy operation was performed. Two (create, access) of three file times are altered/adjusted in a simple copy operation.

Notice the creation time is changed. Even though it is the same drive, different folder, it is now "CREATED" in this new work location. So we get a new create time. How would this fly in an evidence situation.

Now, the file copied to a completely different medium (line 4). Let’s say, after we performed the analysis, we decide to copy it to a thumb drive for delivery as evidentiary disclosure.

Copying to a completely separate drive resulted in two times being updated. But, notice last write/modified still remains as the original. Why, because we did not modify the file. We just copied it. NOT modified, the modified or write time was not altered, but in both "copy" cases the create time was updated. This is how you get a file that seemingly was created after it was modified. An OxyMoron. This is a source of confusion. How a file can be created after it is modified? The answer lies in the way the operating system maintains its timestamps. Try explaining that a file was modified before it was created to a jury.

In other words: when an original file is copied (using the copy command, File Manager, or one of many “Forensic” copy programs I have tested) the original "last write/modification" time on the new file is unaltered. However, the creation time is, by definition, the current time of the copy, and the last access time is also altered depending on the registry setting.

Now explain this:

Original file’s access after first operation:         04/15/2019 18:03:19a 
Current access of the COPIED files last operation:    04/15/2019 18:09:51a

A six (6) minute difference of the original access to current access. And why are/is the access date of the original file NOT adjusted to 18:09 during the second copy? Because the 2nd copy took place less than an hour after the first operation. So the operating system didn’t think it necessary to update the access time.

Now that you are thoroughly confused about file times, let’s discuss something else.

Documenting file dates with an inventory

Because file dates may become so important and controversial. At the earliest possible point during the analysis the investigator should create an inventory of all files on the system with their three dates. Be sure the file dates of your files presented to opposing parties is accurate, and be prepared to explain any discrepancies between the files on the original drive, and the file dates on the drive you present to the opposition.

Unfortunately, I can’t find any way to get Windows Explorer to create a nice neat listing of all the file dates on a computer. But I wouldn’t want to use Explorer anyway. Find a product which can export and/or copy the file dates to/in a file which can be saved, and produced as evidence. I can suggest a few, but I’ll leave that as a homework assignment. Know what dates your software changes or maintains when it creates discovery data for your case.

Final things to think about:

Accepting the premise that access data is turned on. Otherwise this logic fails.
Lets say, the person only copied files, but didn't view them or otherwise open them which would normally take some "human" time.

dir2_setup.bat                10/23/2019 06:26:40:053a EST A.....
dir2_setup.bat:ads_hash.txt   10/23/2019 07:00:07:371a EST .adata
test3                         10/23/2019 07:00:07:371a EST A.....
test3:ads_hash.txt            10/23/2019 07:00:07:371a EST .adata
Notice again that because the copy operation was within the hour, the original access (of dir2_setup.bat) was unchanged. (see above the original listing displaying the dir2... dates). BUT, during the copy operation the data stream was updated. A few thoughts. First, thru unscientific testing, it appears that no matter when an activity is performed, if, and this is a big if, a data stream was attached to a file, it is ALWAYS updated to the current access time. However many (if not most) computers have last access turned off. A real error in my opinion.

Next, if you are looking to show a file was only copied and not otherwise "viewed" which would have taken some time, you might look at the access times. Assuming and this is a big if. That if it was "opened" for view or print, the access time would be more substantial than the access time it takes to copy a file. The copy would take milliseconds or minimal seconds. While a human interation might take much more time. Purely unscientific logic, but might raise some questions about how/why/when the file was actually accessed. AND AND AND, this time difference is solely dependant on two facts. First that the access update is on, and second that there is an outside chance that the particular file had a data stream associated with it. In most cases not likely. But just for #@%&* and gigles. Take a look at your own internet downloaded graphic/picture files, and see if they have data streams associated.


For FAT32 file systems which are still seen on some smaller and older thumb drives, for the last access date and time field, only the date is maintained. The last access time on FAT32 file systems is always 00:00.

Programs can generally alter the file times at will. And file times may be very important to your case. And you may be asked to define and explain file times which you provide as evidence in court.

Setting/resetting the last access time could have evidentiary consequences, and the user should be certain that a sound explanation is available.

Now, here is the file date structure of a file being copied with a reliable forensic copy program. Notice no times were altered during the process.

Filename                 Create		           Modified/Write        Access
Original_file            03/09/2019 11:02:10c  03/29/2019 14:32:39w  04/12/2019 15:46:39a
Copy1_to_same_drive      03/09/2019 11:02:10c  03/29/2019 14:32:39w  04/12/2019 15:46:39a
copy2_to_2nd_drive       03/09/2019 11:02:10c  03/29/2019 14:32:39w  04/12/2019 15:46:39a
Current_original_file    03/09/2019 11:02:10c  03/29/2019 14:32:39w  04/12/2019 15:46:39a

I think we have reliable copies to two destinations, while maintaining the original date structure of the original, and both copies.

One final thought:
If you see a timestamp like this

File            03/09/2019 11:02:10:000c  03/29/2019 14:32:39:000w  04/12/2019 15:46:39:000a
with any or all of the milliseconds listed as 000. You might want to question either the program which is listing the 000's, or how they got to be that way.

Some timely (pun intended) input was received from Mark Menz, and an excellent powerpoint of his.

For those adventurous souls who wish to test their forensic suites or stand alone software I have placed here two zip files of a 1GIG image. They contain files with long filenames > 255 characters, and files which contain Alternate Data Streams, (ADS). You can download them, they are about 3 1/2 meg each (compressed). Unzip to the image and mount with your suite. Then see if you can: export the ADS, LFN's, Hash the files, etc.. Then compare and confirm your results with what is really available.
Here are the zip files.
1Gig DD image
1Gig FTK image
Test data  containing about 30 files, in a self extracting executable

DMARES.COM