Active Directory and ADTimeline(1)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- I added PC 1 to the example domain, but I could not find it on ADTimeline timeline.
- I created an Alice account and added it to the Domain Admins group. Creating an Alice account and updating adminCount was confirmed on the timeline.
- Removed Alice account from Domain Admins. In the timeline, records related to Domain Admin were recorded.
- I created a Bob account in the Example domain, and then deleted the Bob account.
----------
[Note]Please be aware that the verification method not be sufficient.
Continuing from last week, I would like to check what can be investigated by using ADTimeline.
In the test environment there are two computers DC1(Windows Sever 2019) and PC1(Windows 10 1809). Please note that there is only one DC, I have not tested the case where there are multiple DCs. ADTimeline is running on DC1.
Add PC1 to domain Example.
In the output of ADTimeline, the corresponding record could not be found. Whether changes to computer accounts will be recorded will be tested separately in the future.
Next, create an Alice account on the Example domain.
The record when Alice was created could be confirmed on ADTimeline.
ftimeLastOriginatingChange : 2019-02-10T10:26:12Z
Name : Alice
pszAttributeName : primaryGroupID
ObjectClass : user
DN : CN=Alice,CN=Users,DC=example,DC=local
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : alice
dwVersion : 1
WhenCreated : 2019-02-10 10:26:12Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1104
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 24624
usnLocalChange : 24624
Add the Alice account to the "Domain Admins" group.
In the output of ADTimeline, I could not find a record that added Alice to the "Domain admins" group.
When you add the Alice account to the Domain Admins group, Alice's "adminCount" is updated. You can check that record with the output of ADTimeline.
ftimeLastOriginatingChange : 2019-02-10T10:34:41Z
Name : Alice
pszAttributeName : adminCount
ObjectClass : user
DN : CN=Alice,CN=Users,DC=example,DC=local
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : alice
dwVersion : 1
WhenCreated : 2019-02-10 10:26:12Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1104
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 24647
usnLocalChange : 24647
<2019/02/11 add>
Traces of adding Alice to the Domain Admins group. I missed that timestamp, thank you for the comment!
ftimeLastOriginatingChange : 2019-02-10T10:38:49Z
Name : Domain Admins
pszAttributeName : member
ObjectClass : group
DN : CN=Domain Admins,CN=Users,DC=example,DC=local
ObjectCategory : CN=Group,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : Domain Admins
dwVersion : 2
WhenCreated : 2019-01-20 19:20:35Z
Member : CN=Alice,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-10T10:28:38Z
ftimeDeleted : 2019-02-10T10:38:49Z
SID : S-1-5-21-1490397982-2793378994-64436834-512
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 24648
usnLocalChange : 24648
Metadata #2 – The ephemeral admin, or how to track the group membership – Once upon a case…
ftimeCreated the time when the member has been added for the first time.
<2019/02/11 /add>
Log on to PC1 with "example\Alice" account.
In the output of ADTimeline, related records could not be found.
Remove the Alice account from the "Domain Admins" group.
In the output of ADTimeline you can see the records related to Domain Admins.
ftimeLastOriginatingChange : 2019-02-10T10:38:49Z
Name : Domain Admins
pszAttributeName : member
ObjectClass : group
DN : CN=Domain Admins,CN=Users,DC=example,DC=local
ObjectCategory : CN=Group,CN=Schema,CN=Configuration,DC=example,DC=local
SamAccountName : Domain Admins
dwVersion : 2
WhenCreated : 2019-01-20 19:20:35Z
Member : CN=Alice,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-10T10:28:38Z
ftimeDeleted : 2019-02-10T10:38:49Z
SID : S-1-5-21-1490397982-2793378994-64436834-512
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 24648
usnLocalChange : 24648
Log on to PC again with "example\Alice" account. For this logon, Alice is not a member of the Domain Admins group.
I could not find related records in ADTimeline.
Several items I tested were confirmed with ADTimeline. However, I have not tried other tests, such as deleting users.
I created a Bob account in the Example domain. Then delete the Bob account.
ftimeLastOriginatingChange : 2019-02-10T02:42:20Z
Name : bob
DEL:36e610eb-61ef-4fb8-9f15-4612be60d2ae
pszAttributeName : accountExpires
ObjectClass : user
DN : CN=bob\0ADEL:36e610eb-61ef-4fb8-9f15-4612be60d2ae,CN=Deleted
Objects,DC=example,DC=local
ObjectCategory :
SamAccountName : bob
dwVersion : 2
WhenCreated : 2019-02-10 02:39:14Z
Member :
ftimeCreated :
ftimeDeleted :
SID : S-1-5-21-1490397982-2793378994-64436834-1105
pszLastOriginatingDsaDN : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=example,DC=local
uuidLastOriginatingDsaInvocationID : c9e22352-ca47-436a-aeb2-38228298896d
usnOriginatingChange : 28709
usnLocalChange : 28709
While testing the Bob account I noticed that the time in the test environment was incorrect. The Bob account will be tested again.
I will continue testing.
Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC
Reference URL:
Metadata #0 – Metadata, what is it and why do we care?
Active Directory and When-Changed (2)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- I got some comments on Twitter about the previous contents. So I did a simple test using DCshadow.
- Updates of SIDHistory etc. are explained in detail on the DCshadow web.
I have not tried anything new in this blog. - I tried creating a timeline using ADTimeline.
----------
[Note]Please be aware that the verification method not be sufficient.
Check the properties of "Alice", "SIDhistory" is not set.
Using DCshadow, set "SIDhistory" to Alice.
A value has been set for Alice's SIDHistory and "whenChanged" has been updated. The attribute of Alice has changed, but event ID 4738 is not recorded.
Using PowerShell, delete Alice's SIDhistory.
Set-ADUser -Identity alice -Remove @{SIDHistory='S-1-5-21-1490397982-2793378994-64436834-500'}
This operation which does not use DCshadow can be confirmed by event ID 4738.
Use DCshadow to set the time stamp for whenChanged.
You can confirm that the time stamp specified in "whenChanged" is set.
If an attacker did not change the timestamp of whenChanged, can I track updates that are not recorded in the event log?
I tried ANSSI-FR/ADTimeline. I just ran the script and I am not used to this timeline format yet.
I was able to check the timestamp of the record that deleted sIDHistory on the timeline.(This operation is recorded in the event log)
However, I could not find an update of sIDHistory by DCshadow.
The sample ADtimeline that I created can be downloaded from here.
I will continue testing.
Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC
Reference URL:
https://www.ssi.gouv.fr/uploads/2019/01/anssi-coriin_2019-ad_timeline.pdf
Active Directory When-Created and When-Changed (1)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- Active Directory accounts have "When-Created" and "When-Changed" attributes.
- I am checking when those attributes are updated. However, I just started to verify.
- When user Alice logon, the "lastLogon" attribute is updated, but "whenCahged" is not updated.
- The following information is in the Microsoft article. Please refer to the reference URL for details.
・The Update Frequency of the "When-Created" attribute is "When the object is created."
・The Update Frequency of "When-Changed" attribute is "Each time the object is changed." - 2019/02/02 ADD
・Some attributes are not replicated between DCs. For example, "lastLogon" is not replicated.
・The System Flags item has the NR*1 flag bit. [MS-ADTS]: System Flags -
When-Changed and when-Created are pushed by the DC doing the modification / creation. WhenChanged can be modified by DCShadow. When-created only at object creation. A replication of WhenCreated implies an object creation. If a conflict happens the object is marked as duplicate.
— Vincent Le Toux (@mysmartlogon) January 29, 2019
----------
[Note]Please be aware that the verification method not be sufficient.
Create test account Alice on AD. Compare the date and time of the event log with the date and time of "When-Created", and confirm that they match.
Log on to the domain with the Alice account and check the timestamp. Several logon date properties were added to the display.
When Alice first logged on to the domain, "When-Changed" was updated.
Is this update affected by updating attributes such as "lastLogon"? Or, it is "<not set>" at the time of account creation Is it the result of setting "lastLogonTimestamp"?
When Alice logon, the "lastLogon" attribute is updated but "whenCahged" is not updated. (I have not confirmed the update of Last-Logon-Timestamp. LastLogonDate is the result of decoding lastLogonTimestamp?)
I repeated logon and logoff several times, but "when-Changed" was not updated.
Next test,
I added the Alice account to the Domain Admins group. This operation did not update "When-Changed" of Alice account.(It was not updated by this operation, but it will be updated with related events.)
After adding Alice to the Domain Admins group, I did Logon and LogOff, but "when-Changed" was not updated.
While I was trying other tests, I noticed that "When-Changed" was being updated. So I confirmed the time when "When-Changed" was updated in the event log.
Perhaps, I think that it is an ACL update event of "AdminSDHolder". I was forgotten to confirm the attributes of "adminCount" beforehand.
EID 4738 is also recorded in the event log, but I could not identify which attribute was changed.
I will continue testing.
Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC
Reference URL:
https://adsecurity.org/?p=1906
*1:FLAG_ATTR_NOT_REPLICATED or FLAG_CR_NTDS_NC, 0x00000001
RDP and UserAssist (Win 10)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- Did you read "Daily Blog # 602: Solution Saturday 1/19/19"?, I read it and tested it on RDP connection.
- I ran the program via RDP and looked up the result of UserAssist. There was nothing new in my test. ;-)
----------
I used two Windows 10 to test RDP. The destination of RDP connection is Windows 10 ver 1809.(192.168.1.16).
In the MSTSC setting, assign F: drive.
Connect to the remote system with RDP and browse F drive. There is an Autoruns tool on the F drive. Run Autoruns64.exe and Autorunsc64.exe.
Load NTUSER.DAT into the Registry Explorer. (I'm very happy to be able to load the registry with Live!! :-)
You can check that Run Counter and Last Executed are recorded.
I read the article of "No run counts in UserAssist" and tested the execution of Task Scheduler.
As Matthew Seyer wrote in the article, Run Counter and Last Executed were not recorded.
Also, we tried executing the GUI program from CMD described on Twitter of Maxim Suhanov. Run Counter and Last Executed were not recorded.
There was nothing new in my test. ;-)
Thanks to everyone who has published validation results about UserAssist.
Verification environment: Windows 10 1809, Time zone UTC
Reference URL:
@HECFBlog Got the "Run count" field (in the UserAssist value) set to 0 when a GUI application was first launched from a command line. This field in an existing entry is not changed if a GUI application is launched from a command line. 1/2
— Maxim Suhanov (@errno_fail) January 19, 2019
Task Scheduler Registry key and "Last Run Time"
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- "Last Run Time" is displayed in the GUI of Task Scheduler, this value is saved in the registry.
- Several timestamps are stored in the "Dynamicinfo" value.
1.Task File Created
2."Last Run Time"
3. Action completed or Task Completed ??
---
I received a question from my colleague while testing Amcahce.
『The Task Scheduler GUI displays "Last Run Time", but where is this timestamp stored?』
"Last Run Time" will also be displayed in a state in which the task of history is disabled.
I guessed it saved in the registry and searched for registry keys related to Task.
Let's check the registry key of Task Scheduler.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser
The ID of this task is {47C19566-4194-4C9F-BC70-C043803D80E0}.
Look for the key that matches the task ID under the Tasks key.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{47C19566-4194-4C9F-BC70-C043803D80E0}
There are several values under the key. There is "Dynamicinfo" as a value that contains data in FILETIME format.
About this value, some information is provided with winreg-kb. However, there seems to be some unknown part.
03000000
08D12A59C5A9D401
8495AE0DDFA9D401
00000000
00000000
07654515DFA9D401
Decode the first time stamp.
08d12a59c5a9d401 -> 2019-01-11 15:50:17.0216712 (UTC)
The same value as this time stamp can not be found on the task screen. What is this time stamp?
I tried checking the time stamp of the Task file. It matched the created time of the Task file.
Created: 2019-01-11 15:50:17.021671200 (UTC)
By the way, the Task Scheduler GUI also has a Creted column. This column displays the "RegistrationInfo" timestamp in the task file (XML). In the figure below, nothing is displayed because timestamp is not recorded in RegistrationInfo.
Decode the second timestamp.
8495AE0DDFA9D401 -> 2019-01-11 18:54:17.2933508 (UTC)
This timestamp seems to match the "Last Run" Time. 1/11/2019 6:54:17 PM(UTC)
Decode the third timestamp.
07654515DFA9D401 -> 2019-01-11 18:54:30.0257543(UTC)
Is this the timestamp the task completed or Action completed?
Task Completed of the history matches the date and time. 1/11/2019 6:54:30(UTC)
I checked the event log, it seems that the time stamp of Action Completed is close. However, it does not match perfectly.
If the Task Scheduler event log is not enabled, registry information may be somehow clues.
Verification environment: Windows 10 1809, Time zone UTC
Reference URL:
computerforensics.parsonage.co.uk
Windows 10 Storage sense and Recycle.bin
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- I tested the Recycle.bin delete option of the Storage sense feature.
- Files in Recycle.bin are deleted by task SilentCleanup??.
- Sample JPEG file in Recycle.bin on volume C has been deleted.
However, Files in Recycle.bin of volumes E and F were not deleted.
---
Recycle.bin is automatically cleaned up when you enable the Storage sense option of Windows 10. Enable the option in the test environment and confirm the execution of the task to delete the file.
The delete option of recycle.bin specifies 1 day.
The relevant registry keys are below.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy
01 ⇒ Storage sense ON(=1)
2048 ⇒ Run Storage sense: Every day(=1)
04 ⇒ Delete temporary files that my apps aren't using
256 ⇒ 1day
Move sample JPEG files to the recycle bin on the C, E, F volume.
Volumes C: and F: are NTFS and volume E: is ReFS.(These volumes are fixed disk.)
You can not move files to the Recycle.Bin on removable disks.
Two days later, I confirmed that the file on volume C: has been deleted.
Files on volumes E: and F: were not deleted.
When was the sample JPEG file deleted?
Check the date and time that the sample JPEG file was deleted in USN Journal.
In the event log, find the task executed when deleting the file. I found a time very close to the file deletion, but it does not match perfectly.
From the contents of the message, I guess that this task deleted the file.
However, file deletion is recorded one second after completion of the task.
In the USN Journal, there were several records of files deleted at the same time. I am interested in what files SilentCleanup task deletes.
I need to verify further.
Verification environment: Windows 10 1803
Reference URL:
NTFS last access time and 1 hour (3)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- I confirmed that the latest Last Access Time is written to disk by accessing the file after 1 hour has elapsed.
- After one hour elapsed, when shutting down without accessing the file, I did not check whether Last Access Time on memory is written to disk.
<2018/12/16 Add>
The latest Last Access Time was written to disk by shutdown.
In the update of the Last Access Time, the MFT record time stamp was not updated. - This verification had to repeat the same thing over and over....And I still know that it is not enough.
---
I continue to test last access time on the Win 10 1803 environment. (I repeat the same thing like a monkey. :-)
I am hoping to end this test today.
Please note that it is not a sufficient verification method.
DisableLastAccess = 2 (System Managed, Disabled) ⇒ Last Access Time updates are enabled.
The test volume F: is NTFS and the size is 149 GB.
Display properties of Dragonfly.jpg in Explorer.
Check the latest time stamp with the fsutil command.
Check the time stamp recorded on the disk.
It is different from the result of fasutil. I was able to confirm that the old time stamp was saved. This value is the same as the timestamp of the property.
Wait one hour.
Check the latest time stamp with the fsutil command. The timestamp has not changed.
The time stamp on the disk also does not change.
Display the properties of the file and update the timestamp.
Check the latest time stamp with the fsutil command.
Check the time stamp of the disk. The latest timestamp was recorded.
Perhaps, this is what I wanted to test.
In the future, I would like to consider a better verification method.
The resolution of NTFS last access time is described as 1 hour.
File Times - Windows applications | Microsoft Docs
The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.
<2018/12/16 Add>
I tested whether Last Access Time not recorded on disk is written by shutdown processing.
Last Access Time confirmed with the fsutil command has not yet been written to disk even after 1 hour.
Shut down the system and start it. (In this system, fast startup is enabled.)
The Last Access Time seems to have been written to the disk by the shutdown processing.
I did not pay attention to the update date of the FILE record. However, it seems that it was not updated.
NTFS Last Access Time update by property display does not update Change Time. When Last Access Time is set in PowerShell, Change Time is updated.
$(Get-Item f:\Butterfly.jpg).lastaccesstime=$(Get-Date "01/01/2000 00:00 am")
Change Time is updated.
Display the properties of the file and update the Last Access Time.
Last Access Time is updated, but Change Time does not change.
Verification environment: Windows 10 1803
Reference URL:
File Times - Windows applications | Microsoft Docs
It seems that it's okay for Windows to return two different last access timestamps for the same file depending on a function called to retrieve that timestamp (when the "Last Access" updates are enabled, of course). 1/4 #DFIR
— Maxim Suhanov (@errno_fail) December 13, 2018
NTFS last access time and 1 hour (2)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- I used FTK Imager and Autopsy as a tool to check Last Access Time on NTFS volume. However, adding Local Drive did not produce the expected results.
(I lost a lot of time with this repetition.) - Using "PHYSICALDRIVE", expected results were obtained.
- I recommend you to check with PHYSICALDRIVE in the Last Access Time test.
---
I continue to test last access time on the Win 10 1803 environment.
Please note that it is not a sufficient verification method.
DisableLastAccess = 2 (System Managed, Disabled) ⇒ Last Access Time updates are enabled.
The test volume F: is NTFS and the size is 149 GB.
Check the latest time stamp with the fsutil command.
Display properties of Dragonfly.jpg in Explorer. Last Access Time has been updated by this operation.(Close the property and close Explorer.)
Check the latest time stamp with the fsutil command.
Refer to Physicaldrive 2 and check the time stamp. An old timestamp on the disk was displayed.
Add Local Drive F: and check the time stamp. Interestingly, adding Local Drive F: will update the latest timestamp. (This also happens with Autopsy.)
When accessing the logical drive, flash the latest information to the disk?
I recommend you to check with PHYSICALDRIVE in the Last Access Time test.
Because I was referring to F: in the test, I lost a lot of time.
Verification environment: Windows 10 1803
Reference URL:
@port139 @HECFBlog
— Maxim Suhanov (@errno_fail) December 11, 2018
So, the NTFS driver keeps two last access timestamps in memory (for each file): the real one and the shadow one. The real one corresponds to the timestamp on a disk (in the $SI attribute). The shadow one has no corresponding timestamp on a disk. 1/6 #DFIR
NTFS last access time and 1 hour
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Summary:
- NTFS's Last Access Time resolution is one hour. ( I started the test on Win 10 ver 1803.)
- "fsutil file layout" command and PowerShell displays the latest timestamp.
- Displaying properties in Explorer may display old timestamps.(It is not sufficient verification.)
- @errno_fail comments on the timestamp in memory. Thank you!
---
The resolution of NTFS last access time is described as 1 hour.
File Times - Windows applications | Microsoft Docs
The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.
Confirm Last Access Time update on Win 10 ver 1803. (DisableLastAccess = 2 (System Managed, Disabled))
Please note that it is not a sufficient verification method.
Check the time stamp of the sample image file with the fsutil command.
2018/12/09 11:27:05 UTC
Display properties in Windows Explorer. You can check the same timestamp as fsutil command. (The time zone of the verification environment is set to UTC.)
Again, display the time stamp with the fsutil command.
Display properties in Windows Explorer.
Oh? , Explorer displays a different Last Access Time than the FILE record.
I closed Windows Explorer and confirmed it again, but it was the same timestamp. 2018/12/10 10:01:46 UTC
Why does Explorer display old time stamp(Last Access Time)?
I tested it again. Check the timestamp in the property.
Check the time stamp with the fsutil command.
Double check, I confirmed timestamp with FTK Imager
I confirmed the timestamp of $I30. I confirmed the same time stamp as FTK Imager.
2018/12/10 11:11:56.6756334 UTC
???,
Is the fsutil command displaying the latest information and it is different from the value on the disk?
When I checked the property again, I noticed that the time stamp was updated.
The Last Access Time has also been updated in the display of FTK Imager.
It is unknown which access the Last Access Time was updated.
I need to do further verification.
Last Access Time Verification of resolution is a bit difficult. ;-)
<2018/12/11 add>
Thank you for your comment.
@port139 @HECFBlog
— Maxim Suhanov (@errno_fail) December 11, 2018
So, the NTFS driver keeps two last access timestamps in memory (for each file): the real one and the shadow one. The real one corresponds to the timestamp on a disk (in the $SI attribute). The shadow one has no corresponding timestamp on a disk. 1/6 #DFIR
<2018/12/16 add>
I confirmed the Last Access Time in PowerShell. PowerShell displays the latest timestamp.
I checked the Last Access Time with PowerShell and the Last Access Time was not updated.
Verification environment: Windows 10 1803
Reference URL:
DisableLastAccess and 2 (System Managed, Disabled)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
I confirmed DisableLastAccess in verification environment. The size of C: is 40 GB.
The value of DisableLastAccess was "2" and "Disabled"...."Disabled"???
I confirmed the settable value with disablelastaccess.
I saw Forensic Lunch Test Kitchen 12/6/18 and understood the meaning of "Disabled"!
Thank you!
Check the timestamp of Accessed in the property of the sample image file.
Again, display the properties. (File is not opened)
Accessed has been updated.
Connect the USB memory(58.5GB) and repeat the same procedure.
Again, display the properties. (File is not opened)
Accessed has been updated.
I added a 150 GB volume to the test environment.
Check the time stamp of the sample image file.
>fsutil file layout Dragonfly.jpg
Last Access Time : 12/9/2018 10:09:20 (UTC)
Display the properties. (File is not opened)
Again, Check the time stamp of the sample image file.
Last Access Time has been updated.
Muuu??
Time stamp resolution is not 1 hour?
I need to continue testing.
Verification environment: Windows 10 1083
Reference URL:
File Times - Windows applications | Microsoft Docs
