削除された EVTX レコードのカービングとロールオーバー ログの復元

忙しいドメイン コントローラーの Security ログは、日単位ではなく時間単位で巻き戻ります。既定のチャネル サイズは 20 MB で、ノイズの多いホストでは数千レコード分しかありません。3 週間前に始まったインシデントへの対応でディスクをイメージ取得する頃には、実際に見たかったイベントはライブ ファイルから外れて、未割り当て領域、pagefile、場合によってはハイバネーションに眠っています。これらをカービングで取り戻すのは、EVTX 中心の調査のルーチンの一部です。多くの防御担当者はそれをスキップします。ライブ ファイルを唯一の正本のように扱うからです。

そうではありません。ライブ ファイルは最後の 20 MB です。残りはディスクにあります。

シグネチャ: 2a 2a 00 00

EVTX レコードはすべて、4 バイトのマジック 2a 2a 00 00 で始まります。これは ** の後に 2 つの NULL バイトです。このシグネチャは、bulk_extractor、scalpel、あるいはカスタムの 4 バイト grep で生のディスク イメージをスキャンしても十分に有用な候補集合が得られるほど特徴的です。Windows ボリュームでのシグネチャ密度は低く、ヒットのほとんどは実レコードです。

マジックに続く構造は十分に定義されており、ヒットを安価に検証できます。

• バイト 4-7: Size (uint32)。妥当な値であるべき (最小 32 バイト、通常 4 KB 未満)。
• バイト 8-15: EventRecordIdentifier (uint64)。対象期間にとって妥当な RecordID であるべき。
• バイト 16-23: FILETIME としての WriteTime。Vista (EVTX の最初のバージョン) から現在までの範囲に収まるべき。
• バイト Size-4 から Size まで: 同じ Size 値が末尾マーカーとして繰り返される。

先頭の Size が末尾の Size と一致し、FILETIME が妥当な日付に解析され、RecordID が範囲内である候補は、圧倒的に実レコードである可能性が高いです。これら 4 つのチェックで誤検出はほぼゼロに落ちます。

問題は、先頭と末尾の間のバイトをどう扱うかです。

チャンク問題

EVTX レコードは、チャンクごとに 1 回だけ保存されるテンプレートと文字列を参照します。孤立してカービングされたレコードは、適用先のテンプレートのない置換配列を持っています。置換配列から型付きの値を直接読むことはできるので、フィールド レベルのデータ ("ユーザー X が時刻 T に IP Y からログオン") は復元できますが、ライブ パーサーが返すレンダリング済み XML は、チャンクなしには再構築できません。

これがカービングの 2 つの結果の違いです。

• レコード単独カービング: RecordID、タイムスタンプ、EventID、置換値を復元します。フィールド別のイベント ビューは構築できますが、人間可読のレンダリング済み XML は得られません。
• チャンク カービング: チャンク (ElfChnk\0 マジック、64 KB アライン) を見つけて、そのテンプレート テーブルとレコードを復元します。これですべてが揃います。

ElfChnk\0 もシグネチャ カービング可能です。チャンクはディスク上でセクター境界に乗るため、64 KB アライメントは助けになります。オフセット アラインのシグネチャ スキャンは高速です。多くのカービング ツールが両モードをサポートしており、両方を実行すべきです。チャンクは読めるイベントを与え、孤立レコードは囲んでいたチャンクが残っていないときに残りを埋めます。

バイトが眠る場所

スキャンする価値のある場所を、収量の多い順に。

• %SystemRoot%\System32\winevt\Logs\ をホストするボリュームの未割り当てクラスタ。EVTX ファイルがロールオーバーまたはクリアされると、古い内容は未割り当てになります。NTFS は未割り当てクラスタをゼロ化しないので、バイトは再利用されるまで復元可能です。書き込みチャーンの少ないサーバーでは、これが数週間になります。
• ライブ EVTX ファイル内のスラック領域。EVTX ファイルは 64 KB チャンクで書かれます。ファイルの最後のチャンクはしばしば部分的にしか埋まっておらず、スラックには現在のチャンクがサイズ ダウンされる前にそのバイトに書かれた前世代のデータが含まれます。スキャンする価値があります。
• pagefile.sys。イベント ログ サービスは最近のレコードとテンプレートをメモリにキャッシュします。それらの構造をバックアップするページは、メモリ圧迫下でスワップ アウトされます。pagefile は、ホストがクラッシュしたり強制終了されたりしてディスクにフラッシュされなかったレコードの金鉱です。
• hiberfil.sys。ハイバネーション時の物理メモリの圧縮スナップショット。Volatility 3 か Hibr2Bin で解凍し、結果の生メモリでレコード シグネチャを検索します。
• ライブ レスポンスで取得した RAM dump。イベント ログ サービスのワーキング セットには、最近のレコードとそれらをレンダリングするのに必要なテンプレートが含まれています。
• シャドウ コピー (VSS)。ボリュームの古いスナップショットには、ライブ EVTX ファイルの古いバージョンが含まれます。vshadow または vssadmin list shadows の後に mklink /d でシャドウをマウントすると、シャドウ時点でライブだったレコードを含む、前世代のファイル コピーが得られます。

