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

binaryforay.blogspot.jp

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：

binaryforay.blogspot.jp

http://cyberforensicator.com/wp-content/uploads/2017/01/1-s2.0-S1742287616300202-main.2-14.pdf

www.nirsoft.net

https://tzworks.net/prototypes/jmp/jmp.users.guide.pdf

JumpList と Stream

「JumpList と The allocation table」の続きです。

次のDirectory entry(128byte)をパースしてみます。 

31000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ⇒ 1

04 00 ⇒ The byte size of the directory name including the end-of-string character

02 ⇒ The type of the directory entry ⇒ stream

01 ⇒ The node color of the directory entry.⇒ Black

FF FF FF FF ⇒ 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 (FILETIME)

00 00 00 00 00 00 00 00 ⇒ Modification time(FILETIME)

00 00 00 00 ⇒ Refers to the SID of a stream or the SID of short-stream container stream

BD 01 00 00 ⇒ Refers to the size of a stream or the size of a short-stream container stream ⇒ 445

00 00 00 00 ⇒ Reserved

上記結果から、このエントリは445バイトのストリームとなっています。

Root Entry の Sector identifier (SID) of the first sector of the directory は 3 です、セクタ 3 を確認します。LNK ファイルのシグネチャが登場します。

ヘッダによれば、Size of a short-sector (mini-sector)は64バイトとなっています。

SSATを確認します。チェーンは0⇒1⇒2⇒3⇒4⇒5⇒Dと構成されています。

 まず、0⇒1⇒2⇒3⇒4⇒5の 384 バイトを確認します。

 セクタDで残りの64バイトを確認します。（ストリームのサイズは445バイト）

Structured Storage Viewer でデータを確認してみます。 同じデータですね。

このJumpListファイル内には、LNKデータがストリームのエントリとして保存されている事を確認できました。

次へ続きます。

 

参考URL： 

github.com

binaryforay.blogspot.jp

JumpList と The allocation table

JumpListのファイル構造続き。SAT(Sector Allocation Table)を確認します。

「Object Linking and Embedding (OLE) Compound File (CF) format specification」を参照しています。

 Master Sector Allocation Table (MSAT)はオフセット76から開始されており、オフセット76からの4バイトは00 00 00 00である事から、セクタ位置は0となっています。

 セクタ位置0を確認します。Sector identifier は 0xfffffffd (-3)です。

0xfffffffd (-3) ⇒ Marks the sector as used for the SAT(Sector Allocation Table)

次にセクタ1を確認します。チェーンの値は06です。

 セクタ 1 を確認します。

directory entryがあります、directory entryは128バイトです。 

最初のdirectory entryをパースしてみます。

52 00 6F 00 6F 00 74 00 20 00 45 00 6E 00 74 00 72 00 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ⇒ The directory name in UTF-16 ⇒ R.o.o.t. .E.n.t.r.y.

16 00 ⇒ The byte size of the directory name including the end-of-string character ⇒ 22

05 ⇒ The type of the directory entry ⇒ root storage

00 ⇒ The node color of the directory entry. ⇒ red

FF FF FF FF ⇒ -1 ⇒ The value is -1 if no previous directory entry is present

FF FF FF FF ⇒ -1 ⇒ The value is -1 if no next directory entry is present

04 00 00 00 ⇒ 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 flag

00 00 00 00 00 00 00 00 ⇒ Creation time

E0 ED 7A A6 F7 D9 D3 01 ⇒ Modification time(FILETIME) ⇒ 4/22/2018 5:06:19 AM

03 00 00 00 ⇒ Sector identifier (SID) of the first sector of the directory

40 20 00 00 ⇒ The byte size of the directory ⇒ 8256

00 00 00 00 ⇒ Reserved

続きます。

参考URL：

github.com

binaryforay.blogspot.jp

articles.forensicfocus.com

JumpList と OLECF file header

 これも古い話題ですが :-)、JumpListのファイル形式について確認します。
JumpListファイルの詳細については、参考URLの記事を参照してください。

下記図は、Windows 10環境でAutomaticDestinationsフォルダ配下にあるf01b4d95cf55d32a.automaticDestinations-msファイルを参照しています。

AppID が「f01b4d95cf55d32a」ですので、Explorer の JumpList ファイルとなります。

