@port139 Blog

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

$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

 

f:id:hideakii:20180121090355j:plain

Folderと$BITMAP (0xB0)

フォルダの$BITMAP属性について確認します。

まず、「Windows」フォルダのMFTレコード番号（FILEレコード番号）を確認します。

f:id:hideakii:20180120092819p:plain

 $MFT内でオフセット1375232に移動し、$Bitmap属性を探します。

$INDEX_ROOT (0x90)があります。$I30という名前が設定されています。（Resident, Named）

f:id:hideakii:20180120093421p:plain

続けて$INDEX_ALLOCATION (0xA0)があります。$I30という名前が設定されています。（Non-Resident, Named）

f:id:hideakii:20180120093521p:plain

$BITMAP (0xB0)

$BITMAP (0xB0)がありました。(Resident, Named)

f:id:hideakii:20180120093730p:plain

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

f:id:hideakii:20180120104856p:plain

参考URL:

http://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf

 

f:id:hideakii:20180120105028j:plain

Win10 と Thumbnail Index

Windows 10 1709 環境の Thumbnail Index ファイルを確認します。残念ながら、不完全なパース結果となっています。

サンプルファイル thumbcache_idx.db を参照します。ファイルフォーマットについては、「Windows Explorer Thumbnail Cache database format specification」を参考にします。

Index file File header

f:id:hideakii:20180110184726p:plain

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 カラムでも確認できます。 

f:id:hideakii:20180113085746p:plain

Entry hash 値をファイル thumbcache_idx.db 内で検索すると、下記 Index entry がヒットします。

f:id:hideakii:20180113090036p:plain

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：

github.com

https://www.researchgate.net/publication/262327134_An_analysis_of_the_structure_and_behaviour_of_the_Windows_7_operating_system_thumbnail_cache

IThumbnailCache interface (Windows)

WTS_FLAGS enumeration (Windows)

 

f:id:hideakii:20180110183104j:plain

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

f:id:hideakii:20180106093719p:plain

9990cded46f057a1.jpg

f:id:hideakii:20180106093842p:plain

キャッシュされている画像ファイルのメタデータは、Windows Searchのデータベースで確認できます。

C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb

Windows.EDB

ESEDatabaseViewツールを利用し、Windows.edbファイルを開きます。
SystemIndex_PropertyStoreコンテナを参照します。

f:id:hideakii:20180106095931p:plain

 コンテナ内ではサムネイルキャッシュのファイル名部分を検索します。

例えば、9990cded46f057a1.jpg であれば検索するパターンは下記になります。

 A1 57 F0 46 ED CD 90 99

 4655-System_ThumbnailCacheId のカラムで一致するデータを確認できます。

f:id:hideakii:20180106101339p:plain

 ファイルパスなどを確認します。

f:id:hideakii:20180106101618p:plain

 上記では、9990cded46f057a1.jpg の元ファイル名などを確認できましたが、eb66b106b389e269.jpg については一致するレコードがコンテナ内に存在しません。

ファイル eb66b106b389e269.jpg は、C:\2018フォルダ配下にあり、このフォルダはインデックス対象となっていません。

C:\2018フォルダをインデックスの対象に追加します。 

f:id:hideakii:20180106102335p:plain

インデックスが完了しました。

f:id:hideakii:20180106102633p:plain

一度OSを再起動した後、Windows.EDB ファイルの内容を確認します。
残念ながら、OSを再起動せずに最新のインデックス内容をWindows.edbへ反映する方法が分かりませんでした。

 4655-System_ThumbnailCacheId のカラムでファイル eb66b106b389e269.jpg と一致する項目を確認できます。

f:id:hideakii:20180106103646p:plain

 

キャッシュ画像の元ファイルがインデックスされている場合は、メタデータを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.

 

www.swiftforensics.com

f:id:hideakii:20180106104047j:plain

Win10 と Thumbnail Cache

Windows 10 1709 環境の Thumbnail Cache ファイルをテストします。
サンプルの JPEG画像をPreview Paneで表示します。

f:id:hideakii:20180101105702p:plain

ユーザーのプロファイルフォルダ配下に、thumbcacheファイルが作成されている事を確認します。

C:\Users\forensics\AppData\Local\Microsoft\Windows\Explorer

f:id:hideakii:20180101105912p:plain