VSS は、有効でかつ VSS 層で改ざんされていないホストでは、最もレバレッジの高いソースです。現代の Windows サーバーは通常 7 〜 30 日分のシャドウ コピーを持ちます。インシデントが 3 週間前なら、当時のシャドウには、改ざんされていないライブ ログがそのまま残っているかもしれません。

不正形式の入力を扱うツール

カービング シナリオで綺麗な EVTX ファイルは稀です。部分的なチャンク、末尾の欠けたレコード、チャンク外のオフセットを参照するテンプレート、そして CRC 失敗が至るところで発生します。これらを扱うパーサーは、綺麗なファイルを扱うものとは別物です。

• EvtxECmd (Eric Zimmerman)。IR 現場業務でベストインクラス。--inc を渡すと、通常解析に失敗したレコードを含めて、部分レコードから読めたものを出力します。CSV 出力はタイムライン作業に向いています。
• hayabusa (Yamato Security)。大規模 EVTX コーパスを横断するハンティング向けに、Sigma 風ルールを伴って作られています。部分チャンクをまずまず扱え、高速です。--exclude-status フィルタで破損レコードのノイズを抑制できます。
• evtx_dump (Omer Ben-Amram の Rust クレート)。不正形式構造に強く、JSONL 出力。jq や SIEM へのパイプラインに向きます。
• evtxtools (Joachim Metz、libevtx の一部)。形式に対するリファレンス実装。他より遅いですが、レコードが部分的に復元されたときに、どのフィールドがどの検証で失敗したかを正確に教えてくれます。カービング出力のデバッグにはこれが欲しい。
• EVTX スキャナ付きの bulk_extractor。カービング ステップそのもの。候補レコードを、後の検証用にソース イメージ内のオフセット付きで出力します。

実用的なパイプライン:

1. bulk_extractor -E evtx -o out/ image.dd でディスク イメージから候補レコードとチャンクをカービング。
2. カービングされたチャンクを偽造ファイル ヘッダーと連結して、合成 EVTX ファイルに再構成。libevtx の例には evtxexport 互換のチャンク リアセンブラがあります。
3. 再構成ファイルに対し EvtxECmd を --inc 付きで実行し、読めるものすべてを CSV にダンプ。
4. カービングされた RecordID をライブ ファイルの RecordID と差分し、ライブ ログになかったレコードを見つける。

ステップ 4 の出力がカービングの果実です。攻撃者または時間がライブ ファイルから取り除いたイベントです。

ロールオーバーでライブ ログが何も示さないとき

カービングの一般的なケースは、アンチフォレンジック クリアではありません。ロールオーバーです。Security ログが 20 MB、毎秒 50 イベントのホストでの 30 日前のインシデントは、ファイル全体を数十回もロールしています。ライブ ログは直近数時間しか映していません。その間のすべては未割り当てにあります。

ここでのカービングは、改ざんがないため単純です。未割り当てをスキャンし、チャンクを見つけ、再構成します。収量はロールオーバー以来、ボリュームがどれだけ書き込みチャーンを受けたかに依存します。ほぼ静的なシステム ファイルが大半を占め、EVTX ディレクトリが主な書き込みソースであるサーバー ボリュームでは、古いチャンクが長期間そのまま残ります。重いアプリケーション書き込みのあるボリュームでは、未割り当て領域が早く上書きされます。

役立つコツ: EVTX ディレクトリは %SystemRoot%\System32\winevt\Logs\ にあり、競合書き込みの点でボリュームの中で最も冷たいスポットの 1 つです。EVTX ファイルがロールしたときに解放されたクラスタ ランは、しばしば数週間未割り当てのまま残ります。アプリケーション データをホストするボリュームでは同じことは言えません。

復元したもので何をするか

カービングされたレコードは、ライブ レコードと同じタイムラインに入ります。RecordID と WriteTime はカービングで生き残り、それが結合キーです。疑わしい初期アクセス時刻のカービング済み 4624 Type 3 は、完全な XML を必ずしもレンダリングできないという制限はありますが、ライブのものと同じくらい有用です。

以下と相互参照してください:

• Security.evtx の Master File Table エントリ。クリアやロールオーバーでファイルが書き換えられた時刻が分かります。
• EVTX ファイルの DATA_OVERWRITE イベントを示す USN journal。各ロールオーバーの高解像度タイムスタンプが得られます。
• 欠落期間中に実行されたバイナリの Prefetch。Prefetch は Security.evtx から独立しており、ログ クリアを生き残ります。
• 初回実行の証拠としての AmCache と Shimcache。
• インシデント時の状態を捉えるシャドウ コピー内の registry ハイブ。

Prefetch エントリと、疑わしいバイナリの MFT タイムスタンプに揃うカービング済みレコードは、発見です。単独のカービング レコードは、追う価値のある手がかりです。

参考資料

• Andreas Schuster の元のカービング作業 (DFRWS 2007 論文)。現代のあらゆるツールのカービング ヒューリスティクスはここに遡ります。
• Eric Zimmerman の EvtxECmd ドキュメントと、部分レコード処理のための --inc フラグ。
• Yamato Security の hayabusa と付属のサンプル コーパス。カービング パイプラインのテストに有用です。
• Simson Garfinkel の bulk_extractor と EVTX スキャナ モジュール。