ファイルヘッダのシグネチャは D0 CF 11 E0 A1 B1 1A E1 となっており、OLECFである事が分かります。OLECF形式については、マイクロソフトが仕様を公開しています。

Object Linking and Embedding (OLE) Compound File (CF) format specification を参照し、ファイルヘッダ部分をパースします。

D0 CF 11 E0 A1 B1 1A E1 The signature (magic identifier)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Class identifier (GUID)
3E 00 Revision number of the file format (minor version) ⇒ 62
03 00 Version number of the file format (major version)
FE FF Byte order identifier ⇒ \xfe\xff little endian
09 00 Size of a sector in the compound document file in power-of-two ⇒ 512byte
06 00 Size of a short-sector (mini-sector) in the short-stream container stream in power-of-two ⇒ 64byte
00 00 00 00 00 00 Reserved
00 00 00 00  Number of Directory Sectors.
01 00 00 00 Number of FAT Sectors
01 00 00 00 First Directory Sector Location
00 00 00 00 Transaction Signature Number
00 10 00 00 Mini Stream Cutoff Size ⇒ 4096
02 00 00 00 First Mini FAT Sector Location ⇒ 2
02 00 00 00 Number of Mini FAT Sectors ⇒ 2
FE FF FF FF First DIFAT Sector Location
00 00 00 00 Number of DIFAT Sectors
DIFAT (436byte)

 Master Sector Allocation Table (MSAT)はオフセット76から開始されます。下記では、オフセット76からの4バイトは00 00 00 00となっており、セクタ位置は0となっています。 

最初のセクタ位置を確認します。

Sector identifier は 0xfffffffd (-3)となっており、Marks the sector as used for the SAT(Sector Allocation Table)である事が分かります。

