16章

1 NTFSファイルシステムの概要と解析

NTFSは、Microsoft社によって開発されたファイルシステムで、現行のバージョン（3.1）はWindows XPから採用されたものです。なお、バージョン番号自体は3.1のままですが、Windowsの進化に伴ってNTFS内部の機能（ログ記録、アクセス制御など）は拡張され続けています。

NTFSにはさまざまな機能がありますが、ここではデジタルフォレンジックで特に重要な、MFT（Master File Table）によるファイル／フォルダの管理方式を中心に紹介します。

NTFSの構成

NTFSでは、ディスクボリュームの初期化時に、MFTをはじめ、計12種類のNTFS管理用システムファイルをディスク上に配置します。これらのシステムファイルは、すべて先頭に「$」（ドルマーク）がつく特殊なファイルで、エクスプローラー等の標準機能では表示できません。MFTは「$MFT」というファイル名で配置され、他の「$」がついたシステムファイルのロケーションは、MFTで管理されます。

「$MFT」のロケーションについては、NTFSボリュームの先頭クラスターにありOSブート時に読み込まれる、VBR（Volume Boot Record）に記録されています。MFTのロケーションが記録されている位置は、次のHEXダンプで示すように、VBRのオフセット：0x30～0x37です。

• NTFS Volume Boot Record

12種類のNTFS管理用システムファイルを以下に列挙します。なお、MFTで管理するすべてのファイル／フォルダには、新規作成時に「ファイルID」となる一連番号が付与されます。ファイルIDはファイルシステム内で一意かつ不変であるため、削除されたファイルの痕跡分析や、MFTレコードの復元作業など、フォレンジックにおける極めて重要な指標となります。12種類のNTFS管理用システムファイルにもこの「ファイルID」が付与されます。「$MFT」のファイルIDを0（ゼロ）として、次の「$MFTMirr」から最後の「$Extend」までは、順に1から11の番号が固定で割り当てられます。

• $MFT（ファイルID：0）
• $MFTMirr（1）
  • 障害時にバックアップとして使用するMFTの複製
    
• $LogFile（2）
  • NTFS障害時の回復のために使用されるトランザクションログ
    
• $Volume（3）
  • ボリュームに関する情報（ボリュームラベルやボリュームバージョンなど）
    
• $AttrDef（4）
  • NTFSで使用される属性定義のリスト
    
• $（5）
  • ルートフォルダ
    
• $Bitmap（6）
  • クラスターの使用状況管理ファイル
    
• $Boot（7）
  • VBR（Volume Boot Record）のコピー
    
• $BadClus（8）
  • ボリュームの不良クラスター情報
    
• $Secure （9）
  • 各ファイルのセキュリティ記述子
    
• $UpCase（10）
  • 小文字とUnicode大文字の変換テーブル（ファイル名用）
    
• $Extend（11）
  • 拡張機能用のフォルダ（同フォルダ内にUSNジャーナルが作成される）
    

• NTFSボリュームのルートフォルダ表示例（FTK Imager）

MFTの構造と記録内容

MFTレコード

MFTは単一のファイル（$MFT）として、NTFSパーティションのルートフォルダに格納されています。MFTの内部は、固定サイズ（通常は1024バイト）のレコードで構成されており、原則1レコードで1つのファイル／フォルダのメタデータを管理します（一部の大容量ファイルや多数の属性を持つファイルでは、複数のMFTレコードを用いて管理される場合があります）。 各レコードの先頭には、シグネチャ（文字列「FILE」）ではじまるヘッダ領域があり、その中にファイルIDや、後述するフラグ（ファイル／フォルダ、現存／削除済みを示す）などの基本情報が含まれます。

各レコードヘッダの後には、属性情報と呼ばれる複数のブロックが続き、さまざまなメタデータが記録されます。なお、レコードが管理する対象オブジェクトの条件（ファイルかフォルダか、ファイルサイズの大小など）によって、保持する属性情報の種類や構造は異なります。

• MFTレコードのフォーマット（概略）

属性情報：$STANDARD_INFORMATION属性と$FILE_NAME属性

通常のファイル／フォルダのメタデータを管理するレコードは、共通の属性情報として、次の2つを保持します。

• $STANDARD_INFORMATION属性（$SI）
  • 作成日／更新日時などのタイムスタンプ、隠しファイル／読み取り専用等の属性フラグ、などを格納
• $FILE_NAME属性（$FN）
  • ファイル名、親フォルダのファイルID、作成日／リネーム日時などのタイムスタンプ、などを格納

エクスプローラーで表示するファイルのプロパティでは、この2つの属性情報と、後述する$DATA属性などから情報を取得して表示しています。

• エクスプローラーのプロパティとMFTの属性情報

なお、次のような場合には、１つのレコード内に複数の$FNが作成されます。

• ファイル名が、Windows以前のMS-DOSにおける命名制限（名前は8⽂字以内、拡張⼦は3⽂字以内、一部記号の使用禁止等）に反するため、互換性維持用の別名、いわゆる「短いファイル名」を自動生成したとき

  ※例「Program Files」→「PROGRA~1」

