@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

Active Directory and ADTimeline(2)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.

Summary:

  • I created an Alice account, added it to the Domain admins group, and confirmed it on the timeline.
  • Next, I created a Bob account and logged on to the domain, but I could not confirm it in the timeline (Note:Since Bob does not have high privilege, it is not displayed in ADTimeline. You can display Bob in the timeline using $groupscustom definition.)

----------

[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.

I have newly constructed an Active Directory environment with two DCs. (DC1, DC2 and PC1)

First, I created users Alice and Bob.

DC1: 2/11/2019 7:05:45 AM EID 4720 A user account was created.(Alice)
DC2: 2/11/2019 7:05:45 AM EID 4720 A user account was created.(Bob)

I checked the DC1 and DC2 timelines, I found a record related to Alice account, but I could not find record related to Bob account. Interesting.

f:id:hideakii:20190217090609p:plain

Next, I added the Alice account to the Domain Admins group.

DC1: 2/11/2019 7:08:50 AM EID 4728 A member was added to a security-enabled global group.(Alice⇒Domain Admins)

In the timeline, there is a record related to the Domain Admins group and the "adminCount" of the Alice account.

f:id:hideakii:20190217091452p:plain

ftimeLastOriginatingChange : 2019-02-11T07:08:50Z
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 : 1
WhenCreated : 2019-01-20 19:20:35Z
Member : CN=alice,CN=Users,DC=example,DC=local
ftimeCreated : 2019-02-11T07:08:50Z
ftimeDeleted : 1601-01-01T00:00:00Z
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 : 36964
usnLocalChange : 36964

In Microsoft Blog, ftimeDeleted and ftimeCreated are described.

ftimeDeleted the time the member has been removed (equal 0 if the object is currently still a member).
ftimeCreated the time when the member has been added for the first time.

 

Next, log on to PC1 with Alice account.

DC2: 2/11/2019 10:57:19 AM EID 4624 An account was successfully logged on.(Alice)

On the timeline, there is a record related to the "lastLogonTimestamp" of the Alice account.

f:id:hideakii:20190217094449p:plain

ftimeLastOriginatingChange : 2019-02-11T10:57:19Z
Name : alice
pszAttributeName : lastLogonTimestamp
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-11 07:05:45Z
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 : 37098
usnLocalChange : 37098

On DC1 and DC2, check the properties of the Alice account. (Get-ADUser -identity alice -property *)

Since lastLogon is not replicated, there are differences in values.

DC1

lastLogon : 131943562397419196
LastLogonDate : 2/11/2019 10:57:19 AM
lastLogonTimestamp : 131943562397419196

DC2

lastLogon : 131943562396367072
LastLogonDate : 2/11/2019 10:57:19 AM
lastLogonTimestamp : 131943562397419196

The values output to ADobjects.xml created by ADTimeline are as follows.

lastLogon : 131943562397419196
lastLogonTimestamp : 131943562397419196

 

Next, I will also check the Bob account.(Bob account does not have high privilege.)

The Bob account logs on to the domain. You can check Bob's logon with DC1

 and DC2 security log.

DC1

f:id:hideakii:20190217103220p:plain

DC2

f:id:hideakii:20190217101315p:plain

However, I could not find a record related to Bob account. I searched Bob in ADobjects.xml, but it did not exist.

(ADD: I was testing it without understanding that ADTimeline was targeting high privilege. Bob does not have high privilege, so it is not displayed on the timeline.)

f:id:hideakii:20190217101534p:plain

Just to be sure, I will check the properties of Bob with DC1 and DC2. 
lastLogonTimestamp indicates the time Bob logged on. (2/11/2019 10:59:19 AM)

DC1

LastLogonDate : 2/11/2019 10:59:19 AM
lastLogonTimestamp : 131943563590742494

DC2

lastLogon : 131943563590742494
LastLogonDate : 2/11/2019 10:59:19 AM
lastLogonTimestamp : 131943563590742494

It is interesting that Bob's logon does not appear on the timeline.

f:id:hideakii:20190217144557p:plain

The timeline and event log created this time can be downloaded from here.

<add>

I could display Bob in the timeline by defining the "Domain Users" group in "$groupscustom".

$groupscustom = "Domain Users"

f:id:hideakii:20190217180549p:plain

(I have not read all of README.md. I was taught it by DM. Thank you! ;-)

</add>

 

PS

LastLogonTimeStamp seems to have delays of up to 14 days, not updates in real time.

blogs.technet.microsoft.com

 

I will continue testing.

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

blogs.technet.microsoft.com

blogs.technet.microsoft.com

 

f:id:hideakii:20190217085520j:plain



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. 

f:id:hideakii:20190210102413p:plain

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.

f:id:hideakii:20190210102719p:plain

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.

f:id:hideakii:20190210103031p:plain

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.

f:id:hideakii:20190210103545p:plain

In the output of ADTimeline, related records could not be found.

 

Remove the Alice account from the "Domain Admins" group.

f:id:hideakii:20190210104001p:plain

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.

f:id:hideakii:20190210104340p:plain

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.

f:id:hideakii:20190210114340p:plain

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:

github.com

Metadata #0 – Metadata, what is it and why do we care?

blogs.technet.microsoft.com

 

f:id:hideakii:20190210083637j:plain

 

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.

f:id:hideakii:20190203195541j:plain

Using DCshadow, set "SIDhistory" to Alice.

f:id:hideakii:20190203201003j:plain

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.

f:id:hideakii:20190203201225j:plain

Using PowerShell, delete Alice's SIDhistory.

Set-ADUser -Identity alice -Remove @{SIDHistory='S-1-5-21-1490397982-2793378994-64436834-500'}

f:id:hideakii:20190203202228j:plain

This operation which does not use DCshadow can be confirmed by event ID 4738.

f:id:hideakii:20190203202627j:plain

Use DCshadow to set the time stamp for whenChanged.

f:id:hideakii:20190203204451j:plain

You can confirm that the time stamp specified in "whenChanged" is set.

f:id:hideakii:20190203204533j:plain

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.

f:id:hideakii:20190203211938j:plain

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.

f:id:hideakii:20190203212207j:plain

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:

docs.microsoft.com

www.dcshadow.com

github.com

https://www.ssi.gouv.fr/uploads/2019/01/anssi-coriin_2019-ad_timeline.pdf

 

f:id:hideakii:20190203194853j:plain

 

 

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
  •  

 ----------

[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.

f:id:hideakii:20190127085057p:plain

f:id:hideakii:20190127085208p:plain

f:id:hideakii:20190127092635p:plain

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"?

f:id:hideakii:20190127093358p:plain

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.

f:id:hideakii:20190127094943p:plain

f:id:hideakii:20190127095151p:plain

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.

f:id:hideakii:20190127103639p:plain

Perhaps, I think that it is an ACL update event of "AdminSDHolder". I was forgotten to confirm the attributes of "adminCount" beforehand.

EID 4780

f:id:hideakii:20190127103927p:plain

EID 4738 is also recorded in the event log, but I could not identify which attribute was changed.

f:id:hideakii:20190127162603p:plain

 

I will continue testing.

 

Verification environment: Windows Server 2019 1809, Windows 10 1809, Time zone UTC

Reference URL:

docs.microsoft.com

docs.microsoft.com

blogs.technet.microsoft.com

blogs.technet.microsoft.com

https://adsecurity.org/?p=1906

 

f:id:hideakii:20190127083722j:plain

 

*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:

----------

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.

f:id:hideakii:20190120100800p:plain

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.

f:id:hideakii:20190120102407p:plain

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. 

f:id:hideakii:20190120104658p:plain

I read the article of "No run counts in UserAssist" and tested the execution of Task Scheduler.

f:id:hideakii:20190120110021p:plain

As Matthew Seyer wrote in the article, Run Counter and Last Executed were not recorded.

f:id:hideakii:20190120110220p:plain
Also, we tried executing the GUI program from CMD described on Twitter of Maxim Suhanov. Run Counter and Last Executed were not recorded.

f:id:hideakii:20190120111111p:plain

f:id:hideakii:20190120111517p:plain

 

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:

www.hecfblog.com

www.hecfblog.com

medium.com

 

binaryforay.blogspot.com

 

f:id:hideakii:20190120094750j:plain

 

 

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?』

f:id:hideakii:20190112085642j:plain

"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

f:id:hideakii:20190112090528j:plain

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}

f:id:hideakii:20190112090723j:plain

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)