更に詳細に追跡する方法は、「Jump lists in depth: Understand the format to better understand what your tools are (or aren't) doing」で詳しく解説されています。

来週、続きを確認する予定です。

参考URL:

windowsir.blogspot.jp

windowsir.blogspot.jp

binaryforay.blogspot.jp

blog.didierstevens.com

www.blackbagtech.com

github.com

www.nirsoft.net

https://msdn.microsoft.com/en-us/library/dd942138.aspx

github.com

www.4n6k.com

Registry MinerとTime stamp

Registry Miner を利用し、レジストリファイルからタイムスタンプを採掘します。

サンプルのSYSTEMハイブに対して、Registry Miner を実行します。”starting timestamp”で指定した日時以降の、タイムスタンプを含むキーや値が採掘されます。

# ./registry-miner.py 20180101 ./reg/SYSTEM Timestamp.csv

出力結果のCSVファイルを参照し、例としてBAMキーの行を確認します。 

./reg/SYSTEM,ControlSet001\Services\bam\UserSettings\S-1-5-21-3895603692-3337950920-141663326-1001,
value:
\Device\HarddiskVolume2\Program Files\AccessData\FTK Imager\FTK Imager.exe,
2018-04-07 10:21:05.758096,
FILETIME,
value_data_bin,2,"b'\x9e\xeb>#Z\xce\xd3\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00' (ts_pos=0, ts_len=8, ctx_start=0)"

Note:
ExcelでCSVファイルを参照すると、タイムスタンプは丸めて表示されます。

 同じ値をRegistry Explorerでも確認してみます。

 AppCompatCache値のように、複数のタイムスタンプが含まれる場合は1行だけ出力されます。

./reg/SYSTEM,ControlSet001\Control\Session Manager\AppCompatCache,
value: AppCompatCache,
2018-04-07 12:05:40.789000,
FILETIME,
value_data_bin,2,"b's\x00S\x00r\x00v\x00.\x00e\x00x\x00e\x00P\xa6t\xbfh\xce\xd3\x01\x18\x00\x00\x00\x00\x02\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00' (ts_pos=226, ts_len=8, ctx_start=210)"

Registry MinerはGUIDTIME 形式のタイムスタンプも採掘してくれます。
サンプルのSYSTEMハイブ内では、USBに関連した値で出力がありました。

./reg/SYSTEM,ControlSet001\Enum\USBSTOR\Disk&Ven_BUFFALO&Prod_USB_Flash_Disk&Rev_4000\A260000000885020&0\Device Parameters\Partmgr,
value:
DiskId,
2018-03-23 22:43:02.491098,
GUIDTIME,
value_data_str,2,

UNIXTIME形式の採掘結果を確認します。

 ./reg/SYSTEM,ControlSet001\Services\Dnscache\Parameters\Probe\{70b977cd-a94c-4efa-b672-c495177be3ed},
value: LastProbeTime,
2018-04-14 16:36:19,
UNIXTIME,
value_data_int,2,

サンプルのNTUSER.DATファイルを利用して、残りのタイムスタンプ形式を確認します。

ISOTIME形式の採掘結果を確認します。 

./reg2/NTUSER.DAT,Software\Microsoft\Windows\CurrentVersion\WindowsUpdate,
value:
LastAutoAppUpdateSearchSuccessTime,
2018-04-14 07:42:32,
ISOTIME,
value_data_str,2,

SYSTEMTIME形式の採掘結果を確認します。 

./reg2/NTUSER.DAT,Software\Microsoft\MicrosoftEdge\BrowserEmulation,
value:
CVListPingLastYMD,
2018-04-07 09:21:38,
SYSTEMTIME,
value_data_bin,2,"b'\xe2\x07\x04\x00\x06\x00\x07\x00\t\x00\x15\x00&\x00\x01\x01' (ts_pos=0, ts_len=16, ctx_start=0)"

E207 ⇒Year 2018
0400 ⇒ Month 04
0600 ⇒ DayOfWeek
0700 ⇒ Day 7
0900 ⇒ Hour 9
1500 ⇒ Minute 21
2600 ⇒ Second 38
0101 ⇒ Milliseconds 257

 Registry Minerを利用すれば、新たなタイムスタンプの発掘が可能になりそうですね。

Registry Miner に感謝！

By the way, I love Minecraft!

参考URL:

github.com

Registry Miner: https://t.co/kIWoJlt0lb

The program scans a given registry file (primary) and extracts everything that looks like a timestamp. #DFIR pic.twitter.com/13Euz0HZvZ

— Maxim Suhanov (@errno_fail) 2018年4月11日

SYSTEMTIME Structure1

LNK と Time stamp (FAT date and time)

LNKファイル内のShell Itemに含まれる、タイムスタンプ形式を確認します。

LEcmdを利用し、LNKファイルに含まれるタイムスタンプを確認します。フォルダCaseと、P1060117.jpgのタイムスタンプ情報を確認できます。

「LNKとShell item」を参考に、Caseフォルダに関するタイムスタンプを確認します。

874C7732 Last modification date and time
644B2CB4 Creation date and time
874C7732 Last access date and time

タイムスタンプ情報は「Contains a FAT date and time in UTC」形式となっています。TimeLoadを利用し変換します。

874C7732 ⇒ 2018-04-07 06:19:46 Last modification date and time(UTC)

644B2CB4 ⇒ 2017-11-04 22:33:24 Creation date and time (UTC)
874C7732 ⇒ 2018-04-07 06:19:46 Last access date and time (UTC)

NTFSボリューム上にある、Caseフォルダのタイムスタンプを確認します。

NTFS上ではCaseフォルダのData Modified が 06:19:45 となっていますが、LNK内Shell Itemのタイムスタンプは 06:19:46 となっています。

これは、下記URLで説明されている、タイムスタンプ分解能の違いによる影響ですかね。

https://support.microsoft.com/help/402160

PlasoでこのLNKファイルのタイムラインを作成すると、下記の出力結果を得られます。MFTのタイムラインと一緒に確認する場合、タイムスタンプ分解能により、差異が出ますね。

<補足>

Property Storeではタイムスタンプの保存形式が異なります。

例として、P1060117.jpg.LNK のProperty Storeを確認してみます。

b725f130-47ef-101a-a5f1-02608c9eebac\14 Date Modified の値は、04/07/2018 06:19:45 になっています。

HEXデータを確認してみます。下記では、8バイト長のタイムスタンプ(FILETIME)が記録されています。

 タイムスタンプを変換します。2018-04-07 06:19:45.6168864

 参考URL：

computerforensics.parsonage.co.uk

http://www.kazamiya.net/en/fte/type

https://t.co/28oBjUJb5C, https://t.co/7BiZAGMLt6 #DFIR

— H. Carvey (@keydet89) 2018年4月8日

windowsir.blogspot.jp

LNK と Property Store

LNKファイルのProperty Store構造を確認します。

サンプルJPEGファイルを準備します。このJPEGファイルはEXIF情報を含んでいます。

 サンプルJPEGファイルのショートカットを作成します。

作成したショートカットファイルを LEcmd でパースし、Property store data blockを確認します。Property Store dataがLNKファイル内に存在している事を確認できます。

LNKファイル内の「The metadata property store data block」を確認してみます。

 シグネチャ0xa0000009をハイライトしています。

最初のserialized property storageは、245バイトあります。

Windows Property Store formatを参考し、パースしてみます。一部不完全な結果になっています。

F5 00 00 00 Size of the serialized property storage ⇒ 245
31 53 50 53 "1SPS" ⇒ Version
A1 1D B8 14 35 01 31 4D 96 D9 6C BF C9 67 1A 99 ⇒Format class (or property set) identifier GUID ⇒ 14b81da1-0135-4d31-96d9-6cbfc9671a99 
25 00 00 00 ⇒ 37 （長さ）
0F 01 00 00 ⇒ 271 ⇒ Manufacturer of camera
00 Reserved
1F 00 00 00 ⇒ 31 （Property value type？)

