@port139 Blog

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

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

f:id:hideakii:20181012201122j:plain

Copy the JPEG file to the E: Pictures folder using Windows Explorer.

f:id:hideakii:20181012182608j:plain

Check the file meta information with Autopsy.

f:id:hideakii:20181012185555j:plain

Delete the file and create the same file name. I should have recorded the time before deleting the file...

f:id:hideakii:20181012190026j:plain

Unlike expected results, Created timestamp was not restored.
...why?

f:id:hideakii:20181012190630j:plain

Copy the image file with a different name and test again.

f:id:hideakii:20181012191943j:plain

This time, the same file name is created by deleting the file and changing the file name.

f:id:hideakii:20181012192200j:plain

Created time stamp was not restored......why????

f:id:hideakii:20181012192741j:plain

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

f:id:hideakii:20181012193504j:plain

I will test the same operation on the C: drive.
As before, I copied the otter image to c:\Pictures folder.

f:id:hideakii:20181012195235j:plain

f:id:hideakii:20181012195634j:plain

Created timestamp has been restored.

f:id:hideakii:20181012195958j:plain

 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.

f:id:hideakii:20181012204329j:plain

f:id:hideakii:20181012204910j:plain

f:id:hideakii:20181012205330j:plain

f:id:hideakii:20181012205339j:plain

On FAT32, Created time stamp is restored.

 

 

Verification environment: Windows 10 1083

Reference URL:

www.afodblog.com

 

 

f:id:hideakii:20181012180753j:plain

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

f:id:hideakii:20180930191719j:plain

Copy the sample JPEG file to the E: drive, using the explorer.

f:id:hideakii:20180930191902j:plain

Use Autopsy to check the time stamps of $SIA and $ FN.

f:id:hideakii:20180930192156j:plain

The record containing "Basic info change" appeared twice.

f:id:hideakii:20180930192948j:plain

Use Powershell to change the timestamp of LastWriteTime. 

f:id:hideakii:20180930193233j:plain

f:id:hideakii:20180930193406j:plain

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.

f:id:hideakii:20180930193458j:plain

What happens if I unzip the ZIP file?  I created a compressed file using 7zip and expanded it from explorer.

f:id:hideakii:20180930194148j:plain

f:id:hideakii:20180930194324j:plain

A record of "Data extend | File create | Close" is recorded, followed by a record of "Basic info change".

f:id:hideakii:20180930194913j:plain

Next, unzip the ZIP file using 7zip and check the time stamp.

f:id:hideakii:20180930195148j:plain

In the case of 7zip, I was able to confirm the same output result as when copying files in Explorer.

f:id:hideakii:20180930195436j:plain

Move the sample JPEG file on the C: drive to the E: drive and check the time stamp.

f:id:hideakii:20180930200648j:plain

f:id:hideakii:20180930200809j:plain

There was an ObjectID. It was different from my expectation.

f:id:hideakii:20180930201005j:plain

Try again with a file that does not have an ObjectID.

f:id:hideakii:20180930201600j:plain

f:id:hideakii:20180930201712j:plain

f:id:hideakii:20180930201904j:plain

I forgot to confirm the pattern when I created a new file.

f:id:hideakii:20180930203112j:plain

When creating a new file, "Basic info change" is not recorded.

f:id:hideakii:20180930203144j:plain

Open the file with Notepad.exe and update the content.

f:id:hideakii:20181001191007j:plain

I updated the file, but "Basic info change" is not recorded.

f:id:hideakii:20181001191055j:plain

 

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

 

f:id:hideakii:20180930190944j:plain

Autopsy and Realloc

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

Let's create a record labeled (realloc).

f:id:hideakii:20180924082623j:plain

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.

f:id:hideakii:20180924074405j:plain

f:id:hideakii:20180924074757j:plain

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

f:id:hideakii:20180924075141j:plain

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

f:id:hideakii:20180924075413j:plain

Delete the folder F:\Example. 

f:id:hideakii:20180924080117j:plain

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

f:id:hideakii:20180924080543j:plain

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

