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

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.

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

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

Delete the history of Explorer.

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

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

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

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

Two records indicating the JPGE file name have been reported.

I try Carving by PhotoRec. Change PhotoRec options.

For geometry options, set the sector size to 1.

In File Opt setting, only lnk is selected.

Three files were extracted.

Validate the restored LNK file.

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

Testing environment:Windows 10 1803

Reference URL:

www.hecfblog.com

port139.hatenablog.com

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

articles.forensicfocus.com

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.

Delete all files in AutomaticDestinations folder.

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

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

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

f01b4d95cf55d32a.automaticDestinations-ms has no related information.

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. 

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

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

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

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

How will JumpList change?

f01b4d95cf55d32a.automaticDestinations-ms

5f7b5f1e01b83767.automaticDestinations-ms

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>

Look at the mru time of the entry versus the creation time of the directory

— David Cowen (@HECFBlog) July 30, 2018

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

NTFS $REPARSE_POINT and Symbolic link(2)

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

Last week I checked the symbolic link using the mklink command.  The Symbolic link reparse data has a field of Print name, but the mklink command can not set the Print name.

Using CreateNtfsSymlink included in symboliclink-testing-tools, you can specify Print name.

Without specifying Print name, create a symbolic link and check the result. AS a result of the DIR command, the contents of <SYMLINK> shows [example.png].

Next, specify the Print name and create a symbolic link. The reference destination information of <SIMLINK> is test_print_name, it is not the information of the destination.

The FILE record number is 58.
By the way, Reparse Point is displayed in Flags of $ SIA. I did not notice it last week.

Look at offset 59392 in $ MFT.

0C 00 00 A0 Reparse point tag ⇒ Symbolic link
4C 00 Reparse data size ⇒ 76
00 00 Reserved
00 00 Substitute name offset ⇒ 00
1E 00 Substitute name size ⇒ 30
20 00 Print name offset ⇒ 32
1E 00 Print name size ⇒ 30
00 00 00 00 Symbolic link flags
5C003F003F005C006500780061006D0070006C0065002E0070006E006700 \??\example.png
0000
74006500730074005F007000720069006E0074005F006E0061006D006500 test_print_name 

Let's create Junction or mount point reparse data. If Print name is not specified, the link destination is displayed. 

Create the mount point by specifying Print name.

Using MFTECmd Version 0.2.9.1, confirm the parsing result of $MFT.

Sample VHD Disk.

Reference URL:

tyranidslair.blogspot.com

github.com

A simple way to access Shadow Copies in Vista – Antimail

NTFS $REPARSE_POINT and Symbolic link

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

Today, I would like to confirm the NTFS symbolic link.
Copy the JPEG file to the sample VHD Disk.

Use the mklink command for this JPEG file to create a symbolic link.
The link name is exempl.jpg.

When browsed from the explorer, it can be identified by the icon image.

Use Autopsy to browse this volume. It seems difficult to identify a symbolic link from the file list.

You can find $REPARSE_POINT in the Attributes field.

Let's look at $REPARSE_POINT (0xC0) in the FILE record.
Display offset 44032 in $ MFT. The range enclosed in red color starting from 0xC0 is $REPARSE_POINT.

The range of 0C0000A0 enclosed in light blue is Reparse point tag. 0xa000000c means Symbolic link.

0C 00 00 A0 Reparse point tag ⇒ Symbolic link
34 00 Reparse data size ⇒ 52
00 00 Reserved
14 00 Substitute name offset ⇒ 20
14 00 Substitute name size ⇒ 20
00 00 Print name offset
14 00 Print name size ⇒ 20
01 00 00 00 Symbolic link flags
730061006D0070006C0065002E006A0070006700 sample.jpg
730061006D0070006C0065002E006A0070006700 sample.jpg
00000000

 Using MFTECmd is simpler than visual inspection. 

 I do not know what "g" means....Interesting....The character at the end of the file is at the beginning.

<2018/07/17 add >

so i found and fixed a goofy fringe issue based on this post. Grab MFTECmd 0.2.8.0 and see how it looks now. For some reason, the print name offset was 0. i was off by 2 in this case as well, but it should be good now. More test data FTW! pic.twitter.com/wGMmFRNsy2

— Eric Zimmerman (@EricRZimmerman) July 16, 2018

 </add>

Delete sample.jpg and overwrite the FILE record.

 

By creating sample.txt, sample.jpg can not be confirmed.
If you use MFTECmd, you can find example.jpg with the value of ReparseTarget.

When you find a symbolic link, let's check the reference.

Sample VHD Disk.

Reference URL:

github.com

Local Privilege Escalation in Emsisoft Anti-Malware by abusing NTFS Directory Junctions #AVGater » #bogner.sh