0A 00 00 00 ⇒ 10 (文字列長？）
500061006E00610073006F006E00690063000000 ⇒ Panasonic

15 00 00 00 ⇒  21 （長さ）
9A 82 00 00⇒ 33434 ⇒ Exposure Time ？
00 Reserved

<4/2追記> 

サンプルのLNKファイルを、plaso-20180127でパースした結果が下記です。Shell Itemはパースされていますが、Property Soreはパースされません。

参考URL:

github.com

https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa965725(v=vs.85).aspx

http://www.classicshell.net/forum/viewtopic.php?f=13&t=7959

libfole/OLE definitions.asciidoc at master · libyal/libfole · GitHub

LNKとShell item

LNKファイルのShell item構造を確認します。

USBメモリ上にある、Example.jpgを参照し、RecentフォルダにLNKファイルを生成します。

Windows Shortcut File format specification を参考に、LNKファイルのFile headerを確認します。オフセット20からの4バイトがData flagsとなっています。 

Data flags ⇒ 0x00 20 00 93 
0x00000001 HasTargetIDList
0x00000002 HasLinkInfo
0x00000010 HasWorkingDir
0x00000080 IsUnicode
0x00200000 DisableKnownFolderTracking

フラグHasTargetIDListのビットがONになっています。このフラグは、[MS-SHLLINK]: Shell Link (.LNK) Binary File Format では下記記述となっています。

The shell link is saved with an item ID list (IDList). If this bit is set, a
LinkTargetIDList structure (section 2.2) MUST follow the ShellLinkHeader.
If this bit is not set, this structure MUST NOT be present.

 ShellLinkHeaderの続きに、LinkTargetIDList structureが存在しています。オフセット76からの2バイトを確認します。IDListSize (2 bytes)は0x013D⇒317バイトとなっています。 

ItemIDList (variable)とTerminalID (2 bytes)の合計317バイトは、下記でハイライトした範囲となります。

データ内容を、Windows Shell Item format specificationを参考にパースしてみます。
Itemの中に、タイムスタンプ情報やNTFS file referenceを確認できます。

14 00⇒20 byte
1F Class type indicator ⇒ Root folder shell item
50 Sort index
E04FD020EA3A6910A2D808002B30309D ⇒ GUID ⇒ My Computer (Computer)

19 00⇒25 byte
2F Class type indicator ⇒Volume shell item 
453A5C00000000000000000000000000000000000000 ⇒E:\

56 00⇒86 byte
31 Class type indicator ⇒CLSID_ShellFSFolder ⇒File entry shell item 0x01 ⇒ Is directory
00 ⇒ Unknown (Empty value)
00000000 File size
774C4DB8 Last modification date and time Contains a FAT date and time in UTC
1000 File attribute flags ⇒ FILE_ATTRIBUTE_DIRECTORY
466F6C6465723100 ⇒ Folder1
4000 Extension block size ⇒ 64
0900 Extension version
0400EFBE Extension signature ⇒ File entry extension block 0xbeef0004
774C47B8 Creation date and time Contains a FAT date and time in UTC
774C4DB8 Last access date and time Contains a FAT date and time in UTC
2E00 ⇒ Windows 8.1, 10
0000
2B00000000000100 ⇒ NTFS file reference
0000000000000000
0000
00000000
1D907D00
46006F006C006400650072003100 ⇒ Folder1
0000
1600 ⇒ First extension block version offset
56 00⇒86 byte
31 Class type indicator ⇒CLSID_ShellFSFolder ⇒ 0x01 ⇒ Is directory
0000000000774C4CB81000466F6C6465723200400009000400EFBE774C4CB8774C4CB82E0000002C000000000001000000000000000000000000000000A81F930046006F006C00640065007200320000001600
62 00⇒98 byte
32 Class type indicator ⇒CLSID_ShellFSFolder ⇒ 0x02 ⇒ Is file
0000A03F00774C27B820006578616D706C652E6A706700480009000400EFBE774C37B8774C37B82E00000027000000000001000000000000000000000000000000CBF826016500780061006D0070006C0065002E006A007000670000001A00

LEcmdツールを使い、example.jpg.lnkファイルをパースします。

Target ID informationの項目を確認します。

参考URL:

https://forensicswiki.org/wiki/LNK

https://msdn.microsoft.com/en-us/library/dd871305.aspx

github.com

github.com

https://ericzimmerman.github.io/

RegistryとAccess bits

レジストリファイルのAccess Bitsを確認します。検証環境はWindows 10 1709です。

サンプルのレジストリキーをHKCU(NTUSER.DAT)配下に作成します。

yarp-printを利用し、Exampleキーを作成したNTUSER.DATをパースします。ExampleキーのAccess Bits値は2となっています。
#yarp-print NTUSER.DAT

Hive information:

Last written timestamp (UTC): 1601-01-01 00:00:00
Last reorganized timestamp (UTC): 2018-03-12 09:31:35.325376

 <snip>

Key path: Example
Last written timestamp (UTC): 2018-03-17 22:04:22.066882
Access bits: 2

Value name: Example
Value type: REG_SZ
Data size: 18
Data (decoded):
Evidence\00

Windows registry file format specificationを参照し、Access bitsのオフセット位置を確認します。Access Bits値はKey nodeのオフセット14から長さ4となっています。

Registry ExplorerのTechnical detailでnk レコードを確認してみます。0x02となっている事を確認できます。<2018/3/25 追記>最新版のRegistry ExplorerではAcces Flsgsという項目で状態を確認できるようになっています。

 Windows registry file format specificationでは、Access Bits が0x02の場合は下記の説明となっています。

 0x2 This key was accessed after a Windows registry was initialized with the NtInitializeRegistry() routine during the boot

NTUSER.DAT内には0x01になっているキーが無かったので、SYSTEMハイブでAccess Bitsが1のキーを確認します。下記キーはAccess Bitsが0x01です。

Key path: ControlSet001\Control\ACPI
Last written timestamp (UTC): 2017-09-29 13:47:33.433594
Access bits: 1

 Windows registry file format specificationでは、Access Bits が0x01の場合は下記の説明となっています。

0x1 This key was accessed before a Windows registry was initialized with the NtInitializeRegistry() routine during the boot

更に、Access Bitsが0x03のキーをSYSTEMハイブで確認してみます。例えばBAMキーはAccessBitsが3となっています。

Key path: ControlSet001\Services\bam
Last written timestamp (UTC): 2017-11-05 03:07:09.907890
Access bits: 3

最後に、Access Bitsが0x00のキーをNTUSER.DATハイブで確認してみます。

Last reorganized timestamp (UTC): 2018-03-12 09:31:35.325376

<snip>

Key path: Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU\bat
Last written timestamp (UTC): 2018-03-03 00:38:38.119818
Access bits: 0

上記キーはAccess Bits値が0x00です。このキーは2018-03-12 09:31:35以降アクセスされていないという事になるようですね。

詳しくは@errno_failさんのTweetを参照していただけると良いかと思います。

参考URL:

"The access history in hive X was cleared updating Y keys and creating Z modified pages" – this event message means that access bits of all keys in the specified registry hive were set to 0. The yarp-print tool will show the access bits for each registry key (Windows 8+). #DFIR pic.twitter.com/UHEZfOfIdm

— Maxim Suhanov (@errno_fail) 2018年3月11日

github.com

binaryforay.blogspot.jp