ファイルフォーマットについては「Windows Explorer Thumbnail Cache database format specification」と「read_thumbcache.h」を参考にしています。

thumbcache_768.dbをパースしてみます。

f:id:hideakii:20180101110610p:plain

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 で可視化

f:id:hideakii:20180101113720p:plain

 Disk Cleanup

 Disk Cleanupツールを利用すると、 Thumbnail Cache ファイルが削除されます。

f:id:hideakii:20180101142327p:plain

 Disk Cleanupツールを実行すると、キャッシュファイルは ThumbCacheToDelete フォルダに移動されています。

f:id:hideakii:20180101142641p:plain

TMPファイル内には、キャッシュデータを確認できます。

f:id:hideakii:20180101142756p:plain

OSを再起動すると、ThumbCacheToDelete フォルダは削除されるようです。

下記図は、OS 再起動後 Orphan フォルダ配下に thmF9A.tmp ファイルが残っていた状態です。

f:id:hideakii:20180101143518p:plain

 

参考URL：

 

github.com

 

Thumbcache Viewer - Extract thumbnail images from the thumbcache_*.db and iconcache_*.db database files.

 

neosmart.net

Forensic Analysis of Windows Thumbcache files
https://pdfs.semanticscholar.org/97a4/a135acf7ef534992e18f643f577a6749cb3e.pdf

 

f:id:hideakii:20180101171003j:plain

EventLogとEVTX

eventlogedit が利用されると、イベントログ内で個別のレコードが削除されます。

下記Blogでは、eventlogeditがレコードを削除する仕組み、検出ツールとサンプルのEVTXファイルが紹介されています。

blog.fox-it.com

 サンプルEVTXファイルの内容を確認したいと思います。EVTXのファイル形式については、Windows XML Event Log (EVTX) format の資料を参考にしています。

 サンプルファイル post-Security.evtx をイベントビューアで開きます。イベントビューアでは「4616(S): The system time was changed.」のレコードを確認できません。

f:id:hideakii:20171223153142p:plain

 File header

f:id:hideakii:20171223141431p:plain

45 6C 66 46 69 6C 65 00 "ElfFile\x00" Signature
00 00 00 00 00 00 00 00 First chunk number
01 00 00 00 00 00 00 00 Last chunk number ⇒ 1
7F 00 00 00 00 00 00 00 Next record identifier ⇒ 127
80 00 00 00 Header size ⇒ 128
01 00 Minor version
03 00 Major version
00 10 Header block size(or chunk data offset) ⇒ 4096
02 00 Number of chunks ⇒ 2
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Unknown (Empty values)
00 00 97 1B File flags
1A 82 44 3F Checksum

 Chunk header（Chunk 1）Size 512

f:id:hideakii:20171223142406p:plain

45 6C 66 43 68 6E 6B 00 "ElfChnk\x00" Signature
01 00 00 00 00 00 00 00 First event record number ⇒ 1
66 00 00 00 00 00 00 00 Last event record number ⇒ 102
01 00 00 00 00 00 00 00 First event record identifier ⇒ 1
66 00 00 00 00 00 00 00 Last event record identifier ⇒ 102
80 00 00 00 Header size (or offset to pointer data) ⇒ 128
A0 FA 00 00 Last event record data offset ⇒ 64,160
80 FD 00 00 Free space offset ⇒ 64,896
10 78 56 8C Event records checksum
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Unknown (Empty values)
01 00 00 00 Unknown (flags?)
84 B9 53 5B Checksum

 Chunk header（Chunk 2）Size 512

4096+65536 = 69,632

f:id:hideakii:20171223143732p:plain

45 6C 66 43 68 6E 6B 00 "ElfChnk\x00"  Signature
67 00 00 00 00 00 00 00 First event record number ⇒ 103
7E 00 00 00 00 00 00 00 Last event record number ⇒ 126
67 00 00 00 00 00 00 00 First event record identifier ⇒ 103
7E 00 00 00 00 00 00 00 Last event record identifier ⇒ 126
80 00 00 00 Header size (or offset to pointer data) ⇒ 128
28 5D 00 00 Last event record data offset ⇒ 23,848
F8 61 00 00 Free space offset ⇒ 250.080
A1 A8 17 5D Event records checksum
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Unknown (Empty values)
01 00 00 00 Unknown (flags?)
5F 2D 86 33 Checksum

 Event record ID 104

f:id:hideakii:20171223150709p:plain

