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

NTFS $LogFile and DataRun

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

Use $LogFile to check overwriting of the cluster. 
Two images are used for the test. These two image files are almost the same size.

Copy Dragonfly.jpg to formatted F drive.

Check the cluster number of Dragonfly.jpg with the $DATA attribute. Dragonfly.jpg FILE record number is 43, $DATA is Non-Resident and is using cluster number 1993.

Delete Dragonfly.jpg and overwrite the FILE record. Overwriting FILE records may not be necessary.
If you are lucky, simply create a new file and the cluster will be overwritten.
Unfortunately, I tried it many times...

Copy Butterfly to formatted F drive.

Check the cluster number of Butterfly.jpg with the $DATA attribute. Butterfly.jpg FILE record number is 44, $DATA is Non-Resident and is using cluster number 1993.
Cluster 1993 has been reassigned.

Parse $LogFile using LogFileParser.

Check the parse result LogFile.csv.
FILE record number 43 and 44 are displayed. The DataRun value is listed in the lf_DT_DataRuns column.

Dragonfly.jpg lf_DT_DataRuns

216EC90700000000
1 ⇒ 6E ⇒ length⇒110
2 ⇒ C907 ⇒ First cluster number ⇒ 1993

Butterfly.jpg lf_DT_DataRuns

216FC90700000000
1 ⇒ 6F ⇒ length ⇒111
2 ⇒ C907 ⇒ First cluster number ⇒ 1993

By checking "lf_DT_DataRuns" in $LogFile, we were able to confirm that the cluster was reassigned.

This is butterfly effe...

Verification environment: Windows 10 1083

Reference URL:

github.com

NTFS USN Journal and ObjectID

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

Enable USN Journal on sample NTFS volumes and Copy Example.jpg to the Pictures folder.

Check the status of ObjectID, ObjectID is not set.

Using USN Analytics, parse $J and check the USN journal record.

 Open the Example.jpg file from the Photos application. 

The ObjectID is set by the operation that opened the file. (Create LNK file in Recent folder)

You can confirm that USN_REASON_OBJECT_ID_CHANGE is recorded in the USN Journal.

Delete the ObjectID. 

USN Journal will record USN_REASON_OBJECT_ID_CHANGE, but I can not identify that it was deleted.

USN Analytics will output records containing ObjectID to usn_analytics_opened.csv.

<2018/8/26 added>

It explains the ObjectID when the file is not opened.

This video is very helpful. 

www.hecfblog.com

www.hecfblog.com

www.hecfblog.com

www.hecfblog.com

www.hecfblog.com

</add>

by the way,
The author(@4n6ist) of USN Analytics is the #OSDFcon speaker.
I am looking forward to his new presentation!!

www.osdfcon.org

Reference URL:

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

docs.microsoft.com