Registry Transaction LogとPlaso
Registry Explorerを利用する事で、レジストリのトランザクションログファイルを反映したハイブファイルを作成できます。
トランザクションログを反映した、SYSTEMハイブファイルを利用し、タイムラインを作成してみます。
トランザクションログを反映したSYSTEMハイブファイルは、002フォルダ配下に置いてあります。
Plaso(plaso-20180127)のLog2timelineを実行します。
pinfoコマンドを利用し、エラーを確認します。チェックサムが一致しないようです。
> pinfo c:\case\Winreg_tl.db
レジストリファイル内のチェックサムオフセット位置については、 「Windows registry file format specification」で位置を確認できます。
オフセット位置508を参照します。チェックサムが0x746B8159となっている事を確認できます。
チェックサムの値を、59から5Aに書き換えます。
チェックサムを書き換えたレジストリファイルに対して、Log2timeline を実行します。
> pinfo c:\case\Winreg_tl2.db
エラー無く処理された事を確認できます。
psortコマンドを使いタイムラインを出力します。
トランザクションログを反映した、レジストリのタイムラインを作成できました。
参考URL：
Bam KeyとTransaction Log
HKLM\SYSTEM\CurrentControlSet\Services\bam\ キーを引き続き確認します。
今回はレジストリのTransaction Logを、Registry Explorer/RECmd Version 1.0.0.0を使って参照したいと思います。
Live環境でのトランザクションログの取得には、RawCopyを利用します。
コピーのタイミングとしては、若干のズレが発生する可能性が考えられます。（BATファイルでコマンド実行しています。）
REM C:\Windows\System32\config\SYSTEM
RawCopy /FileNamePath:C:79240 /OutputPath:C:\CaseREM C:\Windows\System32\config\SYSTEM.LOG1
RawCopy /FileNamePath:C:79219 /OutputPath:C:\CaseREM C:\Windows\System32\config\SYSTEM.LOG2
RawCopy /FileNamePath:C:79218 /OutputPath:C:\Case
もしかすると、VSSでスナップショットを作成してからファイルを確認する方が確実かもしれません。
サンプルのプログラムとしてfteを実行します。
RawCopyでコピーしたSYSTEMハイブをRegistry Explorerで読み込みます。Dirtyハイブである事が検知されます。
下記では、Dirtyハイブロードしました。
まず、DirtyハイブでBAMキーと値を確認します。タイムスタンプが 2018-03-03 00:54:51 である事を確認できます。
次に、トランザクションログ（LOG1）を反映したSYSTEMハイブでBAMキーと値を確認します。タイムスタンプが 2018-03-03 01:29:44 である事を確認できます。
次に、トランザクションログ（LOG2）を反映したSYSTEMハイブでBAMキーと値を確認します。タイムスタンプが 2018-03-03 00:54:51 である事を確認できます。
トランザクションログを適用する事で、最新の情報を確認できる事が分かります。
参考URL:
https://twitter.com/errno_fail/status/967831155310518272
https://twitter.com/EricRZimmerman/status/968897244232671234
http://ericzimmerman.github.io/
https://twitter.com/4n6k/status/968315227350749184
https://www.linkedin.com/pulse/alternative-prefetch-bam-costas-katsavounidis
bam key と Program execution
HKLM\SYSTEM\CurrentControlSet\Services\bam\ キーに記録される、プログラム実行の痕跡について検証された記事が下記で参照できます。
私もこのレジストリキーについて検証してみたいと思います。
テスト環境は Windows 10 ver 1709 です。
テスト開始時点における、レジストリキーは、下記の状況です。すでに、幾つかのプログラム実行に関連した値が登録されています。
プログラム実行のサンプルとして、APT Simulatorを実行します。RUN EVERY TESTを選択しています。
APT Simulatorの実行後、レジストリキーを確認します。PowerShellやWscriptなどの値が追加された事を確認できます。
システムを再起動します。
再起動後、mim.exe と p.exe の値が新たに登録されている事を確認できます。これらは、UserInitMprLogonScriptとRunキーに登録されているプログラムです。
値には、FILETIMEが含まれているようですが、更新タイミングの詳細については未確認です。再起動しなくても、タイムスタンプが変化しているような気もします。
シフトキーを5回押し、cmd.exeを起動した後のレジストリキーは下記になります。タイムスタンプがCMD.EXEを起動した日時に変化しています。
タイムスタンプの更新については、id:kasasagi_fさんがテストされていますので、そちらも参照してください。
参考URL：
Background Activity Moderator Driver - Windows 10 Service - batcmd.com
USN Analytics と Folder
Forensicistさんが、USN Analyticsツールを公開されています。USN Analytics ツールは、$J をパースするだけでなく、フォルダ構造も解析してくれます。
つまり、$MFT ファイルを利用せずに、フォルダ構造をある程度再現できます。
サンプルのフォルダ構造を、テスト用の NTFS ボリューム上に作成します。
E:\>mkdir folder1
E:\>cd folder1
E:\folder1>mkdir folder2
E:\folder1>copy c:\case\sample.jpg e:\folder1\folder2\
USN Analytics で $J をパースした結果は下記になります。Path のカラムでフォルダ構造を確認できます。
次に、Folder1 を削除し、新規にファイルを作成します。新規ファイルを作成した事により、Folder1 の FILE レコードが上書きされます。
E:\>rmdir /S /Q folder1
E:\>echo sample > zaki.txt
sample.jpg ファイルは $OrphanFiles 配下で確認できます。
USN Analytics の結果を確認します。Sample.jpg の Path から、Folder1 が過去に存在していた事を確認できます。
更にファイルを作成し、Folder2 と Sample.jpg の FILE レコードを上書きします。
E:\>echo sample2 > zaki2.txt
E:\>echo sample3 > zaki3.txt
$OrphanFiles 配下には痕跡が残っていません。
USN Analytics の結果を確認します。これまでの操作状況が分かります。
フォルダを作成し、USN Journal を削除します。
E:\>mkdir folder1
E:\>fsutil usn deletejournal /D E:
USN Journal を有効にし、フォルダとファイルを作成します。$J 内に、Folder1 を作成した記録はありません。
E:\>cd folder1
E:\folder1>mkdir folder2
E:\folder1>copy c:\case\sample.jpg folder2
E:\folder1>rmdir /S /Q folder2
USN Analytics の結果を確認します。Sample.jpg の Path は Folder2 から表示されています。Folder2 の Delete が無い？
-r オプション指定し、再度プログラムを実行します。Folder2 の削除を確認できました。
素晴らしい！！
参考URL;
http://www.jpcert.or.jp/present/2018/JSAC2018_03_yamazaki.pdf
Fixup と Update Sequence Number
NTFS の Fixup 値と update sequence について確認します。Fixup については NTFS Documentation を参照します。
サンプルの画像ファイル coin.jpg を E: ドライブへコピーし、MFT ファイルでFile レコードを確認します。coin.jpg ファイルの File レコード番号は 39、シーケンス番号は 1 です。
MFTファイル内のレコード番号39（1024 x 39 = 399,936 ）を参照します。
下記 FILE レコードでは、オフセット位置 4 にある Offset to the update sequence 値が 30 00 （⇒ 48）となっています。
30 00 Offset to the update sequence ⇒ 48
03 00 Size in words of Update Sequence Number & Array (S) ⇒ 3
オフセット位置 48 からの 2 バイト、03 00 が update sequence になります。
上記図では、セクタの終わりにある 00 00 が FixUp 値 03 00 と入れ替えられている状態です。
次に、coin.jpg ファイルの名前を変更しレコードをアップデートしてみます。
>ren e:\coin.jpg NotCoin.jpg
MFTファイル内のレコード番号39（1024 x 39 = 399,936 ）を参照します。
レコードの更新により、update sequence が 04 00 となっている事を確認できます。
次に、この JPEG ファイルを削除します。
>del e:\NotCoin.jpg
MFTファイル内のレコード番号39 を参照します。
レコードの更新により、update sequence が 05 00 となっている事を確認できます。
また、ファイルが削除された事により、File レコードのシーケンス番号は 2 になった事を確認できます。
レコードを再利用してみます。
>echo "Ancient Andes" > e:\gold.txt
MFTファイル内のレコード番号39 を参照します。
レコードが再利用され、update sequence が 02 00 となっている事を確認できます。
参考URL：
http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf
$INDEX_ALLOCATION (0xA0)とVirtual Cluster Number (VCN)
「Folderと$BITMAP (0xB0)」の続きです。
Windowsフォルダの $BITMAP (0xB0) は下記の状態です。VCN 0 から VCN 5 までが利用されている事を確認できます。
3F 00 00 00 00 00 00 00
↓0 0 1 1 1 1 1 1 ⇒ Bitmap ⇒ クラスタの利用状況
LCNとVCNの関係は下記となっています。これは、 ”Windows”フォルダの $INDEX_ALLOCATION (0xA0)と、VCN of this INDX buffer in the Index Allocation の内容から確認できます。
LCN 984 ⇒ VCN 0
LCN 985 ⇒ VCN 1
LCN 986 ⇒ VCN 2
LCN 987 ⇒ VCN 3
LCN 988 ⇒ VCN 4
LCN 989 ⇒ VCN 5
これらのクラスタが、どの様に繋がっているかを確認してみます。
$INDEX_ROOT (0x90)
まず$INDEX_ROOT (0x90)で利用しているVCNを確認します。Flags値から、Large indexが必要となっている事を確認できます。
Resident, Named
90 00 00 00 Attribute Type
58 00 00 00 Length (including this header)
00 Non-resident flag
04 Name length
18 00 Offset to the Name
00 00 Flags
06 00 Attribute Id (a)
38 00 00 00 Length of the Attribute
20 00 Offset to the Attribute (b)
00 Indexed flag
00 Padding
24 00 49 00 33 00 30 00 ⇒ $I30
Index Root
30 00 00 00 Attribute Type
01 00 00 00 Collation Rule
00 10 00 00 Size of Index Allocation Entry (bytes) ⇒ 4096
01 Clusters per Index Record ⇒ 1
00 00 00 Padding (Align to 8 bytes)
Index Header
10 00 00 00 Offset to first Index Entry ⇒ 16
28 00 00 00 Total size of the Index Entries ⇒ 40
28 00 00 00 Allocated size of the Index Entries ⇒ 40
01 Flags ⇒ Large index (Index Allocation needed)
00 00 00 Padding (align to 8 bytes)
Index Entry
00 00 00 00 00 00 00 00 File reference
18 00 Length of the index entry
00 00 Length of the stream
03 Flags ⇒ ？？
00 00 00
05 00 00 00 00 00 00 00 VCN of the sub-node in the index allocation attribute
上記 Index Entry から、INDEX_ROOTからVCN 5 が参照されている事を確認できます。
次に、VCN 5の内容を確認してみます。
VCN 5（LCN 989）
VCN 5 （LCN 989）の Index Record を確認します。
Index Header
49 4E 44 58 Magic number 'INDX'
28 00 Offset to the Update Sequence
09 00 Size in words of the Update Sequence Number &Array (S)
9D 06 82 0C 00 00 00 00 $LogFile sequence number
05 00 00 00 00 00 00 00 VCN of this INDX buffer in the Index Allocation ⇒ 5
28 00 00 00 Offset to the Index Entries (a)
F8 01 00 00 Size of Index Entries (a) ⇒ 504
E8 0F 00 00 Allocated size of the Index Entries (a)
01 1 if not leaf node (b)
00 00 00 Padding (always zero)
02 00 Update sequence
00000000000000000000000000000000000000000000
Index Record 1
2407000000000100 MFT Reference of the file
7000 Size of this index entry
5200 Offset to the filename
0100 Index Flags
0000 Padding (align to 8 bytes)
3F05000000000100 MFT File Reference of the parent
C7FCC1272939D301 File creation time
C7FCC1272939D301 Last modification time
23629B61EB55D301 Last modification time for FILE record
C7FCC1272939D301 Last access time
0000000000000000 Allocated size of file
0000000000000000 Real size of file
0000001000000000 File Flags
08 Length of filename (F)
02 Filename namespace
44004900410047004E004F007E003100000000000000
00 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 0 ⇒ LCN 984
Index Record 2
snip
01 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 1 ⇒ LCN 985
Index Record 3
snip
02 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 2 ⇒ LCN 986
Index Record 4
snip
03 00 00 00 00 00 00 00 VCN of index buffer with sub-nodes ⇒ VCN 3 ⇒ LCN 987
Index Entry
00 00 00 00 00 00 02 00 File reference
18 00 Length of the index entry
00 00 Length of the stream
03 Flags ⇒ ？？
00 00 00
04 00 00 00 00 00 00 00 ⇒ VCN 4 ⇒ LCN 988
まとめると、下記の繋がりとなります。
ROOT ⇒ VCN 5
VCN 5 ⇒ Index Records 1 ⇒ VCN 0
VCN 5 ⇒ Index Records 2 ⇒ VCN 1
VCN 5 ⇒ Index Records 3 ⇒ VCN 2
VCN 5 ⇒ Index Records 4 ⇒ VCN 3
VCN 5 ⇒ Index Entry ⇒ VCN 4
参考URL:
http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf
Folderと$BITMAP (0xB0)
フォルダの$BITMAP属性について確認します。
まず、「Windows」フォルダのMFTレコード番号（FILEレコード番号）を確認します。
$MFT内でオフセット1375232に移動し、$Bitmap属性を探します。
$INDEX_ROOT (0x90)があります。$I30という名前が設定されています。（Resident, Named）
続けて$INDEX_ALLOCATION (0xA0)があります。$I30という名前が設定されています。（Non-Resident, Named）
$BITMAP (0xB0)
$BITMAP (0xB0)がありました。(Resident, Named)
Standard Attribute Header
B0 00 00 00 Attribute Type ⇒ $BITMAP (0xB0)
28 00 00 00 Length (including this header) ⇒ 40
00 Non-resident flag
04 Name length
18 00 Offset to the Name
00 00 Flags
04 00 Attribute Id (a)
08 00 00 00 Length of the Attribute
20 00 Offset to the Attribute (b)
00 Indexed flag
00 Padding
24 00 49 00 33 00 30 00 The Attribute's Name ⇒ $I30
The Attribute (c)
3F 00 00 00 00 00 00 00
↓
0 0 1 1 1 1 1 1 ⇒ Bitmap ⇒ クラスタの利用状況
$INDEX_ALLOCATION (0xA0)
Bitmapを利用している $INDEX_ALLOCATION (0xA0) の DataRunを確認してみます。
DataRun 21 06 D8 03
↓
Size of the Offset field ⇒2
D8 03 ⇒ LCN 984
Size of the Length field ⇒1
Length ⇒ 6
Index Header の VCN of this INDX buffer in the Index Allocation を確認してみます。
LCN 984 ⇒ VCN 0
LCN 985 ⇒ VCN 1
LCN 986 ⇒ VCN 2
LCN 987 ⇒ VCN 3
LCN 988 ⇒ VCN 4
LCN 989 ⇒ VCN 5
参考URL:
http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf
Win10 と Thumbnail Index
Windows 10 1709 環境の Thumbnail Index ファイルを確認します。残念ながら、不完全なパース結果となっています。
サンプルファイル thumbcache_idx.db を参照します。ファイルフォーマットについては、「Windows Explorer Thumbnail Cache database format specification」を参考にします。
Index file File header
Note:ヘッダ部分の先頭4バイトから一致していません。割り当ててみましたが、間違っていると思います。
0C 00 30 20 ?
49 4D 4D 4D "IMMM" The signature (magic identifier)
20 00 00 00 Version
00 00 00 00 UnKnown
05 00 00 00 The number of entries used ? ⇒ 5
41 00 00 00 Number of entries ? ⇒ 65
65 00 00 00 UnKnown ? ⇒ 101
000010000000100000001000180000000000100000001000180000001800000018000000180000001800000018000000180000001800000001000000030000000E000000000000003100000008000000000000000000000000000000000000000000000000000000000000000000000000000000 ⇒ ???
Index entry
以前に確認したHNYのキャッシュ画像の Index entry を探します。
thumbcache_768.db ファイルにキャッシュされている画像の Entry hash 値は「69 E2 89 B3 06 B1 66 EB」となっています。
2.2. Cache entry
43 4D 4D 4D "CMMM" The signature (magic identifier)
06 E1 01 00 Cache entry size ⇒ 123,142
69 E2 89 B3 06 B1 66 EB Entry hash
20 00 00 00 00 00 00 00 File extension UTF-16 string with end-of-string character ⇒ filename_length? ⇒ 32
A7 E0 01 00 Identifier string size ⇒ Data Size？⇒ 123,047
DE 02 00 00 Padding size ⇒ width? ⇒ 734
80 02 00 00 Data size ⇒ height? ⇒ 640
00 00 00 00 Unknown (empty value)
E1 7A 3F 47 2B 6D EE 78 Data checksum Contains a CRC-64
64 55 95 7F FE 4F BD 1F ⇒ ？ Header Checksum
6500620036003600620031003000360062003300380039006500320036003900 ⇒ e.b.6.6.b.1.0.6.b.3.8.9.e.2.6.9. ⇒ Identifier string ？
この値は Thumbcache Viwer の Cache Entry Hash カラムでも確認できます。
Entry hash 値をファイル thumbcache_idx.db 内で検索すると、下記 Index entry がヒットします。
69 E2 89 B3 06 B1 66 EB Entry hash
80 E2 2D 00 00 00 00 00 ??
FF FF FF FF Cache entry offset in corresponding thumbcache_16
FF FF FF FF Cache entry offset in corresponding thumbcache_32
FF FF FF FF Cache entry offset in corresponding thumbcache_48
FF FF FF FF Cache entry offset in corresponding thumbcache_96
18 00 00 00 Cache entry offset in corresponding thumbcache_256 ⇒ 24
18 00 00 00 Cache entry offset in corresponding thumbcache_768 ⇒ 24
FF FF FF FF Cache entry offset in corresponding thumbcache_1280
FF FF FF FF Cache entry offset in corresponding thumbcache_1920
FF FF FF FF Cache entry offset in corresponding thumbcache_2560
FF FF FF FF sr？
FF FF FF FF wide？
FF FF FF FF exif？
FF FF FF FF wide_alternate？
FF FF FF FF custom_stream？
上記では、キャッシュ画像が無い場合は FF FF FF FF となっています。
参考URL：
IThumbnailCache interface (Windows)
WTS_FLAGS enumeration (Windows)
Windows 10とThumbnailCacheId
Windows 10 ver 1709 環境上における、ThumbnailCacheId とサムネイルキャッシュの関係を確認します。
キャッシュされているサムネイルデータをThumbcache Viewer を使い確認します。
thumbcache_768.db内には2件の画像がキャッシュされています。
C:\Users\forensics\AppData\Local\Microsoft\Windows\Explorer\thumbcache_768.db
eb66b106b389e269.jpg
9990cded46f057a1.jpg
キャッシュされている画像ファイルのメタデータは、Windows Searchのデータベースで確認できます。
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb
Windows.EDB
ESEDatabaseViewツールを利用し、Windows.edbファイルを開きます。
SystemIndex_PropertyStoreコンテナを参照します。
コンテナ内ではサムネイルキャッシュのファイル名部分を検索します。
例えば、9990cded46f057a1.jpg であれば検索するパターンは下記になります。
A1 57 F0 46 ED CD 90 99
4655-System_ThumbnailCacheId のカラムで一致するデータを確認できます。
ファイルパスなどを確認します。
上記では、9990cded46f057a1.jpg の元ファイル名などを確認できましたが、eb66b106b389e269.jpg については一致するレコードがコンテナ内に存在しません。
ファイル eb66b106b389e269.jpg は、C:\2018フォルダ配下にあり、このフォルダはインデックス対象となっていません。
C:\2018フォルダをインデックスの対象に追加します。
インデックスが完了しました。
一度OSを再起動した後、Windows.EDB ファイルの内容を確認します。
残念ながら、OSを再起動せずに最新のインデックス内容をWindows.edbへ反映する方法が分かりませんでした。
4655-System_ThumbnailCacheId のカラムでファイル eb66b106b389e269.jpg と一致する項目を確認できます。
キャッシュ画像の元ファイルがインデックスされている場合は、メタデータをWindows.edb から確認できます。
しかし、元ファイルがインデックスされていない場合は、どこで確認すればよいのでしょうか？
参考URL：
System.ThumbnailCacheId (Windows)
A unique value used as a key to cache thumbnails. The value changes when the name, volume, or data modified of an item changes.
Win10 と Thumbnail Cache
Windows 10 1709 環境の Thumbnail Cache ファイルをテストします。
サンプルの JPEG画像をPreview Paneで表示します。
ユーザーのプロファイルフォルダ配下に、thumbcacheファイルが作成されている事を確認します。
C:\Users\forensics\AppData\Local\Microsoft\Windows\Explorer
ファイルフォーマットについては「Windows Explorer Thumbnail Cache database format specification」と「read_thumbcache.h」を参考にしています。
thumbcache_768.dbをパースしてみます。
2.1. File header
43 4D 4D 4D "CMMM" ⇒ The signature (magic identifier)
20 00 00 00 Version ⇒ ？（Windows 10）
05 00 00 00 Cache type ⇒ thumbcache_768.db？
00 00 00 00 Offset to first cache entry (Or the file header size)
18 00 00 00 Offset to first available cache entry ⇒ 24
18 78 0A 00 Number of cache entries
2.2. Cache entry
43 4D 4D 4D "CMMM" The signature (magic identifier)
06 E1 01 00 Cache entry size ⇒ 123,142
69 E2 89 B3 06 B1 66 EB Entry hash
20 00 00 00 00 00 00 00 File extension UTF-16 string with end-of-string character ⇒ filename_length? ⇒ 32
A7 E0 01 00 Identifier string size ⇒ Data Size？⇒ 123,047
DE 02 00 00 Padding size ⇒ width? ⇒ 734
80 02 00 00 Data size ⇒ height? ⇒ 640
00 00 00 00 Unknown (empty value)
E1 7A 3F 47 2B 6D EE 78 Data checksum Contains a CRC-64
64 55 95 7F FE 4F BD 1F ⇒ ？ Header Checksum
6500620036003600620031003000360062003300380039006500320036003900 ⇒ e.b.6.6.b.1.0.6.b.3.8.9.e.2.6.9. ⇒ Identifier string ？
Thumbcache Viewer で可視化
Disk Cleanup
Disk Cleanupツールを利用すると、 Thumbnail Cache ファイルが削除されます。
Disk Cleanupツールを実行すると、キャッシュファイルは ThumbCacheToDelete フォルダに移動されています。
TMPファイル内には、キャッシュデータを確認できます。
OSを再起動すると、ThumbCacheToDelete フォルダは削除されるようです。
下記図は、OS 再起動後 Orphan フォルダ配下に thmF9A.tmp ファイルが残っていた状態です。
参考URL：
Forensic Analysis of Windows Thumbcache files
https://pdfs.semanticscholar.org/97a4/a135acf7ef534992e18f643f577a6749cb3e.pdf