f:id:hideakii:20190112091811j:plain

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.

f:id:hideakii:20190112092020j:plain

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)

f:id:hideakii:20190112092527j:plain

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)

f:id:hideakii:20190112093107j:plain

I checked the event log, it seems that the time stamp of Action Completed is close. However, it does not match perfectly.

f:id:hideakii:20190112094406j:plain

f:id:hideakii:20190112094237j:plain

 

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:

github.com

computerforensics.parsonage.co.uk

f:id:hideakii:20190112084504j:plain

 

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.

f:id:hideakii:20181224121043p:plain

The delete option of recycle.bin specifies 1 day.

f:id:hideakii:20181224121306p:plain

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

f:id:hideakii:20181224121429p:plain

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.)

f:id:hideakii:20181224121624p:plain

You can not move files to the Recycle.Bin on removable disks.

f:id:hideakii:20181224121743p:plain

Two days later, I confirmed that the file on volume C: has been deleted.
Files on volumes E: and F: were not deleted.

f:id:hideakii:20181224121857p:plain

When was the sample JPEG file deleted?
Check the date and time that the sample JPEG file was deleted in USN Journal.

f:id:hideakii:20181224122000p:plain

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.

f:id:hideakii:20181224122039p:plain

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:

blogs.technet.microsoft.com