2A 2A 00 00  "\x2a\x2a\x00\x00" Signature
68 06 00 00 Size ⇒ 1,640
68 00 00 00 00 00 00 00 Event record identifier ⇒ 104
55 CB 22 91 22 74 D3 01 Written date and time ⇒ FILETIME (UTC): 12/13/2017 2:56:33 PM、FILETIME (local): 12/13/2017 11:56:33 PM

 

上記Size値から、レコード104は73,608～75,248の範囲だと分かります。
しかし、オフセット 74,288 には Event record ID 105 のシグネチャがあります。
この部分が削除されているレコードとなります。

f:id:hideakii:20171223152702p:plain

2A 2A 00 00  "\x2a\x2a\x00\x00" Signature
C0 03 00 00 Size ⇒ 960
69 00 00 00 00 00 00 00 Event record identifier ⇒  105
00 26 28 96 22 74 D3 01 ⇒ FILETIME (UTC): 12/13/2017 2:56:42 PM、FILETIME (local): 12/13/2017 11:56:42 PM

 

オフセット 75,248 には再び、 Event record ID 105 のシグネチャが登場します。 

f:id:hideakii:20171223153545p:plain

2A 2A 00 00 "\x2a\x2a\x00\x00" Signature
38 04 00 00 Size ⇒ 1080
69 00 00 00 00 00 00 00 Event record identifier ⇒  105
37 B8 ED 96 22 74 D3 01 ⇒ FILETIME (UTC): 12/13/2017 2:56:43 PM、FILETIME (local): 12/13/2017 11:56:43 PM

 

イベントビューアでは、12/13/2017 11:56:42 PM のレコードが無い事を確認できます。

参考URL：

blog.fox-it.com

 

github.com

github.com

Windows 10 and Windows Server 2016 security auditing and monitoring reference
https://www.microsoft.com/en-us/download/details.aspx?id=52630

[MS-EVEN6]: BinXml Example Using Templates

 

f:id:hideakii:20171223154827j:plain

RegistryとTransaction log files

Windows 10 環境で取得した ntuser.dat.LOG1 ファイルのデータ内容を確認します。

ファイルフォーマットについては「Windows registry file format specification」のNew format を参照しています。

 ファイルの先頭 512バイトは、Base block となっており、NTUSER.DAT ファイルの一部バックアップとなっています。（部分的には異なる）

f:id:hideakii:20171210091124p:plain

Log entries

オフセット512からLog entrieが開始されます。

f:id:hideakii:20171210092120p:plain

48 76 4C 45 Signature ⇒ HvLE
00 8E 01 00 Size ⇒ 101,888
00 00 00 00 Flags 
9B 01 00 00 Sequence number
00 50 0E 00 Hive bins data size ⇒ 937,984
0D 00 00 00 Dirty pages count ⇒ 13
4E 8D E6 65 CA 45 AE 85 Hash-1 
E7 5 DD 9B AE 69 9 EC 79 Hash-2 

 Dirty pages references

オフセット40から Dirty pages references が Dirty pages count 分(＝13)続きます。

f:id:hideakii:20171210092829p:plain

00000000 Offset ⇒ 0
00100000 Size ⇒ 4096
00000300 Offset ⇒ 196,608
00100000 Size ⇒ 4096 
00600300 Offset ⇒ 221,184
00100000 Size ⇒ 4096
00300600 Offset ⇒ 405,504
00200000 Size ⇒ 8192
00C00600 Offset ⇒ 442,368
00100000 Size ⇒ 4096
00B00700 Offset ⇒ 503,808
00100000 Size ⇒ 4096
00E00700 Offset ⇒ 516,096
00100000 Size ⇒ 4096
00200800 Offset ⇒ 532,480
00100000 Size ⇒ 4096
00600B00 Offset ⇒ 745,472
00100000 Size ⇒ 4096
00000C00 Offset ⇒ 786,432
00100000 Size ⇒ 4096
00A00C00 Offset ⇒ 827,392
00800000 Size ⇒ 32768
00A00D00 Offset ⇒ 892,928
00100000 Size ⇒ 4096
00D00D00 Offset ⇒ 905,216
00400000 Size ⇒ 16,384

Dirty page

例えば、「RegistryとFile format(3)」で参照した UserInitMprLogonScript 値は NTUSER.DAT ファイル内の、Hive Bins Data のオフセット 443,304 にあります。