f:id:hideakii:20180924083452j:plain

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

 

Reference URL:

 

github.com

f:id:hideakii:20180924074042j:plain

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.

f:id:hideakii:20180917193149p:plain

 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

f:id:hideakii:20180917200455p:plain

Let's copy the sample JPEG file.

f:id:hideakii:20180917193558p:plain

f:id:hideakii:20180917193814p:plain

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

f:id:hideakii:20180917195058p:plain

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

 

f:id:hideakii:20180917192011j:plain

 

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.

f:id:hideakii:20180909123928p:plain

f:id:hideakii:20180909124417p:plain

Browse the image file and check the ObjectID.

f:id:hideakii:20180909124537p:plain

Confirm that the ObjectID was given.

f:id:hideakii:20180909124611p:plain

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.

f:id:hideakii:20180909130106p:plain

Refer to multiple files and add ObjectID to $ObjID.

f:id:hideakii:20180909131314p:plain

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

f:id:hideakii:20180909131453p:plain

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

f:id:hideakii:20180909131953p:plain

Delete boat.jpg which we last referred to.

f:id:hideakii:20180909132149p:plain

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. 

f:id:hideakii:20180909132541p:plain

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

 

f:id:hideakii:20180909121904j:plain

 

 

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

f:id:hideakii:20180902125431p:plain

f:id:hideakii:20180902125704p:plain

Using the fsutil command, create an ObjectID.

f:id:hideakii:20180902130013p:plain

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

f:id:hideakii:20180902131731p:plain

Parse $LogFile.

f:id:hideakii:20180902131418p:plain

See the parse result.

f:id:hideakii:20180902134109p:plain

f:id:hideakii:20180902134214p:plain

Delete the ObjectID and check $LogFile.

f:id:hideakii:20180902134454p:plain

You can confirm that the ObjectID was deleted with DeleteAttribute.

f:id:hideakii:20180902135158p:plain

Create ObjectID again. Different ObjectIDs were created.

f:id:hideakii:20180902135458p:plain

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

f:id:hideakii:20180902141301p:plain

f:id:hideakii:20180902140949p:plain

 

 

Verification environment: Windows 10 1083

Reference URL:

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

 

f:id:hideakii:20180902124822j:plain

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.

f:id:hideakii:20180826083931p:plain

Copy Dragonfly.jpg to formatted F drive.

f:id:hideakii:20180826090059p:plain

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.

f:id:hideakii:20180826090109p:plain

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

f:id:hideakii:20180826090124p:plain

Copy Butterfly to formatted F drive.

f:id:hideakii:20180826090135p:plain

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.

f:id:hideakii:20180826090146p:plain

Parse $LogFile using LogFileParser.

f:id:hideakii:20180826091129p:plain

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.

f:id:hideakii:20180826093602p:plain

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

 

f:id:hideakii:20180826083909j:plain

 

 

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.

f:id:hideakii:20180819192719p:plain

Check the status of ObjectID, ObjectID is not set.

f:id:hideakii:20180819193135p:plain

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

f:id:hideakii:20180819193924p:plain

f:id:hideakii:20180819193934p:plain

 Open the Example.jpg file from the Photos application. 

f:id:hideakii:20180819194312p:plain

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

f:id:hideakii:20180819194434p:plain

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

f:id:hideakii:20180819195224p:plain

Delete the ObjectID. 

f:id:hideakii:20180819195658p:plain

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

f:id:hideakii:20180819200117p:plain

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

f:id:hideakii:20180820175110p:plain

<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

f:id:hideakii:20180819192043p:plain

Jumplist and Clear File Explorer history

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

Hop Step Jumplist.

Display file 5f7b5f1e01b83767.automaticDestinations-ms with HEX.
Only 'DestList' exists in this file.

f:id:hideakii:20180805162651p:plain

I started explorer and I looked up 4 image files with E: drive.

f:id:hideakii:20180805162911p:plain

Check the contents of the JumpList file. Four records that refer to the image file are displayed.