www.tenforums.com

f:id:hideakii:20181224120707j:plain

 

NTFS last access time and 1 hour (3)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

Summary:

  1. I confirmed that the latest Last Access Time is written to disk by accessing the file after 1 hour has elapsed.
  2. 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.
  3. 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.

f:id:hideakii:20181212180117p:plain

Check the latest time stamp with the fsutil command.

f:id:hideakii:20181212180214p:plain

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.

f:id:hideakii:20181212180344p:plain

Wait one hour.

Check the latest time stamp with the fsutil command. The timestamp has not changed.

f:id:hideakii:20181212185438p:plain

The time stamp on the disk also does not change.

f:id:hideakii:20181212185450p:plain

Display the properties of the file and update the timestamp.

f:id:hideakii:20181212185629p:plain

Check the latest time stamp with the fsutil command.

f:id:hideakii:20181212185640p:plain

Check the time stamp of the disk. The latest timestamp was recorded.

f:id:hideakii:20181212185700p:plain

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.

f:id:hideakii:20181216124137p:plain

f:id:hideakii:20181216123651p:plain

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.

f:id:hideakii:20181216124524p:plain

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.

f:id:hideakii:20181216133049p:plain

$(Get-Item f:\Butterfly.jpg).lastaccesstime=$(Get-Date "01/01/2000 00:00 am")
Change Time is updated.

f:id:hideakii:20181216133231p:plain

Display the properties of the file and update the Last Access Time.
Last Access Time is updated, but Change Time does not change.

f:id:hideakii:20181216133534p:plain

 

Verification environment: Windows 10 1803

Reference URL:

File Times - Windows applications | Microsoft Docs

 

dfir.ru

 

f:id:hideakii:20181212175819j:plain

 

NTFS last access time and 1 hour (2)

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

Summary:

  1. 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.)
  2. Using "PHYSICALDRIVE", expected results were obtained.
  3. 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.

f:id:hideakii:20181211194703p:plain

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.

f:id:hideakii:20181211195748p:plain

Refer to Physicaldrive 2 and check the time stamp. An old timestamp on the disk was displayed.

f:id:hideakii:20181211195836p:plain

Add Local Drive F: and check the time stamp. Interestingly, adding Local Drive F: will update the latest timestamp. (This also happens with Autopsy.)

f:id:hideakii:20181211200132p:plain

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:

 

 

f:id:hideakii:20181211184548j:plain

 

NTFS last access time and 1 hour

Note:I translated Japanese into English using Google Translate.
Thank you, Google.  

Summary:

  1. NTFS's Last Access Time resolution is one hour. ( I started the test on Win 10 ver 1803.)
  2. "fsutil file layout" command and PowerShell displays the latest timestamp.
  3. Displaying properties in Explorer may display old timestamps.(It is not sufficient verification.)
  4. @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

f:id:hideakii:20181210185658p:plain

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.)

f:id:hideakii:20181210185750p:plain

 

Again, display the time stamp with the fsutil command.

f:id:hideakii:20181210194723p:plain

Display properties in Windows Explorer.

Oh? , Explorer displays a different Last Access Time than the FILE record.

f:id:hideakii:20181210194841p:plain

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.

f:id:hideakii:20181210201441p:plain

Check the time stamp with the fsutil command. 

f:id:hideakii:20181210201520p:plain

Double check, I confirmed timestamp with FTK Imager

f:id:hideakii:20181210201858p:plain

I confirmed the timestamp of $I30. I confirmed the same time stamp as FTK Imager.

2018/12/10 11:11:56.6756334 UTC

f:id:hideakii:20181210202236p:plain

???,

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.

f:id:hideakii:20181210203217p:plain

The Last Access Time has also been updated in the display of FTK Imager.

f:id:hideakii:20181210203428p:plain

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.

 <2018/12/16 add>

I confirmed the Last Access Time in PowerShell. PowerShell displays the latest timestamp.

f:id:hideakii:20181216092120p:plain

f:id:hideakii:20181216092321p:plain

f:id:hideakii:20181216092508p:plain

I checked the Last Access Time with PowerShell and the Last Access Time was not updated.

 

Verification environment: Windows 10 1803

Reference URL:

 

f:id:hideakii:20181210184955j:plain