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:
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:
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.
Reference URL:
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.
Reference URL:
$ATTRIBUTE_LIST and deleted record
Note:I translated Japanese into English using Google Translate.
Thank you, Google.
I will use the sample VHD Disk created last week.
$ATTRIBUTE_LIST of FILE record 39 is as follows. Several $FILE_NAME saved in FILE record number 40.
Filename00000001.txt is saved in FILE record number 40. At the end of this FILE record, the $DATA attribute is stored.
Delete filename00000001.txt and confirm the FILE record 40.
You can check the character string of filename00000001.txt with Slack of FILE record number 40.
However, since only one $FILE_NAME attribute has been deleted, we can not find filename00000001.txt as a deleted file.
Is it possible to delete two FILE records referenced by $ATTRIBUTE_LIST at the same time? I'd like to verify whether an inconsistency occurs due to deleting and overwriting the FILE record referenced by $ATTRIBUTE_LIST.
To test another scenario, return the VHD disk to its original state.
Delete all files.
Let's check the state after deletion....Unfortunately, it was different from what I expected.
Is it the result of the Del command sequentially deleting files? , Only filename 00000007.txt file will be displayed.
I will try another method.
Check the status of $ATTRIBUTE_LIST.
FILE records 40 and 41 are used.
Delete folder1.
The following figure is the result I was expecting.....Aaaa, I misunderstood the result.
The above figure contained $I30 parsing result. When referenced by other tools, only filename0000007.txt is displayed in the deleted file.
I have created another VHD disk.
$SIA of filename00000006.txt is stored in FILE record 39, and $FILE_NAME is stored in FILE record 40.
Create a new file and overwrite the FILE record 39.
FILE record 40 remains, but Autopsy can not refer to filename00000006.txt.
Export $MFT and parse it with fte tool. I can find filename00000006.txt. Thank you fte, I wanted to confirm this result.
Overwrite the FILE record with another pattern.
$SIA is stored in FILE record 40, $FILE_NAME is stored in FILE record 39.
Delete files other than filename00000001.txt.
Create a file and overwrite the FILE record 39. $SIA is in FILE record 40, but $FILE_NAME does not exist. Some tools do not display $SIA in FILE record 40.
Does your favorite tool display $SIA of FILE record 40?
Well, how do I visualize the FILE record 40?
For example, there is a way to use Plas MFT parser.
>log2timeline.exe --parsers mft --artifact_filters NTFSMFTFiles c:\case\mft.plaso c:\case\Atrribute9.vhd
>psort -o l2tcsv -w c:\case\mft_timeline.csv c:\case\mft.plaso
FILE Record 40 $SIA was confirmed.
by the way,
Google Translate shows multiple candidates for a single word, but suffers from choosing which one is right. For example, check and confirm.
Reference URL:
http://www.kazamiya.net/en/fte
it appears MFTECmd behaves appropriately in this case. Tools that to not follow attribute lists to other MFT entries or manually track extension records miss data. many tools do not do this correctly pic.twitter.com/b702mh2khT
— Eric Zimmerman (@EricRZimmerman) July 7, 2018
$MFT と $ATTRIBUTE_LIST
Note:
For experimental purposes, I use Google Translate to convert Blog to English.Unfortunately, I do not know whether it was translated into an appropriate English expression.Please let me know if there is a more appropriate expression.
There are many tools to parse $MFT, but the processing result of $ATTRIBUTE_LIST varies depending on the tool.
I would like to confirm about $ATTRIBUTE_LIST.
Create a test file in the sample VHD disk.
Use the fsutil command to create several hard links.By executing the following command, the attribute will not fit all in one FILE record.
In the $MFT file, reference the FILE record of Filename 00000001.txt.
You can see that there is a $ ATTRIBUTE_LIST (0x20) attribute in the FILE record.
In the example below, this attribute is Resident.
When you refer to the same file with Autopsy, it becomes as follows.
The MFT record number of Filename 00000001.txt is 39. In addition, you can check that this file is using record number 40 as well.
(Type 48 (0x30) is the $FILE_NAME attribute.)
Reference record number 40 in the $ MFT file.
"File reference to the base FILE record" indicates 39 (0x27).
When parsing this $MFT file with fte tool, it becomes as follows.
The $FILE_NAME attribute stored in record number 40 is also displayed.
The result of parsing the same $MFT file with MFTECmd is as follows.
Both tools display seven sample files.
However, when parsing the $MFT file, depending on the tool, all file names are not displayed due to $ATTRIBUTE_LIST.
<Added 2018/7/3>
There are several tools affected by $ATTRIBUTE_LIST. One example is Plaso MFT parser.
I will try parsing $MFT using the MFT parser of plaso-20180630.
Artifacts filter is available in Plaso-20180630. I'm not familiar with it yet, but it's a very interesting feature.
c:\case\plaso-20180630-amd64>log2timeline.exe --parsers mft --artifact_filters NTFSMFTFiles c:\case\mft.plaso c:\case\Atrribute1.vhd
Use the psort command to output the timeline in l2tcsv format.
You can find file names 2 and 7, but you can not find file names 1, 3, 4, 5, and 6.
</Added>
Sample VHD file.
By the way, I did not know that the fsutil command has a layout option.
it seems that it doesn't mean anything pic.twitter.com/Nxg05FXzaL
— Costas K (@sv2hui) June 28, 2018
The Layout option seems to be available from Win 10 ver 1803.
参考URL：
MFTECmd と $EA
NTFSの$MFTファイルをパースするツール”MFTECmd”をEricさんがリリースしています。素晴らしいツールをありがとうございます！
<2018/6/27 Add>ｖ0.2.6.0がリリースされています</add>
セキュリティキャンプ2018でE6トラックを選択する若者達には、ぜひ調査で利用していただきたいツールです。
初めて利用するので、ツール利用方法の確認と、$EA属性が確認できるかを見てみます。
まず、サンプルの画像ファイルを準備します。 ファイルサイズは33.2KBです。
この画像ファイルを、EaToolsを利用してNTFSの$EA属性へ保存します。
$MFTでFILEレコードを確認します。$EA属性が追加されている事を確認できます。
DataRunの値から、クラスタ2009にデータが保存されている事が分かります。
Autopsy 4.7.0でも確認してみます。ストリームの名前が確認できないようですが、データが存在する事は識別できます。
$MFTファイルをエクスポートし、MFTECmd 0.2.5.0でパースします。
結果を確認します。SiFlags値が数字？
<6/24 added>
SiFlags値が262176となっていました、$SI を参照すると下記の状態になっています。
00 04 00 20
File attribute flagsを参照すると0x00000020 FILE_ATTRIBUTE_ARCHIVEは確認できますが、04 00 00は記載がありません。PowerMftの説明では、ea = 0x00040000となっていますね。
次のリリースではHasEAフラグが登場ということです。これは便利です！
For example: You wont see the integer in the SIFlags column after the next release too now that i added the HasEA flag
— Eric Zimmerman (@EricRZimmerman) June 23, 2018
--deオプションを利用すれば、EA属性を確認できる事に気が付いていませんでした。
MFTECmd.exe -f c:\case\MFT\$MFT --de 39-1
次のバージョンでは下記のようになるそうです。楽しみですね！
this is in the next release. notice how you can see the bytes from the EA.
— Eric Zimmerman (@EricRZimmerman) June 23, 2018
example command to see this detail: .\MFTECmd.exe -f 'D:\SynologyDrive\MFTs\vanko\vanko_MFT' --de 0x46EE1-0x2
Get the entry and seq info from the CSV pic.twitter.com/lKltiDbC9J
</added>
もしかすると、私だけかもしれませんが、属性一覧と、DataRun値のパース結果が、MFTECmdの出力結果に含まれていると便利ではないでしょうか。
※上記で作成したサンプルVHDディスク
参考URL：
Introducing MFTECmd! Give it a whirl!! https://t.co/2OgzfctTnJ #DFIR
— Eric Zimmerman (@EricRZimmerman) June 22, 2018
ActivitiesCache.dbとアクティビティ削除(3)
先週の続きです。
OSの日付を6月25日へ変更し、レコード削除を発生させます。
OSを再起動し、-wal ファイルがActivitiesCache.dbへ反映された状態にします。
ActivitiesCache.dbファイルをHEXで参照し、ファイル名を検索してみます。
DeleteSample.jpgを発見できます。
更に古い情報もまだ残っていますね。
さて、これらの削除レコードを復元するにはどうするのが良いでしょうか？
削除レコードを復元できるツールは幾つかありますので、今後色々と試してみたいと思います。
参考URL:
SQLite database format - ForensicsWiki
ActivitiesCache.dbとアクティビティ削除(2)
先週の続きです。
テスト環境は先週からずっとシャットダウンしていましたので、先ほど起動しました。
アクティビティの状態を確認します、アクティビティには何も表示されません。
ActivitiesCache.dbファイルをエクスポートします。
ActivitiesCache.dbファイルの最終更新日時は5月26日のままです。（-walファイルは現在の日付）
ジャーナルを含めてActivitiesCache.dbファイルを参照します。
最初に、Activityテーブルを参照します。38番レコードが、先週削除したサンプルですが、レコード内容を確認できます。
ActivityOperationテーブルも同様に確認すると、レコードを確認できます。
日付を変更してから、OS[を再起動します。（ExpirationTime⇒1529875249⇒Mon, 25 June 2018 06:20:49 +0900）
ActivitiesCache.dbファイルをエクスポートし、ジャーナルを含めて参照します。
この日時では、レコードが削除されている事を確認できます。
テストファイルのタイムスタンプを確認します、ジャーナルだけが新しい日付です。
ジャーナルファイルを削除し、ActivitiesCache.dbファイルだけを参照してみます。
削除前のレコードを確認できます。
ジャーナルが反映されていない状況では、ジャーナル無しでファイルを参照する必要がありますね。
削除レコードの復元が可能かは確認していません。
参考URL：
ActivitiesCache.dbとアクティビティ削除
アクティビティを削除し、ActivitiesCache.db内でどのような変化が発生するかを確認します。テスト環境は Win 10 1803 です。
サンプルのJPEG画像ファイルを参照し、アクティビティを作成します。
Activityテーブルでレコードを確認します。38番レコードにJPEG画像ファイルの情報があります。
アクティビティから項目を削除します。
Activityテーブルで38番レコードを再度確認します。（ジャーナルファイルを含めてデータベースファイルを参照）
レコードが残っており、情報を確認する事ができます。
また、ActivityOperationテーブルに、レコードが追加されている事を確認できます。
ActivityOperationテーブルには、OperationTypeというカラムがあります。3は削除操作という意味でしょうか？
アクティビティを一つ削除しましたが、このテーブルには2つのレコードが登録されています。
また、これら2件のレコードについては、Etag値はActivityテーブルとActivityOperationテーブルで異なるようです。
先週テストしたアクティビティのデータを削除してみます。
Activityテーブルでは、削除したアクティビティに関する情報を確認できます。
ActivityOperationテーブルを確認します。AppActivityIdは同じですが、ActivityType 6のレコードだけが追加されています。ActivityType 5 のレコードは追加されていません。
いずれのレコードも、OperationTypeは3になっています。
これらのレコードが本当に削除されるのは何時でしょうか？
参考URL：