f:id:hideakii:20180805164519p:plain

Delete the history of Explorer.

f:id:hideakii:20180805163906p:plain

 

Check the contents of the JumpList file. Four records in JumpList have disappeared.

f:id:hideakii:20180805165432p:plain

However, stream data seems to remain in the JumpList file. I have studied the structure of automaticdestinations in past blog.

f:id:hideakii:20180805165732p:plain

Save the range of LNK data as binary and try to parse with LEcmd.

f:id:hideakii:20180805172629p:plain

Carving the Jump List file using Bulk_Extractor 'winlnk' option.

f:id:hideakii:20180805170023p:plain

Two records indicating the JPGE file name have been reported.

f:id:hideakii:20180805171006p:plain

I try Carving by PhotoRec. Change PhotoRec options.

f:id:hideakii:20180805201447p:plain

For geometry options, set the sector size to 1.

f:id:hideakii:20180805201638p:plain

In File Opt setting, only lnk is selected.

f:id:hideakii:20180805201818p:plain

Three files were extracted.

f:id:hideakii:20180805202003p:plain

Validate the restored LNK file.

f:id:hideakii:20180805202432p:plain

File f0003776.lnk is broken, but you can check the link destination.

f:id:hideakii:20180805202920p:plain

Testing environment:Windows 10 1803

Reference URL:

www.hecfblog.com

port139.hatenablog.com

http://www.mitec.cz/ssv.html

articles.forensicfocus.com

f:id:hideakii:20180805155622p:plain

Jumplist and File copy

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

I did not know about the artifacts in the Jumplist mentioned below. 

http://www.hecfblog.com/2018/07/daily-blog-426-directory-copy-and-paste.html

So new as of at least Windows 10 (this needs to be tested on Windows 7 and Windows 8) there is a now a jumplist that is capturing the full path of every directory that is copy and pasted.

Let's try it.
The copy source folder C:\Pictures has three JPEG image files.

f:id:hideakii:20180729203941p:plain

Delete all files in AutomaticDestinations folder.

f:id:hideakii:20180729195253p:plain

 Using Explorer, copy the C:\Picture folder to E:\.

f:id:hideakii:20180729195653p:plain

When you execute copy, you can see that two files were created.  

f:id:hideakii:20180729195849p:plain

I refer to these contents by using JumpListExplorer. (I took a copy and confirmed it later.)

f01b4d95cf55d32a.automaticDestinations-ms has no related information.

f:id:hideakii:20180729202241p:plain

5f7b5f1e01b83767.automaticDestinations-ms contains information on the C:\Pictures folder. 
I deleted the file and then operated it, but I noticed that it contains the data before deleting it. 

f:id:hideakii:20180729202444p:plain

Paste the C:\Pictures folder into E:\.

f:id:hideakii:20180729200129p:plain

 Check the contents of the JumpList file. Records of the E:\Pictures folder have been added to f01b4d95cf55d32a.automaticDestinations-ms.

f:id:hideakii:20180729204535p:plain

 5f7b5f1e01b83767.automaticDestinations-ms There is no change in the contents of the file.

f:id:hideakii:20180729205055p:plain

Open Example2.jpg under the E:\Pictures folder. 

f:id:hideakii:20180729205945p:plain

How will JumpList change?

f01b4d95cf55d32a.automaticDestinations-ms

f:id:hideakii:20180729210213p:plain

5f7b5f1e01b83767.automaticDestinations-ms

f:id:hideakii:20180729210324p:plain

The record of Example 2.jpg was added to the 5f7b5f1e01b83767.automaticDestinations-ms file.

It's an interesting file.

HM, I feel that I need to do a bit more testing.

 

<2018/07/31 add>

 

</add>

 

ps

Unfortunately I am not familiar with content that Google Translate can not use.
That is why I appreciate being posted on the blog.

 

Reference URL:

www.hecfblog.com

https://www.syntricate.com/files/computer-forensics/WINDOWS%2010%20ARTIFACT%20LIST.pdf

f:id:hideakii:20180729211616p:plain