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ファイル）に画像ファイルが含まれている場合、それが抽出される事はない。
コンテナファイルとして、他のデータを含んでいるのに、「埋め込みファイルの抽出」では取り出されないデータとしては他に何があるでしょうか？
Autopsy 4.4.1 疑わしいファイル機能
Autopsy 4.4.1 のベータ機能テスト
Autopsy には事前に定義した「疑わしいファイル」を探すモジュールがあり、オプションメニューからルールセットの作成ができる。
Interesting Files Identifier Module
http://sleuthkit.org/autopsy/docs/user-docs/4.4.1/interesting_files_identifier_page.html
下記はオプションから「疑わしいファイル」のタブを選択したところ。
「新規セット」から新しいセットを作成し、次に「新規ルール」から一致させる条件を設定する。
条件としては、対象をファイル・フォルダ・全てから選択し、その他の項目としてファイル名、パス、MIME タイプ、ファイルサイズなどの項目を指定できる。項目により正規表現も利用が可能。
例えば下記図であれば、MIMEタイプとして JPEG 画像を設定しているので、拡張子が変更されていたとしても、MIME Type に従い検出が行われる。
セット内で複数の項目を指定した場合には、AND で評価される。
例えば拡張子は不明だが、ファイル名に一定の文字列を含み(正規表現を利用)、かつMIME Type が JPEG のファイルといった条件を設定する事ができる。
項目としてハッシュ値が無い為、ハッシュ値で一致させたい場合にはこの機能を利用するのではなく、ハッシュデータベースの方で登録する必要がある。
ルールを作成後、「疑わしいファイル」モジュールを実行すると、作成したルールを選択する事ができる。
モジュールの実行結果は、「疑わしいアイテム」のツリーから確認ができる。ルールで設定した条件に一致したファイルが項目として表示される。
インジェストモジュールとして「疑わしいファイル」を実行する際に、同じルールを再実行すると、重複して結果が登録されてしまうので注意が必要。（モジュールの結果を削除する項目が見当たらない）
今回、Autopsy 4.4.1 のベータ機能として追加されたのが「central repository」ですが、デフォルトでは無効になっています。モジュールを利用するには、アクティブ化を選択し適用します。
アクティブ化してある場合は、インジェストモジュールの項目として Correlation Engine を選択できるようになる。
ただ、このモジュールを有効にした後、該当モジュールを実行しても設定が無いということでエラーメッセージが表示される。
Case メニューに項目は見えるが、グレーアウトされておりプロパティを確認できない状況。
何かしらの設定が必要なようです。
Autopsy 4.4.1 リリース
リリースノートを参照
バージョン 4.4.1 の変更点は下記に記載されています。幾つか新たな機能追加があります。
https://github.com/sleuthkit/autopsy/releases/tag/autopsy-4.4.1
-
Beta version of new central repository feature has been added for correlating artifacts across cases; results are displayed using an Interesting Artifacts branch of the Interesting Items tree and an Other Data Sources content viewer.
-
Results viewer (top right area of desktop application) sorts are persistent and can be applied to either the table viewer or the thumbnail viewer.
-
The View Source File in Directory context menu item now works correctly.
-
Tagged image files in the HTML report are now displayed full-size.
-
Case deletion is now done using a Case menu item and both single-user and general (not auto ingest) multi-user cases can be deleted.
-
Content viewers (bottom right area of desktop application) now resize correctly.
-
Some potential deadlocks during ingest have been eliminated.
-
Assorted performance improvements, enhancements, and bug fixes.
ベータバージョンの機能として「central repository feature」が追加。
複数ケースで検出されたものを参照する機能のようですが、検証しないと使い道がよく分からないので、これは後日検証。
ソート順の設定
次に、Results viewer におけるのソート機能ですが、画面上はこの部分ではないかと思いますが、この項目は 4.4.0 までは無かった項目ですね。
ただ、手元で試している範囲では指定した順序でソートが適用され“ない”ように見えますが、日本語の影響でしょうか？、英語版環境でどうなるか別途検証が必要です。
英語版環境上でソート機能を試したところ、期待した動作になっています。日本語に翻訳されている悪影響でしょうか。ここで設定したソート順は、テーブルに切り替えても維持されている事も確認できました、便利な機能だと思いますが英語環境でないと使えない状況です。
ケースの削除
このバージョンから、ケースの削除がメニューから可能になっています。従来はケースを削除するにはフォルダを手動で削除する必要がありましたが、メニューから「ケースを削除」が選択できるようになっています。
ソースファイルの表示
結果のツリー内でデータを参照している場合に、データソースのツリーで該当ファイルを参照する機能が正しく動作するようになったという事ですが、メニューとしては下記図の項目ですね。
Autopsy 4.4.0 におけるキーワード検索(Stem)
Autopsy のキーワード検索で、Stem を利用した検索が可能かを確認。
サンプルデータは Content-Encoding: windows-1252 として認識されているテキスト ファイル。また、サンプル文字列として、solr.PorterStemFilterFactory で例示されている文字列パターンとして "riding", "rides", "horses" を末尾に追記。
上記の「インデックス化されたテキスト」に対して、例示されている"ride", "hors" を完全一致で検索しても、"riding", "rides", "horses" の文字列にはヒットしない。
Autopsy 4.4.0 のキーワード検索は stem による検索を利用できないので、サブストリング一致で検索を行う必要がある。（サブストリング一致で ride を検索しても、riding に一致するわけではないですが）
スキーマファイルを調整する事で可能になるかもしれないが未確認。
stemを意識して検索する必要があるキーワードのパターンとしては、他にどのような文字列がありますか？
