← ブログに戻る

4 つの MFT タイムスタンプと、timestomping がそこにどう現れるか

· 読了 2 分

すべての MFT レコードは、2 つの別個の属性に 4 つのタイムスタンプを保存します。それはレコードあたり 8 つの数字です。それらは常に同期しているわけではありません。それらの関係、そしてそれが破綻する場所が NTFS 時間分析の基礎です。MFT フォレンジックで 1 つだけ詳細を学ぶなら、これを学んでください。

NTFS が記録する 4 つの瞬間

$STANDARD_INFORMATION（SI、属性タイプ 0x10）と $FILE_NAME（FN、属性タイプ 0x30）はどちらも、同じ 4 つのイベントのタイムスタンプを保持しています。

  • Created: ファイルが最初にボリュームに書き込まれたとき。
  • Modified: ファイルの内容が最後に変更されたとき。
  • Accessed: ファイルが最後に読まれたとき。
  • MFT-modified: レコード自体が最後に更新されたとき（データだけでなく、任意の属性変更）。

タイムスタンプは Windows FILETIME 形式（1601-01-01 UTC 以来の 100 ナノ秒ティック）の 64 ビット値として格納されます。100 ナノ秒の粒度。自然なイベントが下位桁にノイズを残すのに十分なビットがあります。

なぜ 2 つの組が存在するか

$STANDARD_INFORMATION は、ユーザーランドが見るタイムスタンプの組です。Win32 API の SetFileTime はここに書き込みます。タイムスタンプに触れる日常的なファイル操作はすべて SI を更新します。書き込み、読み取り（アクセスタイム設定に依存）、リネーム、属性変更。

$FILE_NAME は初期の NT で POSIX サブシステム互換のために追加され、歴史的な理由で残っています。名前が変わるときだけ更新されます。作成（名前が最初に設定されるとき）、リネーム（名前が変わるとき）、ディレクトリ間の移動（NTFS の意味でのリネーム）。それ以降、ファイルがその名前を保持する限り FN は変更されません。

実務上、これは SI タイムスタンプは常時刻んでおり、FN タイムスタンプは安定していることを意味します。非対称性が timestomping を検出可能にします。

timestomping は何をするか

タイムスタンプを変更するツールは通常 SetFileTime を呼び出します。これは SI に書き込みます。FN には触れません。timestomping 後。

  • SI は攻撃者が選んだ任意のものを示します。最近ドロップされたツールをシステムファイルのように見せるためにしばしば数年バックデートされるか、実際の活動時間を曖昧にするために前進させられます。
  • FN は依然として実際の作成時間を反映しており、場合によっては大きな差があります。

これが標準的な timestomping シグネチャを生成します。SI created が 2018 年で FN created が 6 分前のファイルです。

トリアージ中に注意すべき 2 つのパターン。

  1. SI created が FN created より古い。 これは自然には不可能です。ファイルは名付けられる前には存在できません。SI created が FN created より前のあるレコードはすべて触れられています。
  2. 明らかにリネームされていないファイルで SI modified が FN modified から大きく離れている。 FN modified はリネーム時のみ動きます。SI が 2017 で FN が間にリネームなく昨日なら、何かが間違っています。

二重リネームのトリック

SI/FN の乖離が検出可能であることを知っているオペレーターは回避策を使います。ファイルをリネームし（NTFS に FN を更新させる）、SI と FN の両方で SetFileTime を呼び、リネームバックします。これで両方の属性がバックデートされた値を示します。

これは SI/FN の比較を打ち負かします。次のものは打ち負かしません。

  • USN ジャーナル。 すべてのリネームは RENAME_OLD_NAME / RENAME_NEW_NAME のペアを書き込みます。トリックに必要な 2 つのリネームはジャーナルに見えます。ジャーナル内のそれらのタイムスタンプは、偽装された FN 値ではなく実際の時刻です。
  • $LogFile。 リネームを囲むトランザクションレコードがログに座っています。
  • VSS スナップショット。 古いスナップショットは stomp 前の FN 値を持っています。同じレコードについて現在の MFT とスナップショットの MFT を差分してください。

