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 .adataHere 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 .adataCould 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 .adataNotice 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:000awith 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