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：
Win 10 1803 とActivitiesCache.db
Windows 10 Ver 1803 の Timeline 機能が利用している ActivitiesCache.db を確認したいと思います。
サンプルのアクティビティを作成します。Photosアプリケーションでサンプル画像を参照します。
ActivitiesCache.db ファイルは下記フォルダにあります。（ジャーナルファイルもありますね）
C:\Users\forensics\AppData\Local\ConnectedDevicesPlatform\L.forensics
DB Browser for SQLite ツールを利用し、ActivitiesCache.dbファイルを参照します。
Activityテーブルを参照します。
AppIDのカラムでアプリケーション名などを確認できます。
[{"application":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App","platform":"windows_universal"},{"application":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App","platform":"packageId"},{"application":"","platform":"alternateId"}]
Payloadカラムを参照します。
Photosアプリケーションで参照していたJPEGファイルの情報を確認できます。日本語文字列をファイル名に含めていますが、文字コードはUTF-8です。
{"displayText":"sample(サンプル).jpg","activationUri":"ms-shellactivity:","appDisplayName":"Photos","description":"C:\\Users\\forensics\\Pictures\\sample(サンプル).jpg","backgroundColor":"black","contentUri":"file:%7B33E28130-4E1E-4676-835A-98395C3BC3BB%7D/sample(サンプル).jpg","shellContentDescription":{"FileShellLink":"MBAAAEAFCAAAAAAAADAAAAAAAY0gAAAAgAAAAwjMu1n7uPdAzaBQF7u7THQGZCXfu7+0BAA8JCAAAAAABAAAAAAAAAAAAAAAAAAAAQRAUAwHQB+TQDi66kGEiiNCAsCMw0pOA4CgUrTrkkWpwUEmhvqA5HkeoaCABAgJA8uvRAAAAIXmFYP7uPdAq/o8g1u7THw0ttWYt7+0BQBAEDgMAAA8JCgsMRvqgAwUB1EUMVkfx4iSQdEAAIFAJAABA8uvyyE9qKLTqsqLAAAAVKWAAAAABAAAAAAAAAAAAAAAAAAAAcO/dAwcAEGAtBAcAwGAlBAKAULMzDz1wsOMpAgLAoGAwBwZAAAAcAgVAAAAaAw7+KAABBAcAAHAYBANAMDAoBgbAgHA0BgYAkHA5BAcAMHA2AgMAoGAoBQZAkDAzBQcAAHAkBgeAgHAuBQMAcDA5AAMAoHAlBAdAMGAAAAHAAAAADAAAQCAAAQAAAAAkAAAAUDAAAAAAAAA8CAAAIGAAAgvAAAARAAAAMAAAAw+loubQAAAAAwQ6wVVzVmczxlZvJXZuNXajNHXQl2Y0VnclNHXzFWbwxWZo8zP/8TKuoGcnBwQAoDAcBQVAMHAlBgcAMHAcBgZA8GAyBQZA4GAzBQaAMGAzBAXAAFApBwYAQHA1BgcAUGAzBAXAMHAhBQbAAHAsBQZAgCA1Cz8wcNMrDTKA4CAqBAcAcGAAAAAAAAAgBAAAMAAAAKWAAAAAAAAAQWZztGdvBXLyETO2EnN4AAuQpo/RFeKAp5UKhgCWucHr/GAGFuWoHxktgAAnwcsegLUK6fUhnCQaOlSIoglL3x6vBgRhrF6RMZLIAwJMHrHFBAAAkAAAAaOAAAAxMFUTFrFtRUrNCHSniEQuQaP4xYHAAAAoBAAAAASAAAADcrWtCAAAAAAAAmIAAAAAAAAAAAAAAAAAAAAAA"}}
contentUriを確認します。GUID 33E28130-4E1E-4676-835A-98395C3BC3BB は Pictures フォルダを意味しています。
"file:%7B33E28130-4E1E-4676-835A-98395C3BC3BB%7D/sample(サンプル).jpg"
FileShellLink項目が興味深いです。
Base64でエンコードされたバイナリデータだと思われますが、このデータは何でしょうかね？
{"FileShellLink":"MBAAAEAFCAAAAAAAADAAAAAAAY0gAAAAgAAAAwjMu1n7uPdAzaBQF7u7THQGZCXfu7+0BAA8JCAAAAAABAAAAAAAAAAAAAAAAAAAAQRAUAwHQB+TQDi66kGEiiNCAsCMw0pOA4CgUrTrkkWpwUEmhvqA5HkeoaCABAgJA8uvRAAAAIXmFYP7uPdAq/o8g1u7THw0ttWYt7+0BQBAEDgMAAA8JCgsMRvqgAwUB1EUMVkfx4iSQdEAAIFAJAABA8uvyyE9qKLTqsqLAAAAVKWAAAAABAAAAAAAAAAAAAAAAAAAAcO/dAwcAEGAtBAcAwGAlBAKAULMzDz1wsOMpAgLAoGAwBwZAAAAcAgVAAAAaAw7+KAABBAcAAHAYBANAMDAoBgbAgHA0BgYAkHA5BAcAMHA2AgMAoGAoBQZAkDAzBQcAAHAkBgeAgHAuBQMAcDA5AAMAoHAlBAdAMGAAAAHAAAAADAAAQCAAAQAAAAAkAAAAUDAAAAAAAAA8CAAAIGAAAgvAAAARAAAAMAAAAw+loubQAAAAAwQ6wVVzVmczxlZvJXZuNXajNHXQl2Y0VnclNHXzFWbwxWZo8zP/8TKuoGcnBwQAoDAcBQVAMHAlBgcAMHAcBgZA8GAyBQZA4GAzBQaAMGAzBAXAAFApBwYAQHA1BgcAUGAzBAXAMHAhBQbAAHAsBQZAgCA1Cz8wcNMrDTKA4CAqBAcAcGAAAAAAAAAgBAAAMAAAAKWAAAAAAAAAQWZztGdvBXLyETO2EnN4AAuQpo/RFeKAp5UKhgCWucHr/GAGFuWoHxktgAAnwcsegLUK6fUhnCQaOlSIoglL3x6vBgRhrF6RMZLIAwJMHrHFBAAAkAAAAaOAAAAxMFUTFrFtRUrNCHSniEQuQaP4xYHAAAAoBAAAAASAAAADcrWtCAAAAAAAAmIAAAAAAAAAAAAAAAAAAAAAA"}
HEXでデコードすると下記になるようです。
30 10 00 00 40 05 08 00 00 00 00 00 00 30 00 00 00 00 01 8d 20 00 00 00 80 00 00 03 08 cc bb 59 fb b8 f7 40 cd a0 50 17 bb bb 4c 74 06 64 25 df bb bf b4 04 00 3c 24 20 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 04 40 50 0c 07 40 1f 93 40 38 ba ea 41 84 8a 23 42 02 c0 8c c3 4a 4e 03 80 a0 52 b4 eb 92 45 a9 c1 41 26 86 fa 80 e4 79 1e a1 a0 80 04 08 09 03 cb af 44 00 00 00 85 e6 15 83 fb b8 f7 40 ab fa 3c 83 5b bb 4c 7c 34 b6 d5 98 b7 bf b4 05 00 40 10 38 0c 00 00 3c 24 28 2c 31 1b ea 80 0c 14 07 51 14 31 59 1f c7 88 92 41 d1 00 00 81 40 24 00 01 03 cb af cb 21 3d a8 a2 d3 aa ca 8b 00 00 00 54 a5 80 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 c3 bf 74 0c 1c 00 41 80 b4 10 1c 03 01 80 94 10 0a 01 42 cc cc 3c f5 c2 c3 8c a4 08 0b 02 81 80 c0 1c 19 00 00 00 70 08 15 00 00 00 68 0c 3b f8 a0 00 04 10 1c 00 01 c0 60 10 0d 00 c0 c0 a0 18 1b 02 01 c0 d0 18 18 02 41 c0 e4 10 1c 00 c1 c0 d8 08 0c 02 81 80 a0 14 19 02 40 c0 cc 14 1c 00 01 c0 90 18 1e 02 01 c0 b8 14 0c 01 c0 c0 e4 00 0c 02 81 c0 94 10 1d 00 c1 80 00 00 07 00 00 00 00 30 00 01 00 80 00 04 00 00 00 00 90 00 00 01 40 c0 00 00 00 00 00 00 f0 20 00 00 81 80 00 08 2f 00 00 00 44 00 00 00 c0 00 00 0c 3e 96 8b 9b 40 00 00 00 0c 10 eb 05 55 cd 59 9c cf 19 59 bc 95 d9 b8 d5 da 8c d1 d7 42 5d 98 d1 59 dc 94 d1 d7 cc 55 9b c3 15 99 a3 cc cf ff c4 ca ba 81 9c 9c 1c 10 02 80 c0 70 14 15 00 c1 c0 94 18 1c 00 c1 c0 70 18 19 03 c1 80 c8 14 19 03 81 80 cc 14 1a 00 c1 80 cc 10 17 00 01 40 a4 1c 18 01 01 c0 d4 18 1c 01 41 80 cc 10 17 00 c1 c0 84 14 1b 00 01 c0 b0 14 19 02 00 80 d4 2c fc c1 c3 4c ac 34 ca 03 80 80 a8 10 1c 01 c1 80 00 00 00 00 00 00 80 10 00 00 c0 00 00 02 96 00 00 00 00 00 00 01 05 99 ce d1 9d bc 15 cb c8 44 ce d8 49 cd e0 00 2e 42 9a 3f 44 57 8a 02 9e 54 2a 18 02 5a e7 07 af f1 80 18 5b 96 a0 7c 64 b6 00 00 9f 07 2c 7a 02 d4 2b a7 d4 86 70 90 68 e9 52 22 88 25 2f 7c 7a bc 18 11 86 b1 7a 44 c6 4b 20 0c 09 30 7a c7 14 10 00 02 40 00 00 06 8e 00 00 00 c4 c1 54 4c 5a c5 b5 15 2b 34 21 d2 9e 21 10 b9 06 8f e3 16 07 00 00 00 a0 10 00 00 00 12 00 00 00 0d ca d6 b4 20 00 00 00 00 00 09 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FileShellLinkって何ですか？
参考URL:
Windows 10 Timeline Forensic Artefacts – CCL Group
Windows 10 Timeline Forensic Artefacts – Cyber Forensicator
JumpList と DestList
JumpList 内の DestList を確認します。
DestListのDirectory entry(128byte)は下記になります。
44006500730074004C00690073007400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ⇒ DestList
12 00 ⇒ 18（The byte size of the directory name including the end-of-string character）02 ⇒ stream
01 ⇒ black
0C 00 00 00 ⇒ 12（The directory identifier of the previous directory entry）
FF FF FF FF ⇒ The directory identifier of the next directory entry
FF FF FF FF ⇒ The directory identifier of the sub directory entry
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ⇒ Class identifier
00 00 00 00 ⇒ User flags
00 00 00 00 00 00 00 00 ⇒ Creation time
00 00 00 00 00 00 00 00 ⇒ Modification time
1C 00 00 00 ⇒ 28 （Sector identifier (SID) of the first sector of the directory）
76 08 00 00 ⇒ 2,166 (The byte size of the directory）
00 00 00 00 ⇒ Reserved
Structured Storage Viewerでも確認してみます。
「A forensic insight into Windows 10 Jump Lists」を参考に、DestListのヘッダをパースしてみます。
04 00 00 00 ⇒ 4 ⇒ Version number
0A 00 00 00 ⇒ 10 ⇒ Total number of current Entries
04 00 00 00 4 ⇒ Total number of pinned Entries
8F C2 AA 42 ⇒ Unknown value
0B 00 00 00 00 00 00 00 ⇒ 11 ⇒ Last Issued Entry ID number
1C 00 00 00 00 00 00 00 ⇒ 28 ⇒ Number of add/delete/re-open actions
「A forensic insight into Windows 10 Jump Lists」を参考に、DestList Entryをパースします。
76 09 DE 3D 94 6C 6C EF ⇒ A checksum or hash of the Entry
0A 51 AE 1B E0 3A E1 4A BD AB 84 21 59 48 3E 0B ⇒ New Volume ID
29 48 53 A2 AD C1 E7 11 A2 16 08 00 27 A8 3F 6E ⇒ New Object ID
0A 51 AE 1B E0 3A E1 4A BD AB 84 21 59 48 3E 0B ⇒ Birth Volume ID
29 48 53 A2 AD C1 E7 11 A2 16 08 00 27 A8 3F 6E ⇒ Birth Object ID
64 65 73 6B 74 6F 70 2D 69 36 6D 65 6F 36 34 00 ⇒ desktop-i6meo64. ⇒ NetBIOS Name padded with zero
07 00 00 00 ⇒ 7 ⇒ Entry ID number
00 00 00 00 00 00 B8 41 ⇒ ？
3B 09 3F B2 BE 55 D3 01 ⇒ 11/4/2017 10:46:04 PM ⇒ MSFILETIME of last recorded access
FF FF FF FF ⇒ Entry pin status
02 00 00 00 ⇒ ？
08 00 00 00 ⇒ (access count）
00 00 00 00 00 00 00 00
07 00 ⇒ Length of Unicode string data
43 00 3A 00 5C 00 63 00 61 00 73 00 65 00 ⇒ C.:.\.c.a.s.e.
Object IDのタイムスタンプを確認します。
29 48 53 A2 AD C1 E7 11
↓
29 48 53 A2 AD C1 E7 01
↓
137291265154959401 - 5748192000000000
↓
131543073154959401
↓
01D355BA64108829
↓
Sat, 04 November 2017 22:15:15 UTC
同じ内容を JLECmd で確認できます。ObjectIDのタイムスタンプはCreateed on:となります。
JumpListViewではLast modifiedがRecord Timeになります。
Plaso 20180127 の出力結果は下記になります。LOGのタイムスタンプがLast modifiedですね。
参考URL：
http://cyberforensicator.com/wp-content/uploads/2017/01/1-s2.0-S1742287616300202-main.2-14.pdf
https://tzworks.net/prototypes/jmp/jmp.users.guide.pdf
