Windows マシンのない環境で .evtx ファイルを読む

ログは、あなたが座っているマシン上には決してない

パターンはいつも同じです。何かが起きた——侵害の疑い、ロックアウトの嵐、03:00 に死んだサービス——そして証拠は、誰かがエクスポートし、イメージ化し、あるいは起動できない、ログオンできない、触れる許可のないマシンからコピーした Windows イベントログです。自分のマシンは Mac か Linux ワークステーションか、Windows VM の影もないロックダウンされた会社支給ノート PC です。イベント ビューアーは助けに来ません。

幸いなことに、.evtx ファイルは文書化された自己完結型のバイナリ形式です。イベント ビューアーがレコードについて見せるものはすべて——以下で扱う重要な例外を 1 つ除いて——ファイルの中にあり、まともなパーサーならどこでも読めます。このサイトの EVTX ビューアー は、そのパーサー（Rust の evtx crate を WebAssembly にコンパイルしたもの）をブラウザタブ内で動かします。イベントログにはユーザー、コンピューター、IP アドレスが記録されているので、パケットキャプチャと同じく、適当な変換サイトにアップロードすべきものではないからです。以下はツールのマニュアルではなく作業方法です。何を、どの順序で見るか、そしてフィールドが教えてくれることと、教えてくれないこと。

.evtx ファイルの中に実際にあるもの

.evtx ファイルは 4096 バイトのヘッダーの後に 64 KB の chunk が続いたものです。各 chunk には一連のイベントレコードが入り、各レコードはバイナリ XML（BinXML）として保存されます。オペレーティングシステムが埋める System ブロックと、EventData または UserData としてのプロバイダー固有のペイロードです。レコードを 1 つ開くと、文章ではなくフィールドが見つかります——EventID 4625、タイムスタンプ、チャネル、そして IpAddress、TargetUserName、LogonType のような名前付きの値。それらのフィールドこそが証拠です。そしてそれは、よそのマシン上のパーサーが正直に渡せるもののすべてでもあります。

ここに例外があり、それがこのガイドの残りすべてを形作ります。イベント ビューアーが表示する文——「アカウントがログオンできませんでした」——はファイルの中にありません。Windows はそれを、各プロバイダーに属し、ログを書いたマシン上に存在するメッセージ DLL から、表示時に描画します。データ値が %%14592 のように見えることがあるのはそのためです。それらは、ファイルが運んでこないメッセージテーブルへの参照なのです。別のマシン上のビューアーは、イベントが記録したすべてのフィールドと、保存されたとおりの生 XML を見せることができます——しかし、他人の .evtx について整ったメッセージ文を提示するツールは、自前の DLL コピーから再構成しているか、推測しているかのどちらかです。フィールドが先、文章は最後、それが正直な順序です。

数値を引用する前に知っておくべき構造上の事実がもう 1 つ。ファイルの chunk は互いに独立しています。ディスクイメージから切り出されたログや、死にかけのドライブからコピーされたログには、もう解析できない chunk が個別に含まれていることがよくあります。良いリーダーは、損傷した chunk をバイトオフセット付きで報告し、その前後すべてを読みます。この点についての沈黙——短くなったログを何も言わずに返すツール——こそが、調査からレコードが静かに消えていく仕組みです。

System ブロックから始める

すべてのレコードの System ブロックは同じ骨格を持ちます。Provider（どのコンポーネントが書いたか）、EventID（そのプロバイダーの番号体系で何が起きたか）、Level（1 の重大から 5 の詳細まで、レベルを持たないイベントは 0）、Channel（Security、System、Application、そして Microsoft-Windows-* 配下の何百もの運用ログ）、Computer、UTC タイムスタンプ、そして EventRecordID です。トリアージは、ログ全体をその骨格に沿って仕分けすることから始まります。レコードは何件か、期間はどれだけか、どのチャネルからか、どのイベント ID が支配的か。80% が 1 つのイベント ID で占められたセキュリティログは、たいていその 1 つについての物語です——判断を下すファイアウォール、ループで認証を繰り返すサービス——そして概要は、レコードを 1 件読む前にそれを教えてくれます。

レコードを参照するときは、System ブロックの EventRecordID を引用してください。切り出されたり、選択されたり、再エクスポートされたりしたファイルでは、レコードヘッダーがそれを作ったツールによって付け直されていることがありますが、System ブロックはマシンが最初に割り当てた ID を保持します——「この抜粋のレコード 7」と「元のログの EventRecordID 319457858」の違いは、誰かがあなたの発見を再現しようとする瞬間に重要になります。タイムスタンプにも同じ注意を払ってください。ファイルの中では常に UTC です。イベント ビューアーはそれをログを開くマシンの現地時刻に変換するため、同じレコードのスクリーンショット 2 枚が数時間ずれることがあるのです。レポートでは UTC を選び、その旨を明記してください。