二重リネームは静かに行うのが難しいです。それでも成熟したレッドチームツールキットでは一般的です。

サブ秒の粒度、雑なツールの決め手

NTFS はタイムスタンプを 100 ナノ秒のティックで保持します。ネイティブの Windows 操作は下位桁にノイズを残します。OS はタイムスタンプを書き込むときにサブ秒の成分をゼロアウトしません。カーネルクロックが返したものが記録されます。

ほとんどの timestomping ツールは書き込む前に秒単位に丸めます。結果は .0000000 UTC で終わるタイムスタンプです。1 つのそのようなタイムスタンプは取るに足らない（時折の自然なイベントは丸めることがあります）。多くのファイルにわたって整列した .0000000 のサフィックスの列はフィンガープリントです。

これは確認しやすいです。MFT 解析から created、modified、accessed、MFT-modified の列を取り、4 つの SI タイムスタンプすべてが .0000000 で終わるレコードをフィルタします。自然な Windows 活動のベースラインと比較します。コントラストは即座にわかります。

Windows 自身がタイムスタンプに何をするか

SI/FN 比較を使うには、Windows が 4 つのフィールドに対して自分で何をするかを知る必要があります。チートシート。

  • SI created: 作成時に書き込まれます。一部のインストーラがファイルを「作成」（抽出によって）するときに更新します。
  • SI modified: すべてのデータ書き込み時に書き込まれます。SetFileTime で更新されます。メタデータのみの変更では更新されません。
  • SI accessed: Windows 7+ ではデフォルトで無効（有効化するには fsutil behavior set disablelastaccess 0 を設定）。無効でも、このフィールドは特定の操作（バックアップソフトウェア、EDR スキャン）によって時折更新されますが、どちらの方向にも「最後に読まれた」シグナルとして信頼性がありません。
  • SI MFT-modified: リネーム、ACL 変更、ADS 作成、データ書き込みを含む任意の属性変更時に書き込まれます。
  • FN created: 名前が最初に設定されるとき（作成、ハードリンク作成、リネーム）に書き込まれます。
  • FN modified, FN accessed, FN MFT-modified: 名前が設定されたときに書き込まれ、その後はほぼ安定です。

クリーンインストールでは、FN の 4 つのタイムスタンプは通常等しくなります（名前が割り当てられた同じ瞬間にすべて設定されました）。FN の 4 つのタイムスタンプが同一で SI の 4 つが乖離している場合、それは正常です。

Windows Update とパッチを当てたバイナリ

Windows Update はパッチを当てたバイナリの SI タイムスタンプに触れます。累積アップデート後、\Windows\System32\ の半分は数分以内の SI modified を持ち、FN は最後のサービスパック以来安定です。これは正常です。これを異常な活動としてではなく、ベースラインパターンとして扱ってください。

パッチウィンドウについて CBS.log および setupapi.dev.log とクロスリファレンスしてください。SI が svchost.exe が 03:14 に変更されたと言い、CBS ログが 03:14 にコンポーネントインストールを示すなら、それは Windows Update であり、攻撃者ではありません。

私が timestomping をスクリーニングする方法

新規の MFT 抽出で実行するスクリーン。

  1. SI created < FN created のすべてのレコードを取得します。各レコードを手動で確認します。
  2. SI modified が FN modified の 30 日以上前であり、ファイルがユーザー書き込み可能なディレクトリにあるすべてのレコードを取得します。手動で確認します。
  3. 4 つの SI タイムスタンプすべてが .0000000 で終わり、ファイルが Windows システムバイナリではないすべてのレコードを取得します。手動で確認します。
  4. 現在の MFT を最新の VSS スナップショットと差分します。SI タイムスタンプが逆行したレコードをハイライトします。手動で確認します。

そのシーケンスは実環境での timestomping の大多数を捕まえます。二重リネームのトリックや VSS 削除を使用する洗練されたオペレーターには、検出にジャーナルとイベントログのレイヤーが必要ですが、上記の 4 つのチェックは他のアーティファクト（USN ジャーナル内のリネーム、イベントログ内の VSS 削除）を通じて、いずれにせよ彼らを浮かび上がらせます。

参考資料

関連記事

外部リソース