上記 Dirty pages reference の Offset 値から、オフセット  442,368 のDirty Page内にデータが含まれている事を確認できます。

NTUSER.DAT.LOG1 ファイル内では、Base block 512 + Log entrie 40 + Dirty pages references 104 + 4096 + 4096 + 4096 + 8192 = 21,136 からの 4096 バイトになります。

f:id:hideakii:20171210100005p:plain

30 00 00 00 Size ⇒ 48
76 6B Signature ⇒ vk
16 00 Name length ⇒ 22
3C 00 00 00 Data size ⇒ 60
28 33 0E 00 Data offset  ⇒ 930,600
01 00 00 00 Data type ⇒ REG_SZ
01 00 Flags 
04 00  Spare
55736572496E69744D70724C6F676F6E5363726970746D00 ⇒ UserInitMprLogonScriptm

削除データの復元

yarp: yet another registry parser を利用すると、削除データの復元が可能です。

このツールはトランザクションログにも対応しており、オプション指定により含める・含めないを選択できます。 

f:id:hideakii:20171216100611p:plain

--deleteオプションを利用した出力結果で、削除された値を確認できました。

---

Key path: Environment
Last written timestamp (UTC): 2017-12-09 05:58:21.726800
Access bits: 2

Value name: Path
Value type: REG_EXPAND_SZ
Data size: 102
Data (decoded):
%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;

Value name: TEMP
Value type: REG_EXPAND_SZ
Data size: 66
Data (decoded):
%USERPROFILE%\AppData\Local\Temp

Value name: TMP
Value type: REG_EXPAND_SZ
Data size: 66
Data (decoded):
%USERPROFILE%\AppData\Local\Temp

Value name: OneDrive
Value type: REG_SZ
Data size: 56
Data (decoded):
C:\Users\forensics\OneDrive

Associated deleted values below (may contain reallocated data):

Value name: UserInitMprLogonScript
Value type: REG_SZ
Data size: 60
Data (decoded):
c:\users\forensics\mrset.bat

---

 snip

---

Deleted values (all, may contain reallocated data):

Value name: UserInitMprLogonScript
Value type: REG_SZ
Data size: 60
Data (decoded):
c:\users\forensics\mrset.bat

 素晴らしい！

 

参考URL:

github.com

github.com

www.slideshare.net

f:id:hideakii:20171216101947j:plain

RegistryとFile format(3)

レジストリから値を削除し、変化を確認します。
サンプルとして、HKEY_CURRENT_USER\Environment 配下にUserInitMprLogonScript値を作成します。
この値はAPT28で自動起動の手口としても利用されています。

f:id:hideakii:20171209114741p:plain

この値のオフセット位置を確認します。

Registry Explorer の Technical Details で Relative offset を確認します。
オフセット位置は 4096+968=5064 になります。

f:id:hideakii:20171209142903p:plain

 次に、Value list cell index のオフセットを確認します。
オフセット位置は 4096+443352=447448 となります。 Value countは5ですから、5個の値があります。

f:id:hideakii:20171209143216p:plain

NTUSER.DAT のオフセット 447448 を参照します。 

f:id:hideakii:20171209143539p:plain

E0 FF FF FF -32

C8 18 01 00 ⇒ 71880 ⇒ Path
58 19 01 00 ⇒ 72024 ⇒ TEMP
D0 19 01 00 ⇒ 72144 ⇒ TMP
B8 4D 07 00 ⇒ 478648 ⇒ OneDrive
A8 C3 06 00 ⇒ 443304 ⇒ UserInitMprLogonScript ⇒ 4096+443304=447400
A8 C3 06 00 ⇒ 443304
00 00 41 00 ⇒ 4259840 

Registry Explorer では下記から確認できます。Data のオフセット位置は 4096+930600 =934696 です。

f:id:hideakii:20171209144621p:plain

オフセット位置934696で値を確認します。

f:id:hideakii:20171209145341p:plain

 値を削除

レジストリ Environment キーからUserInitMprLogonScript値を削除します。

f:id:hideakii:20171209145806p:plain

Registry ExplorerからNTUSER.DATを参照し、UserInitMprLogonScript値が無い事を確認します。

f:id:hideakii:20171209150413p:plain

値を削除した後のNTUSER.DAT で、オフセット 447448 を参照します。Value list cell index の内容を確認します。 Value countは4となっています。

