Deleted Registry KEY and Timestamp
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Delete the registry key and check the time stamp.
Create sample registry keys and values under SYSTEM.
Last write timestamp:2018-12-09 05:33:00(UTC)
Delete the registry key and check the time stamp. The timestamp has not changed.
Last write timestamp:2018-12-09 05:33:00(UTC)
Next, we create a key with several subkeys.
EVIDENCE002: Last write timestamp:2018-12-09 05:54:22(UTC)
EVIDENCE003: Last write timestamp:2018-12-09 05:54:31(UTC)
EVIDENCE004: Last write timestamp:2018-12-09 05:54:49(UTC)
Delete the parent's EVIDENCE002 key and check the time stamp.
EVIDENCE002: Last write timestamp:2018-12-09 06:01:00(UTC)
EVIDENCE003: Last write timestamp:2018-12-09 06:01:00(UTC)
EVIDENCE004: Last write timestamp:2018-12-09 05:54:49(UTC)
The timestamp of EVIDENCE 002 and 003 has been updated.
What changed?, Compare Technical details.
EVIDENCE003(Before deleting)
Size: 0x60
Relative Offset: 0x327848
Absolute Offset: 0x328848
Signature: nk
Flags: CompressedNameName: EVIDENCE003
Last Write Timestamp: 12/9/2018 5:54:31 AM +00:00
Is Free: False
Debug: 0x0
Maximum Class Length: 0x0
Class Cell Index: 0x0
Class Length: 0x0Maximum Value Data Length: 0x0
Maximum Value Name Length: 0x0Name Length: 0xB
Maximum Name Length: 0x16Parent Cell Index: 0x327970
Security Cell Index: 0x64B3D0Subkey Counts Stable: 0x1
Subkey Lists Stable Cell Index: 0xA489A8Subkey Counts Volatile: 0x0
User Flags: 0x00000000
Virtual Control Flags: 0x00000000
Work Var: 0x0Value Count: 0x0
Value List Cell Index: 0x0Padding: 00-63-14-FE-E9
Security key
Size: 0x108
Relative Offset: 0x64B3D0
Absolute Offset: 0x64C3D0
Signature: sk
Is Free: FalseForward Link: 0x138C70
Backward Link: 0x64B8F0Reference Count: 7
Security descriptor length: 0xF0
Security descriptor: Revision: 0x1
Control: SeDaclPresent, SeDaclAutoInherited, SeSaclAutoInherited, SeSelfRelativeOwner offset: 0xC4
Owner SID: S-1-5-32-544
Owner SID Type: BuiltinAdministratorsGroup offset: 0xD4
Group SID: S-1-5-21-3032502310-280463001-373959476-513
Group SID Type: DomainUsersDacl Offset: 0x14
DACL: ACL Revision: 0x2
ACL Size: 0xB0
ACL Type: Discretionary
Sbz1: 0x0
Sbz2: 0x0
ACE Records Count: 6------------ Ace record #0 ------------
ACE Size: 0x18
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: QueryValue, EnumerateSubkeys, Notify, ReadControl
SID: S-1-5-32-545
SID Type: BuiltinUsers
SID Type Description: S-1-5-32-545: A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer.------------ Ace record #1 ------------
ACE Size: 0x18
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: FullControl
SID: S-1-5-32-544
SID Type: BuiltinAdministrators
SID Type Description: S-1-5-32-544: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Administrators group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Administrators group also is added to the Administrators group.------------ Ace record #2 ------------
ACE Size: 0x14
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: FullControl
SID: S-1-5-18
SID Type: LocalSystem
SID Type Description: S-1-5-18: An account that is used by the operating system.------------ Ace record #3 ------------
ACE Size: 0x14
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritOnlyAce, InheritedAce
Mask: FullControl
SID: S-1-3-0
SID Type: CreatorOwner
SID Type Description: S-1-3-0: A placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the object's creator.------------ Ace record #4 ------------
ACE Size: 0x18
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: QueryValue, EnumerateSubkeys, Notify, ReadControl
SID: S-1-15-2-1
SID Type: AllAppPackages
SID Type Description: S-1-15-2-1: All applications running in an app package context.------------ Ace record #5 ------------
ACE Size: 0x38
ACE Type: AccessAllowedAceType
ACE Flags: ContainerInheritAce, InheritedAce
Mask: QueryValue, EnumerateSubkeys, Notify, ReadControl
SID: S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681
SID Type: UnknownOrUserSid
SID Type Description: SID does not map to a common SID or this is a user SID
Subkeys
Key name: EVIDENCE004, Value count: 1, Subkey count: 0
Key name: New Key #1, Value count: 0, Subkey count: 0
EVIDENCE003(Deleted)
Size: 0xB0
Relative Offset: 0x327848
Absolute Offset: 0x328848
Signature: nk
Flags: CompressedNameName: EVIDENCE003
Last Write Timestamp: 12/9/2018 6:01:00 AM +00:00
Is Free: True
Debug: 0x0
Maximum Class Length: 0x0
Class Cell Index: 0x0
Class Length: 0x0Maximum Value Data Length: 0x0
Maximum Value Name Length: 0x0Name Length: 0xB
Maximum Name Length: 0x0Parent Cell Index: 0x327970
Security Cell Index: 0xFFFFFFFFSubkey Counts Stable: 0x0
Subkey Lists Stable Cell Index: 0x0Subkey Counts Volatile: 0x0
User Flags: 0x00000000
Virtual Control Flags: 0x00000000
Work Var: 0x0Value Count: 0x0
Value List Cell Index: 0x0
SubkeysKey name: New Key #1, Value count: 0, Subkey count: 0
Key name: EVIDENCE004, Value count: 1, Subkey count: 0
Verification environment: Windows 10 1803
Reference URL:
USB and Amcache(2)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
This is the continuation of the Amcache test.
I connected a USB memory and created an LNK file.
Each LNK file targets the CLI and the GUI program that exist on the USB memory.
Run each LNK file and check the timestamp in the Sysmon event log.
I will wait until it is reflected in Amcahce. (The USB memory is still connected.)
Confirm the parse result.
There was no entry for F: drive in "20181203071331_Amcache_ShortCuts.csv".
Result of 20181203071313_Amcache_UnassociatedFileEntries.csv.
???, There is a record of the CLI program, Autorunsc.exe. (I want to test what happens when PowerShell etc. are embedded in LNK file.)
And the record of the program deleted from F: drive has disappeared.(Record such as fte.exe does not exist.)
Result of 2018120307131331_Amcache_DevicePnps.csv.
Verification environment: Windows 10 1803
Reference URL:
USB and Amcache
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Have you seen the Amcache season of Forensic Lunch Test Kitchen?
Unfortunately, I have not seen everything yet. I am planning to enjoy them at the weekend.
and I saw @errno_fail tweet. They are very interesting comments.
@HECFBlog Sunday Funday. 1/4
— Maxim Suhanov (@errno_fail) November 27, 2018
Windows 7 SP1 (Home Basic, 32-bit): the Amcache hive gets updated when the Microsoft Compatibility Appraiser task is executed. It's scheduled to run at 03:00 every day (it can be executed later if a computer was powered off at that time). #DFIR
Either way, I have done quite limited tests on USB memory and Amcache.hve.
Since it is not a sufficient test, it may be overlooking something.
First of all, I ran several programs from the USB memory(F:).
Run autorunsc64.exe as CLI program. The following is Sysmon event log.
And as a GUI program, I executed Dcode.exe.
The USB memory is still connected to the system.
I waited for the Application Experience task to be executed.(The execution date and time of the task is Japan time.)
Parse Amcache.hve with AmcacheParser and filter by F:.
Dcode.exe is recorded, but Autorunsc64.exe does not exist.
FileKeyLastWriteTimestamp(UTC) does not exactly match the date and time of the Sysmon event.(I checked the Sysmon event log that there is no record at 05:54)
I removed the USB memory from the system and waited one day.
There was no change in the parse result of Amcache.hve. I do not know how long F: drive information will be maintained.
Next test.
I ran the program from the USB memory and removed the USB memory from the system.
I waited for the Application Experience task to be executed. At the time when the task is executed, the USB memory is not connected.
As already mentioned by @ errno_fail, records are not recorded if USB is not connected.
I felt strange about FileKeyLastWriteTimestamp.(The key is being updated before the task is executed.)
Do keys generate according to task execution? When is this key created?
Interestingly, the timestamp of Amcache.hve and LOG file is old. The contents of the file have been updated, but Date modified has not been updated. (This is also seen in the thumbcache_ * file.)
I tried Shift + Shutdown.
Muuu...Is it updated when a complete shutdown is performed?(In this system, fast startup is enabled.)
I have not tried running the LNK file on the USB memory yet.
I will continue testing.
Verification environment: Windows 10 1803
Reference URL:
ReFS and File ID
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
The File ID of ReFS looks different from NTFS. Using USN Journal, confirm the ReFS File ID.
I enabled the USN Journal on the ReFS volume used for testing.
Create the folder Pictures and check the File ID.
File ID is "00000000000007020000000000000000". ⇒ 1,794
Parent file ID : 00000000000006000000000000000000 ⇒ 1,536
Copy Example1.jpg to the Picutres folder. The file ID of Example1.jpg is 00000000000007020000000000000001.
Add more files and check the File ID. The last number will increase.
example2.jpg
File ID : 00000000000007020000000000000002
Parent file ID : 00000000000007020000000000000000
example3.jpg
File ID : 00000000000007020000000000000003
Parent file ID : 00000000000007020000000000000000
Delete example3.jpg and copy example4.jpg to the Pictures folder.
Will 0000000000000003 be reused?
example4.jpg
File ID : 00000000000007020000000000000004
Parent file ID : 00000000000007020000000000000000
Next, let's move the file. Parent file ID is updated and File ID is unchanged.
move Pictures\example4.jpg e:\
example4.jpg
File ID : 00000000000007020000000000000004
Parent file ID : 00000000000006000000000000000000
Using File ID, can I check the parent folder at the time of file creation?
Copy example3.jpg to the Pictures folder and check the File ID.
example3.jpg
File ID : 00000000000007020000000000000005
Parent file ID : 00000000000007020000000000000000
Create "subfilder1" under the Pictures folder.
705 was set for the File ID of "subfilder 1". In addition, 703 is in $ RECYCLE.BIN and 704 is a folder of SID.
Discard example3.jpg to the trash. The file name of Example3.jpg is changed but the File ID does not change.
Is the File ID in ReFS composed of two of folder number and file number?
Verification environment: Windows 10 1083
Reference URL:
USN_RECORD_V4 structure (Windows)
Refs and USN Journal(2)
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
I got the Refs volume of Win10 1803 as E01 image. You can download it from the following URL. (That is the volume I tested last time.)
Win10_1083_Refs.E01
https://drive.google.com/open?id=1adzuHvXH2FlMpQnGHh2S-i9FXvV1Llwd
Unfortunately I do not have a tool to parse Refs. Therefore, I will use my own eyes :-)
Look for the USN record of example.jpg in the Refs volume.
I found several file names at offset 268445728. Well, is this a USN Journal record?
I compared with the structure of USN_RECORD_V2, but some did not match.
So, I tried the structure of USN_RECORD_V3.
68 00 00 00 ⇒ RecordLength ⇒ 104
03 00 ⇒ MajorVersion ⇒ 3
00 00 ⇒ MinorVersion ⇒ 0
01000000000000000207000000000000 ⇒ FileReferenceNumber (16 bytes)
00000000000000000207000000000000 ⇒ ParentFileReferenceNumber (16 bytes)
D8 07 00 00 00 00 00 00 ⇒ USN
DE A4 43 09 FF 73 D4 01 ⇒ TimeStamp ⇒ FILETIME (UTC): 11/4/2018 5:27:10 AM
00010000 ⇒ Reason ⇒ 0x00010000 USN_REASON_HARD_LINK_CHANGE
00000000 ⇒ SourceInfo
00000000 ⇒ SecurityId
20000000 ⇒ FileAttributes
16 00 ⇒ FileNameLength ⇒ 22
4C 00 ⇒ FileNameOffset ⇒ 76
6500780061006D0070006C0065002E006A0070006700000000000000 ⇒ FileName (variable) ⇒ example.jpg
The Refs' USN Journal appears to be using USN_RECORD_V3. However, I do not know if it is always USN_RECORD_V3.
The structure differs between USN_RECORD_V3 and USN_RECORD_V2. For this reason, carving assuming V2 structure will fail.
By the way, I noticed that the USN related URL of Microsoft was 404.
So, I refer to the URL that David taught me. Thank you!
<add>
Zaki-san taught me that UsnJrnl2Csv supports USN_RECORD_V3.
I exported from offset 268443648 to 268449952.
However, no results were obtained.
Verification environment: Windows 10 1803
Reference URL:
GitHub - jschicht/UsnJrnl2Csv: Parser for $UsnJrnl on NTFS
Refs and USN Journal
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
A little while ago I learned that ReFS supports the USN Journal.
How do I check the USN Journal on ReFS?
Format E: drive with ReFS.
Start the administrator command prompt. Check the status of USN Journal with fsutil command.
For some reason, access is denied. Also I could confirm that USN journal is not valid.
Enable USN Journal. However, the queryjournal option is access denied.
Create the Pictures folder and read the USN Journal. The readjournal command worked.(also tried the CSV option)
Copy example.jpg to the Pctures folder and browse.
Since ReFS does not support ObjectID, ObjectID is not set.
NTFS ADS is supported. Perhaps the USN Journal also exists as $J?
So how do I get USN Journal data on ReFS in RAW format?
<add>
I exported the area of ReFS and tried Carving. Unfortunately, no USN record was found.
Verification environment: Windows 10 1083
Reference URL:
https://en.wikipedia.org/wiki/ReFS
https://www.jpcert.or.jp/present/2018/JSAC2018_03_yamazaki.pdf
Bulk Extractor with Record Carving | Forensicist
Audit PNP Activity and ID 6416
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
When audit setting "Audit PNP Activity" is enabled on Windows 10, event ID 6416 is recorded. Auditing is not enabled for this item by default.
Let's check the record when connecting the USB memory.
Connect the USB memory. This USB memory was connected to the system for the first time.
Three records were recorded in the security log.
ID 6416
The user name is the computer account. It seems that it is necessary to confirm the account connected the USB device to the system with another item.
Slightly later, another 6416 records are also recorded. Volume name is recorded in the item of DeviceDescription.
Event IDs 6419 and 6420 are recorded when device is disabled.
Interesting, ID 6419 has recorded the user who disabled the device.
When you enable the device, IDs 6421 and 6422 are recorded.
Event ID 6421 records the user who activated the device.
Perform removal of the device.
Unfortunately, no record was recorded on removal of the device.
While shutting down the system with the USB device connected, records were not recorded.
When rebooting the system with the USB device connected, ID 6416 is recorded after system startup. (There was only one record related to the USB device.)
Verification environment: Windows 10 1083
Reference URL:
6416(S) A new external device was recognized by the System. (Windows 10) | Microsoft Docs
File System Tunneling and C:\
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
Last week I enjoyed File System Tunneling.
Unfortunately, I could not reproduce File System Tunneling with NTFS 'E: drive. This time I use the C: drive for testing.
Also, last time I did not refer to the USN journal and $LogFile.
Can I find out the occurrence of File System Tunneling from the USN Journal?
Copy the owl image file to the C:\Pictures folder.
Check the USN journal and the timestamp.
>fsutil usn readjournal c:
Delete the file owl.jpg and create the same file name.
Use usn_analytics to parse the USN journal.
Let's check the parsing result.
I was expecting a record of "Basic Info Change", but it was not there.
Confirm the meta information of the created file.
The timestamp of Created is restored by File System Tunneling. (Created time stamps of $SI and $FN, both have been restored.)
Use LogFileParser to parse $LogFile and check the record of owl.jpg.
When you confirm the InitializeFileRecordSegment, Created time stamp has restored value appeared.
Next, try changing the file name. I copied the owl.tmp file to the Pictures folder.
Confirm the parse result of USN journal, Basic Info Change is not recorded.
Confirm Created time stamp with file meta information.
Interestingly, the Created timestamp of $FN was not updated.
Check the record in $ LogFile.
.....If a FILE record already exists, the Created timestamp of $SI is restored and $FN is not restored?
Verification environment: Windows 10 1083
Reference URL:
File System Tunneling and E:\
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
iria_piyo has published some interesting verifications on File System Tunneling in the blog. I read those blogs and I wanted to see how the USN Journal was recorded.
(2013 article in the reference URL, Keydet89 has already mentioned the USN journal.)
Unfortunately I do not have an image of fried eggs (medamayaki.png) so I will use the otter image.
Format E drive as NTFS and enable USN Journal.
E:\>fsutil usn createjournal e: m=1 a=1
Copy the JPEG file to the E: Pictures folder using Windows Explorer.
Check the file meta information with Autopsy.
Delete the file and create the same file name. I should have recorded the time before deleting the file...
Unlike expected results, Created timestamp was not restored.
...why?
Copy the image file with a different name and test again.
This time, the same file name is created by deleting the file and changing the file name.
Created time stamp was not restored......why????
Just to be sure, I check the registry, but there is no value of MaximumTunnelEntries.
By the way, why is NtfsDisableLastAccessUpdate value 80000002? (DisableLastAccess = 2 (System Managed, Disabled))
I will test the same operation on the C: drive.
As before, I copied the otter image to c:\Pictures folder.
Created timestamp has been restored.
Muuuuuu...Why is the Created time stamp not restored on E: drive?
<FAT32>
I formatted E: drive with FAT32, and performed the same test, it was the result below.
On FAT32, Created time stamp is restored.
Verification environment: Windows 10 1083
Reference URL:
Timestamp and USN_REASON_BASIC_INFO_CHANGE
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
My question is
Can I find timestamp changes using USN Journal?
Let's try it.
Enable USN Journal with volume E :.
Copy the sample JPEG file to the E: drive, using the explorer.
Use Autopsy to check the time stamps of $SIA and $ FN.
The record containing "Basic info change" appeared twice.
Use Powershell to change the timestamp of LastWriteTime.
In the figure below, it is easy to confirm that "Basic info change" has been changed. Unfortunately, I can not identify that the timestamp value has changed.
What happens if I unzip the ZIP file? I created a compressed file using 7zip and expanded it from explorer.
A record of "Data extend | File create | Close" is recorded, followed by a record of "Basic info change".
Next, unzip the ZIP file using 7zip and check the time stamp.
In the case of 7zip, I was able to confirm the same output result as when copying files in Explorer.
Move the sample JPEG file on the C: drive to the E: drive and check the time stamp.
There was an ObjectID. It was different from my expectation.
Try again with a file that does not have an ObjectID.
I forgot to confirm the pattern when I created a new file.
When creating a new file, "Basic info change" is not recorded.
Open the file with Notepad.exe and update the content.
I updated the file, but "Basic info change" is not recorded.
I need to test more patterns.
Verification environment: Windows 10 1083
Reference URL:
https://www.jpcert.or.jp/present/2018/JSAC2018_03_yamazaki.pdf
GitHub - jschicht/SetMace: Manipulate timestamps on NTFS