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:

[MS-FSCC]: USN_RECORD_V2

[MS-FSCC]: USN_RECORD_V3

GitHub - jschicht/UsnJrnl2Csv: Parser for $UsnJrnl on NTFS

www.williballenthin.com

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:

docs.microsoft.com

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

iria-piyo.hatenablog.com

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:

www.afodblog.com

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:

docs.microsoft.com

https://www.jpcert.or.jp/present/2018/JSAC2018_03_yamazaki.pdf

GitHub - jschicht/SetMace: Manipulate timestamps on NTFS

Autopsy and Realloc

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

Let's create a record labeled (realloc).

Create Example folder and create several files in the folder. In the following, a long file name is set to create Index Allocation of $i30.

Copy frog.jpg to be used for testing to the F:\Example folder.

Create a hard link to the frog.jpg file. Frog.jpg and sample.jpg are FILE record number 51.

Delete the folder F:\Example. 

If you check $i30, you can find Frog.jpg's $FN. Interesting, FTK Imager 4.1.1.1 does not display Frog.jpg.

Check the display on Autopsy. Flags (Dir) is Unallocated, but Flags (Meta) is Allocated.

 In addition, Frog.jpg is not displayed on the timeline of plaso-20180818-amd64.

Reference URL:

github.com

Esentutl and File copy

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

FireEye has released a report on APT 10's TTPs. I was interested in the method using ESENTUTL tool. 

https://www.fireeye.com/blog/threat-research/2018/09/apt10-targeting-japanese-corporations-using-updated-ttps.html

3. The macro creates a copy of the files with their proper extensions using Extensible Storage Engine Utilities (esentutil.exe) with the following commands (esentutil.exe is also a legitimate program that is pre-installed in Windows):

C:\Windows\System32\esentutl.exe" /y C:\ProgramData\\GUP.txt /d C:\ProgramData\GUP.exe /o

 First, confirm HELP. the file name is very confusing. "i" is not included in the correct command.

 In the macro, the following three options are specified.

Copy File: /y <source file> [options]
/d<file> - destination file (default: copy source file to current directory)
/o - suppress logo

Let's copy the sample JPEG file.

When the ESENTUTL command creates an .EXE file, it should be noted.

By the way, ESENTUTL contains the character string NT.
Recently, I was asked by young people "What is the meaning of NT?"
I like the story of Windows NT and David Cutler.

Verification environment: Windows 10 1083

Reference URL:

https://www.fireeye.com/blog/threat-research/2018/09/apt10-targeting-japanese-corporations-using-updated-ttps.html

NTFS $ObjID and ObjectID

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

Let's check NTFS $ObjID:$O and the deleted ObjectID. 
There is image files on the sample E: drive, but these files do not have an ObjectID.

Browse the image file and check the ObjectID.

Confirm that the ObjectID was given.

Let's look at the FILE record of $ObjID. In the figure below, you can find the $O index record in $ INDEX_ROOT (0x90).

At this point, $ObjID:$O does not exist.

Refer to multiple files and add ObjectID to $ObjID.

$O was created as $INDEX_ALLOCATION (0xA0). ( In my test environment $O was created with seven references, including root. )

Using the fte tool, see the result of parsing ObjID.

Delete boat.jpg which we last referred to.

By this operation, the record of boat.jpg in $O is deleted.
The fte tool can refer to deleted records if there are data remaining. 

note:
When there is no $O, ObjectID is not displayed even if you use the fet tool. 

Verification environment: Windows 10 1083

Reference URL:

http://www.kazamiya.net/en/fte

GitHub - jschicht/Indx2Csv: An advanced parser for INDX records

NTFS $LogFile and ObjectID

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

Check the record of $LogFile when setting ObjectID.
E: drive used for verification is newly formatted with NTFS.

Copy the sample JPEG file to the E drive. This file does not have an ObjectID..

Using the fsutil command, create an ObjectID.

Check the contents of the FILE record with Autopsy. The FILE record number of the sample image file is 40.

Parse $LogFile.

See the parse result.

Delete the ObjectID and check $LogFile.

You can confirm that the ObjectID was deleted with DeleteAttribute.

Create ObjectID again. Different ObjectIDs were created.

In the parsing result of $LogFile, check the current value and the previous value.

Verification environment: Windows 10 1083

Reference URL:

GitHub - jschicht/LogFileParser: Parser for $LogFile on NTFS