f:id:hideakii:20171209151400p:plain

E0 FF FF FF
C8 18 01 00
58 19 01 00
D0 19 01 00
B8 4D 07 00
A8 C3 06 00 ⇒ 443304 ⇒ UserInitMprLogonScript ⇒ 4096+443304=447400
A8C30600
00004100

NTUSER.DAT のオフセット 447400 を確認します。

f:id:hideakii:20171209151618p:plain

NTUSER.DAT のオフセット位置 4096+930600 =934696 で Data 内容を確認します。

f:id:hideakii:20171209152025p:plain

  削除された値を確認できました。

  次はLOGファイルを確認してみたいと思います。

参考URL：

 

port139.hatenablog.com

github.com

 

f:id:hideakii:20171209153323j:plain

RegistryとFile format(2)

前回の続きです。
ROOTキー(nk)のサブキーを確認します。
ROOTキー配下に、サブキーは 9個あります。

f:id:hideakii:20171202083359p:plain

ROOTキーのCELL内容から、サブキーのリストはオフセット位置 72,288（4096 + 68,192）である事を確認できます。

09 00 00 00 Number of subkeys ⇒ 9
01 00 00 00 Number if volatile subkeys ⇒ 1
60 0A 01 00 Subkey list offset ⇒ 68,192

NTUSER.DAT のオフセット 72,288 を参照します。

f:id:hideakii:20171202083827p:plain

Hash leaf (lh)

A0 FF FF FF Cell Size ⇒ -96
6C 68 Signature ⇒ lh ⇒ Hash leaf (lh)
09 00 Number of elements ⇒ 9
78 00 00 00 Key node offset ⇒ 120
86 BC AC 05 Name hash
E8 00 00 00 Key node offset ⇒ 232
23 8E C0 55 Name hash
70 02 00 00 Key node offset ⇒ 624
B9 D7 9C BD Name hash
C8 03 00 00 Key node offset ⇒ 968
C9 CE 48 6F Name hash
28 04 00 00 Key node offset ⇒ 1,064
35 25 37 00 Name hash
20 10 01 00 Key node offset ⇒ 69,664
87 6E 02 E5 Name hash
70 03 00 00 Key node offset ⇒ 880
4B BE 5B 71 Name hash
80 04 00 00 Key node offset ⇒ 1,152
63 14 FE E9 Name hash
68 05 00 00 Key node offset ⇒ 1,384
F9 D0 41 61 Name hash
68050000F9D04161382D303332462D31

Control Panel key

サブキーを更に辿ってみます。

「Key node offset ⇒ 624」のサブキーを確認する為、オフセット 4,720（4096 + 624） を参照します。

f:id:hideakii:20171202085538p:plain

A0 FF FF FF Cell Size ⇒ -96
6E 6B Signature ⇒ nk
20 00 Flag
EF 1B CF D2 B9 55 D3 01 ⇒ Last written timestamp ⇒ 11/4/2017 10:11:11 PM
02 00 00 00 Access bits
20 00 00 00 Parent 
0F 00 00 00 Number of subkeys ⇒  15
00 00 00 00 Number of volatile subkeys
60 1F 01 00 Subkeys list offset ⇒ 73,568
FF FF FF FF Volatile subkeys list offset
01 00 00 00 Number of key values ⇒ 1
50 81 07 00 Key values list offset ⇒ 491,856
C8 22 00 00 Key security offset  ⇒ 8,904
FF FF FF FF Class name offset
1E 00 00 00 Largest subkey name length
00 00 00 00 Largest subkey class name length
38 00 00 00 Largest value name length
08 00 00 00 Largest value data size
00 00 00 00 WorkVar
0D 00 Key name length ⇒ 13
00 00 Class name length
436F6E74726F6C2050616E656C ⇒ Control Panel
000000

Key values list

値リストを確認する為、オフセット 495,952（ 4096 + 491,856 ）を参照します。

f:id:hideakii:20171202091546p:plain

F8 FF FF FF Size ⇒ -8
B8 85 02 00 Key value offset ⇒ 165,304

Key value

f:id:hideakii:20171202092618p:plain

値を確認する為、オフセット 169,400 （4096 + 165,304）を参照します。

f:id:hideakii:20171202092010p:plain