元が取れる 4 つのイベント ID

1102——監査ログが消去された。セキュリティログは、自らが消去されたことを、新しいログの最初のイベントとして記録します。そのフィールドは、消去したユーザーを示します。インシデントにおいて 1102 は証拠であると同時に境界です。そのログでそれより前のものはすべて、あなたが持つファイルから消えており、消去そのものがレポートに 1 行書く価値のある事実です。ログの最も古いレコードが、関心のある期間内のタイムスタンプを持つ 1102 であれば、誰かが先行イベントの不在の上に理論を組み立てる前に、その旨を述べてください。

4624 と 4625——ログオンの成功と失敗。これらはアカウント調査の主力です。重要なフィールドは TargetUserName、IpAddress、そして何より LogonType です。3 はネットワークログオン、10 はリモート デスクトップ、2 は対話型コンソールログオン、7 はロック解除です。ブルートフォースのパターンは、1 つのアドレスから 1 つのアカウントに対する 4625 の集中として読め、その後に——重要なのはその瞬間です——4624 が続きます。4625 が 1 件だけならタイプミスです。信号なのはシーケンスの形であり、だからこそスクロールではなく、絞り込んで数えるのです。

4688——プロセスが作成された。監査ポリシーが記録していれば、各 4688 は新しいプロセス（NewProcessName）、それを起動したアカウント、そしてしばしば親プロセスを示します——「このマシンで何が、いつ動いたか」の原材料です。正直でいるための注意点が 2 つ。4688 は、送信元マシンで「プロセス作成の監査」が有効だった場合にのみ存在します（その不在は、何が動いたかについて何も証明しません）。そしてコマンドラインの取得はまた別の設定です。豊かな 4688 の痕跡は、当然の権利ではなく、贈り物として扱ってください。

この 4 つは開始セットであり、シラバスではありません——4624 の特殊ログオンの兄弟である 4672、明示的な資格情報によるログオン 4648、System ログのサービスインストール 7045 が、通常の次の目的地です。しかし初日の疑問のかなりの割合——ログは消去されたか、誰が入り、どこから入り、何を実行したか——は、1102、4624、4625、4688 だけで答えが得られます。

フィールドでは分からないこと

不在についての規律こそが、ログ作業の大部分です。ファイルは、送信元マシンが決して記録しなかったイベントを見せることはできません。何が存在するかは監査ポリシーが決め、既定構成のマシンは調査員が望むよりはるかに少なく記録します。メッセージ文も見せられません。前述のとおり、%% 参照は、あなたが持っていないマシン上の文字列へのポインターです。改ざんやその不在を、それだけで証明することもできません。レコード ID の欠落は、消去されたログだけでなく、正直に切り出されたファイルにも現れます。だからこそ、頼るべき信号は欠落ではなく、明示的な 1102 レコードなのです。

そしてログは 1 人の証人にすぎません。タイムスタンプは送信元マシンの時計から来ており、その時計が間違っていた可能性があります。アカウントはマシンが知っていた名前で現れます。ネットワークログオンの IP は、NAT や VPN を含め、マシンが見たアドレスです。フィールドはマシンが記録したそのものです——それ以下ではなく、そして規律とは、それ以上ではないことを忘れないことです。

5 分間のトリアージ手順

1 分目：EVTX ビューアー でファイルを開き、レコードの前に概要を読みます——総数、期間、チャネル、上位のイベント ID。ビューアーが読み取り不能として報告する chunk があれば、オフセットとともにメモします。その注意書きは、後からの脚注ではなく、最初からメモに属するものです。

2 分目：1102 を確認します。ログが消去されていたら、アプローチのすべてが変わり、消去の時刻とアカウントが最初の確かな事実になります。3 分目：4625 で絞り込み、形を見ます——アカウントごと、送信元アドレスごとの件数。集中の後に、同じアカウントについて同じアドレスからの 4624 があれば、それが発見です。正確なタイムスタンプをメモします。4 分目：疑わしい期間を固定したら、その期間内で 4688（リモートアクセスが問題なら 4624 のタイプ 10 も）で絞り込み、何が動き、誰がログオンしたかを列挙します。5 分目：絞り込んだレコードを JSON または CSV としてエクスポートし、数値が目の前にあるうちに段落を書きます——レコード ID、UTC 時刻、アカウント、アドレス。エクスポートが作業用紙であり、読み取り不能な chunk とメッセージ文の限界についての注意書きを添えた段落が成果物です。

この手順は調査を終わらせるものではありません。よそのバイナリファイルを、引用できる 5 つの事実と、根拠のある次の問いへと変えるものです。目の前にあるのがどんなマシンであっても——そしてそれこそが、トリアージというものの大部分なのです。

よくある質問