• 当該ファイル／フォルダに対するハードリンクが作成されたとき

属性情報：$DATA属性

$DATA属性のヘッダには、データの実サイズやディスク上のアロケーションサイズなどが記録されます。ファイルを管理するMFTレコードの場合、その後に続くブロックは、ファイルのサイズによって「Resident」／「Non-Resident」と呼ばれるタイプに分かれ、それぞれ記録形式や内容が異なります。

「Resident（常駐）」は、データのサイズが最大700バイト程度までの比較的小さいファイルで、この場合はMFTレコードの$DATA内にデータそのものが格納されます。つまり、$MFTファイルのMFTレコード内にデータそのものが内包されますので、他のデータ領域を消費しません。

一方、「Non-Resident（非常駐）」は、データサイズが比較的大きいファイル、具体的には、MFTレコードに記録される属性情報とデータサイズの合計が1024バイト（1つのMFTレコードの固定長）を超えるファイルを管理するMFTレコードです。この場合、データは$MFTファイルには内包されず、ディスク上の別のデータ領域に格納されます。その場合、$DATAには、格納されたデータ領域の先頭クラスター番号を示す値などが記録されます。

次の図は、ResidentであるMFTレコードの例です（ファイル名：cdir.ini）。$DATAにデータそのものが内包されていることを視認できます。

• 「cdir.ini」ファイルのMFTレコード（FTK Imagerによる$MFTのHEXダンプ）

• 実際の「cdir.ini」ファイル（ファイルサイズ：449バイト）

削除されたファイル／フォルダのMFTレコード

ファイルやフォルダが削除された場合でも、NTFSのMFTレコードは即時に消去されるわけではありません。削除済みを示すフラグが立つだけで、他の情報は基本的にそのまま保持されます。いずれ新たなファイルやフォルダが作成された際に、情報が上書きされて再利用されます。その際、ファイルIDはそのまま再利用されるため、「過去にそのIDが割り当てられていたファイル」と「現在のファイル」とが異なる場合もあります。そのため、時系列の整合性や証拠保全の場面では注意が必要です。

削除済み（Deleted）かどうかを示すフラグは、各MFTレコードのヘッダに記録されます。具体的には、各レコードのオフセット：0x15（10進数:21）から開始する2バイトに、次のバイナリ値で記録されます（オフセットは、レコードの先頭位置を0として相対位置を示します）。

先述の「cdir.ini」ファイルのヘッダをみると、フラグは「01 00」になっていますので、現存するファイルであることが確認できます。次の図は、MFTレコードのHEXダンプから、該当部分を示したものです。なお、Windows PCのバイトオーダー（複数のバイトの転送方式）はリトルエンディアン（下位のバイトから先に転送）であるため、HEXダンプの表示上は、上位の桁（0x01）は右側、下位の桁（0x00）が左側と、上位と下位が逆になることに注意して下さい。

• 「cdir.ini」ファイル：MFTレコードヘッダのフラグ

現在のところ、このフラグの2バイトのうち上位の1バイトしか使用されていませんので、実質的にはオフセット：0x16（22）で判定できます。

ファイルの削除→再利用時におけるMFTレコードの変化は、次の例のようになります。

1. ファイル「test.dat」を作成
   • ファイルID：25
   • ファイル名：test.dat
   • フラグの上位桁（オフセット：0x16）：01（現存ファイル）
     
2. ファイル「test.dat」を削除（※ごみ箱は経由しない）
   • ファイルID：25
   • ファイル名：test.dat
   • フラグの上位桁（オフセット：0x16）：00（削除済みファイル）
     
3. ファイル「abcd.txt」を作成（MFTレコードの再利用が発生）
   • ファイルID：25
   • ファイル名：abcd.txt
   • フラグの上位桁（オフセット：0x16）：01（現存ファイル）
     

上記3のタイミングで、MFTレコードの$DATA属性も同時に上書きされるため、Resident（データ本体を内包）のMFTレコードでは、データ内容の復元は不可能となります。一方、Non-Residentであれば、MFTレコードが上書きされても、データ領域は上書きされずに残っている可能性があります。その場合は、「証拠保全Ⅱ」の章で紹介した「カービング」（ファイルヘッダなどの特徴をもとに未割当領域から削除データを抽出する手法）で復元できるケースもあります。

なお、削除済みファイルのMFTレコードが再利用されるタイミングは、ディスクボリュームの容量やタイプなどによってOSが自動的に調整しており、一定ではありません。そのため、削除済みファイルの復元が必要なケースでは、調査対象PCの操作を最低限にとどめたうえ、可能な限り速やかにMFTの保全や物理イメージの取得を行うことが重要です。

また、ファイルやフォルダをごみ箱に入れた場合は、フラグは削除済みには変更されず、現存するファイル／フォルダを示したまま（0x01／0x03）で、親フォルダIDがごみ箱フォルダ（$Recycle.bin）のファイルIDに変更されます。つまり、MFT上では削除ではなく、移動（親フォルダの変更）というステータスになります。詳細は次項で紹介します。