C8 FF FF FF Size ⇒ -56
76 6B Signature
1C 00 Name length ⇒ 28
08 00 00 00 Data size ⇒ 8
F0 85 02 00 Data offset ⇒ 165,360
03 00 00 00 Data Type ⇒ REG_BINARY
01 00 Flags
0D 00 Spare
53657474696E6773457874656E73696F6E417070536E617073686F74 ⇒ SettingsExtensionAppSnapshot
656C0100

Value data

データ内容を確認する為、オフセット 139,456 （4096 + 165,360）を参照します。 

f:id:hideakii:20171202093233p:plain

F0 FF FF FF Size ⇒ -16
00 00 00 00 00 00 00 00 Data
09 04 09 04 Slack

 

 参考URL：

github.com

 

f:id:hideakii:20171202094019j:plain

RegistryとFile format(1)

レジストリのバイナリ構造について確認します。レジストリファイルの構造については、「Windows registry file format specification」の資料を参考にします。

サンプルのレジストリファイルは Windows 10 のNTUSER.DAT を利用します。

f:id:hideakii:20171126081916p:plain

Base Block

72 65 67 66 Signature regf
0C 01 00 00 Primary sequence number
0C 01 00 00 Secondary sequence number
00 00 00 00 00 00 00 00 Last written timestamp
01 00 00 00 Major version
05 00 00 00 Minor version
00 00 00 00 File type ⇒ 0 means primary file
01 00 00 00 File format ⇒ 1 means direct memory load
20 00 00 00 Root cell offset ⇒ 32
00 50 0E 00 Hive bins data size ⇒ 937,984
01 00 00 00 Clustering factor 
3F 00 5C 00 43 00 3A 00 5C 00 55 00 73 00 65 00 72 00 73 00 5C 00 66 00 6F 00 72 00 65 00 6E 00 73 00 69 00 63 00 73 00 5C 00 6E 00 74 00 75 00 73 00 65 00 72 00 2E 00 64 00 61 00 74 00 00 00 File Name
Offset 112
74 A1 A6 47 14 A5 E7 11 A9 4E EC 0D 9A 05 C8 60 RmId
74 A1 A6 47 14 A5 E7 11 A9 4E EC 0D 9A 05 C8 60 LogId
00 00 00 00 Flags
75 A1 A6 47 14 A5 E7 11 A9 4E EC 0D 9A 05 C8 60 TmId
72 6D 74 6D GUID signature ⇒ rmtm
22 CD DD 2A 10 64 D3 01 Last reorganized timestamp ⇒  11/23/2017 4:04:32 AM
4F665267010000000000000000000000 ⇒ ???

Hive bin

f:id:hideakii:20171126084958p:plain

68 62 69 6E Signature hbin
00 00 00 00 Offset
00 10 00 00 Size ⇒ 4096
00 00 00 00 00 00 00 00 ⇒ Reserved
00 00 00 00 00 00 00 00 ⇒ Timestamp
00 00 00 00 Spare (or MemAlloc)

Cell

A8 FF FF FF Size ⇒ -88 (negative if a cell is allocated）
6E 6B nk ⇒ Key node (nk) ⇒ Registry key node
2C 00 Flags
01 21 E3 2A 10 64 D3 01 Last written timestamp（UTC) ⇒ 11/23/2017 4:04:32 AM
02 00 00 00 Access bits
98 07 00 00 Parent
09 00 00 00 Number of subkeys ⇒ 9
01 00 00 00 Number if volatile subkeys ⇒ 1
60 0A 01 00 Subkey list offset ⇒ 68,192 
68 02 00 80 Volatile subkey list offset
00 00 00 00 Number of key values
FF FF FF FF Key values list offset
50 65 00 00 Key security offset
FF FF FF FF Class name offset
2A 00 00 00 Largest subkey name length
00 00 00 00 Largest subkey class name length
00 00 00 00 Largest value name length
00 00 00 00 Largest value data size
00 00 00 00 WorkVar
04 00 Key name length
00 00 Class name length
52 4F 4F 54 00 00 00 00 ⇒ ROOT

 Registry ExplorerでROOTキーのTechnical detailesを参照すれば、簡単に確認できます。

f:id:hideakii:20171126092559p:plain

 

参考URL:

www.slideshare.net

github.com

github.com

https://posts.specterops.io/hiding-registry-keys-with-psreflect-b18ec5ac8353

f:id:hideakii:20171126092356j:plain