ごみ箱（$Recycle.Bin）の調査における留意点

ごみ箱（$Recycle.Bin）へ移動されたファイルは、自動的にランダムなファイル名にリネーム（$Rファイル）されます。同時に、$Recycle.Bin内に、インデックス情報（元のファイル／フォルダ名）を記録するファイル（$Iファイル）が新規作成されます。次にその例を示します。

• 元のファイルは「C:\temp\abcd.exe」とする。
• リネーム：ごみ箱へ移動後、元のファイル名が$Rファイルに変更される（MFTレコード）。
  • ファイル名の変更（ファイル名先頭の「$R」に続きランダムな文字列を付与）
    • 例：abcd.exe　→　 $RX4MCG0.exe
      
  • 親フォルダIDが、ごみ箱フォルダのファイルIDへ変更
    • 例：C:\temp　→　C:\$Recycle.Bin\（SID）
      
  • ファイルIDは変更されずに維持
  • フラグは、現存ファイル（0x01）のステータスを維持
    
• インデックス情報ファイル作成：ごみ箱フォルダ内に、ごみ箱へ移動されたファイルとペアになる、$Iファイルが新規作成される（ファイル名は、先頭の「$I」に続いて、「$R」以降と同一のランダムな文字列を付与）。
  • 例：C:\$Recycle.Bin\（SID）\$IX4MCG0.exe
  • ファイルIDは新規に付与
  • インデックス情報ファイル内には、Unicode文字列で元のファイルパスを記録
    • 例「C:\temp\abcd.exe」
      

ごみ箱フォルダに入れられたファイル（リネーム後のファイル）とインデックス情報ファイルは、それぞれ「$R」「$I」以降のファイル名が同一となることで紐づけられます。上の例では、「$RX4MCG0.exe」と「$IX4MCG0.exe」になります。いずれも、拡張子は元のファイルのものが付与されますが、インデックス情報ファイルの実体は、Unicodeテキストを含む特殊な形式のバイナリファイルです。

次の図は、インデックス情報ファイル内に、Unicodeテキストで記録された、元のファイル名（フルパス）の例です。

• FTK Imagerによる$Recycle.Bin内インデックス情報ファイルの表示例
  

「$I」ファイルのサイズは、記録するファイル名の長さにより変動しますが、数百バイト程度で収まるケースがほとんどです。そのため、ほぼすべての「$I」ファイルは「Resident」になります。ごみ箱から削除された後でも、「$I」ファイルのMFTレコードが残っていれば、$DATA属性から元のファイル名を確認できる可能性があります。

エクスプローラーでごみ箱を開いた際は、リネームされた「$R」ファイルや生成された「$I」ファイルは表示されず、元のファイル名のまま格納されているように見えますが、実際は上述のような制御が行われています。

なお、ごみ箱（$Recycle.Bin）内での命名ルールやファイル形式に沿わないファイルが存在する場合、不審なファイルとして調査することを推奨します。ごみ箱にファイルを隠匿するマルウェアも観測されていますので、その仕組みをよく理解しておきましょう。

代替データストリーム（ADS）

最後に、マルウェアや攻撃者がデータを隠匿するために使用することがある、代替データストリーム（ADS： Alternate Data Stream）について紹介します。

NTFSでは、1つのMFTレコード内に複数の$DATA属性を持たせることが可能です。このうち、ファイル名とは異なる名前（ストリーム名）が付与された$DATA属性が「ADS」に該当します。

このADSは、通常のファイルのデータとは別のデータ領域であり、ファイル本体と並行して情報を保存できます。よく知られる例としては、Windows OSが、インターネットからダウンロードされたファイルに対する危険性評価に使用するため、ダウンロードURL等の情報を「Zone.Identifier」というストリーム名のADSへ記録するケースです。

ADSは、エクスプローラーなどの一般的な標準機能やアプリケーションでは表示されませんが、コマンドプロンプトから「dir /r」コマンドでリスト表示できます。

次の例は、「dir /r」で、「test.dat」ファイルのADS「Zone.Identifier」をリスト表示させたものです。この例では、ADSが「test.dat:Zone.Identifier:$DATA」と表示されています。このようにADSは、本来のファイル名に続く「:」（コロン）の後に、名称が表示されます。

• ファイル「test.dat」のADS（Zone.Identifier）を表示

ADSの名称がわかれば、次の例のように、moreコマンド等へのリダイレクト入力で内容を表示できます。

• ADS（test.dat:Zone.Identifier）の内容を表示

  
  

ADSの作成は、コマンドプロンプトでの操作を例にすると、次のようなコマンドで実行できます。

echo HELLO WORLD! > test.dat:ABC

この例では、記録したい文字列「HELLO WORLD!」を、ファイル名「test.dat」に「：」（コロン）で続けた「ABC」という名称のADSにリダイレクト出力しています。

マルウェアが、ADSを悪用して情報を隠匿する例も観測されています。調査の際は、ADSの存在も念頭におきましょう。