Skip to content

EVTX トリアージ: 1 時間と 1 台のホストがあるときに最初に読むもの

インシデント レスポンス中の Windows イベント ログ トリアージのための実務家の操作順序 — どのチャネルが重要か、どの Event ID が嘘をつくか、Sysmon がどこで重労働をするか。

著者 Florian Amette公開 2 {n} 分で読める

侵害されたと思うホストの EVTX バンドルを渡され、1 時間与えられたら、エレガンスのための時間はありません。1 つも記録を読む前に信頼できるようになるまで、十分な回数機能した操作順序のための時間しかありません。

これが私のです。完全なリファレンスではなく、すべてのケースに適切でもありません — じっくり燃える内部者調査には全く異なる姿勢が必要です — が、標準的な「これは popped か、どうやって」という質問には、これを走らせます。

実際に時間を返してくれるチャネル

デフォルトの Windows インストールは 300 以上の EVTX チャネルを出荷します。実際に見るのはおそらく 7 つです。一貫して重要なもの:

  • Security.evtx — ログオン、特権利用、アカウント変更。すべての対話的インシデントの最初の停留所。
  • Microsoft-Windows-Sysmon%4Operational.evtxSysmon が展開されていれば (そしてあるべきだと懇願、嘆願、脅迫すべき)、ここに実信号が住んでいます。コマンドライン付きのプロセス作成、ファイル作成、ネットワーク接続、DNS、image load。Security.evtx が指し示すが言わないすべて。
  • System.evtx — サービス インストール、ドライバ ロード、ブート イベント、時刻変更。ラテラル ムーブメントがサービス インストールを残す唯一の場所であることが多い。
  • Application.evtx — 通常ノイズ、ただし Office マクロ エラー、.NET 例外、一部の EDR サイド チャネルがここに浮上。
  • Microsoft-Windows-PowerShell%4Operational.evtx — モジュール ロギングとパイプライン イベント、有効なら。4104 script block ログは、ロギングが on だったと仮定するなら、あらゆる悪意のある PowerShell の各行が見つかる場所。両方アクティブなとき、Sysmon に次いで 2 番目に重要なチャネル。
  • Microsoft-Windows-TaskScheduler%4Operational.evtx — スケジュールド タスク作成、削除、実行。短く読めて、すぐに返ってくる。
  • Microsoft-Windows-WMI-Activity%4Operational.evtx — WMI サブスクリプションとコンシューマー登録。読むのは安価。特定の永続化パターンを捕える。

ホストに Defender があれば、Microsoft-Windows-Windows Defender%4Operational.evtx も取得。1116 / 1117 ファミリは、重要だったファイルへの唯一の同時代の言及であることがあります。

それ以外はすべて 2 回目のパスに残せます。

最初に開くのは Security ログではない

デフォルトの反射は Security.evtx4624 で grep することです。最初のパスではそれをやめて、あなたもおそらくそうすべきです。忙しいサーバーの Security ログは時間あたり数千の正当なログオンをログします。質問を組み立てる前にノイズに溺れます。

存在するときに最初に開くのは、疑われるウィンドウ内の EventID=1 (プロセス作成) にフィルタした Sysmon%4Operational.evtx です。Sysmon は親プロセス、実際に呼び出されたコマンドライン、ユーザー、整合性レベル、親と子の両方のハッシュを与えます。それは画面から物語を読むのに十分です。

Sysmon がない場合 (落胆するほど多くの企業 Windows 資産でまだない)、次の手は、コマンドライン監査有効の4688 にフィルタした Security.evtx です。コマンドラインが監査されていなければ、剥き出しのプログラム名しか得られず、ほぼ無用です — その時点で AmCache、Prefetch、USN journal にジャンプして何が動いたかを再構築します。

声に出して言う価値のある系: Sysmon なし、4688 コマンドラインなしの EVTX 調査は、ほとんど推測ゲームです。インシデントに先立ってこれを読んでいるなら、それをまず修正してください。

調べなくてよくなる Event ID

最終的には暗記で学びます。短い版、IR で各々について私が考える方法とともに:

  • 4624 — 成功ログオン。LogonType をまず読む: 3 はネットワーク (ファイル共有、リモート ツール)、10 は RDP / Terminal Services、2 は対話的、9 は明示的資格情報での runas5 はサービス。LogonType はイベント自体よりも意味を運びます。
  • 4625 — 失敗ログオン。バーストはスプレー攻撃、多数アカウントにわたる孤立したものは credential stuffing。
  • 4634 / 4647 — ログオフとユーザー開始ログオフ。セッションを閉じるブラケットに有用。
  • 4648 — 明示的資格情報でのログオン。ラテラル ムーブメント帰属に実際に欲しいもの: アカウント A がアカウント B の cred を使ってプロセスを開始するか、どこかに接続するとき、これがレコードです。多くの防御者は活用していません。
  • 4672 — ログオン時に割り当てられた特殊特権。「このアカウントはちょうど管理者になった」行。続く 4624 とペアに。
  • 4688 — プロセス作成。コマンドライン監査が有効な場合のみ有用 (Group Policy: Audit Process CreationInclude command line in process creation events)。なしではプログラム名が得られます。
  • 4697 — サービス インストール。PsExec、Impacket smbexec 系ツーリングによるラテラル ムーブメントはここに住んでいます。
  • 4720 / 4732 / 4738 — アカウント作成、グループ メンバーシップ変更、アカウント変更。永続化はこれらが大好き。
  • 1102 — Security ログがクリアされました。これを見たら、その時点までの Security ログの残りは疑わしいか欠如している。イベントが存在すること自体が煙の銃。
  • 5140 / 5145 — ネットワーク共有アクセス。後者はファイル名をログ。on なら、SMB 経由のラテラル ムーブメントが詳細に監査可能。
  • 7045 — サービス インストール (System ログ)。4697 のミラーだが System チャネルから。
  • Sysmon 1 — フル コンテキスト付きプロセス作成。Sysmon が on なら DFIR で最も有用な単一の Event ID。
  • Sysmon 3 — ネットワーク接続。Defender が見逃した送信 C2 を捕える。
  • Sysmon 10 — プロセス アクセス。lsass.exe からの credential dumping を捕えるもの。
  • Sysmon 11 — ファイル作成。実行に至らなかったドロッパー活動を捕える。
  • PowerShell 4104 — script block logging。難読化されたものを含むすべての PowerShell コマンドの完全テキストを記録 (多くの場合デコード後の難読化解除)。

印刷したチート シートを机の隣に置いています、あなたもそうすべきです。栄光ではなく、実際の分を節約します。

あなたに嘘をつく、または誤読しやすいイベント

\\NT AUTHORITY\ANONYMOUS LOGON からの 4624 Type 3 は「攻撃者が中にいる」ではありません。通常は構成ミスの共有列挙、脆弱性スキャナー、または半ダースの Windows 内部メカニズムの 1 つです。エスカレートする前に検証してください。

1 つのサービス アカウントに対する分あたり 1 回の 4625 は、ほぼ常にどこかにキャッシュされた古い資格情報です。ブルートフォースと呼ぶ前にソース ワークステーション フィールドを見てください。

Security.evtx のタイムスタンプは、デフォルトで一部のツールでは生成したホストのローカル時刻、他のものでは UTC です。新しいツールでバンドルをロードしたら、既知の外部イベント (チケット更新、VPN セッション) と相関できるログオンを見つけ、オフセットを確認してください。誰かが確認を忘れて報告書全体が 4 時間ずれていたのを見たことがあります。

イベント ログ クリア (1102) は通常騒がしいですが、選択的レコード削除は別の獣です。wevtutil cl はチャネル全体をクリアし、これは検知可能です。phant0mInvoke-Phant0m のようなツールは代わりにイベント サービスのスレッドを停止し、クリア イベントを残さず可視ギャップを作ります。1102 だけでなくギャップを探してください。

転送イベント (Microsoft-Windows-EventLog%4ForwardedEvents) は発信ホストの RecordID と元のタイムスタンプを保持します。インシデントを生き残った WEC サブスクライバーがあれば、それらのコピーは時に唯一残った完全な記録です。

Security ログが 1100 (イベント サービス シャットダウン) の後に説明できないギャップを示しているなら、証拠をクリアする試みの中でもクリーンなものを見ています。registry hivesMaster File Table、Prefetch と相互検証してください。

記録が欠落しているときのカービングと復旧

ライブ ファイルがクリアまたはロールオーバーされたとき、EVTX レコードは未割り当てディスクと pagefile.sys からカービングできます。レコード ヘッダー (2a 2a 00 00 マジック) は、シグネチャ カービングが妥当に機能するほど特徴的です。Yamato Security の hayabusaevtx_dump は両方ともパッチが当たったレコード ストリームを持つ不正形式ファイルを扱います。

ログが改ざんされたと疑われるホストを扱っているなら、RAM dump からの EVTX レコードの復旧も試してください。イベント ログ サービスは最近のレコードをメモリにキャッシュします。インシデント近くで取られたスナップショットには、ディスクに到達しなかったレコードが含まれることがあります。

ヒットからどこへ

単一イベントがケースを閉じることはまずありません。私が手を伸ばす軸点を順番に:

  • 疑わしい 4624 → 対応する 4672、先行する 4625 失敗、そしてそのトークンで後続に何が作成されたか (一致する LogonId の Sysmon 1) を探す。
  • 7045 または 4697 サービス インストール → フォローオン タスクのため Microsoft-Windows-TaskScheduler%4Operational.evtx を確認、バイナリ パスのため registryHKLM\SYSTEM\CurrentControlSet\Services\ を確認。
  • lsass.exe に対する Sysmon 10 → 要求プロセスのプロセス ツリー、作業ディレクトリのファイル ドロップ、非企業宛先へのネットワーク接続。
  • 難読化された内容を持つ PowerShell 4104 → サンドボックスでデコード、それから他のホストに着地する同じペイロードを探す (ほとんどのエンタープライズ アクターは再利用する)。

ブラウザでの EVTX 読み取り

本サイトのパーサー は EVTX を完全にクライアント サイドで読みます: ファイルをドロップすると、チャネル、RecordID、EventID、時刻、コンピューター、レンダリングされた XML を持つソート可能、フィルタ可能なテーブルが得られます。アップロードなし、これは規制環境からの EVTX にはほぼ常にベンダー境界を越えさせたくない PII が含まれるため重要です。

参考資料

  • JPCERT/CC の「Detecting Lateral Movement through Tracking Event Logs」 — ラテラル ムーブメント イベント相関に関する最も有用な単一文書。ゆっくり読む価値あり。
  • Eric Zimmerman の EvtxECmd — 正準フィールド マッピング出力を持つオフライン パーサー。
  • Microsoft Threat Intelligence (旧 SwiftOnSecurity) がベースラインとしてメンテナンスする Sysmon 設定: sysmon-modular。これから始めてください、ゼロから書かないでください。

上記すべての皮肉な版: Sysmon とコマンドライン監査があれば、EVTX は侵入を再構築するのに必要なものの 80% を与えます。なしでは、イベントそのものではなく、イベントのシルエットに対してフォレンジックをしています。

関連記事

実際の敵対者ツールが Windows 環境でホスト間を移動する仕組みと、PsExec、Impacket、WMIExec を捕える Security.evtx の正確なイベント ID の組み合わせ。
攻撃者が Windows イベント ログをどうクリアするか、ディスク上と転送チャネルにどんな証拠が残るか、そして wevtutil cl と Invoke-Phant0m のようなスレッド停止ツールの違い。
Sysmonに関する意見: IRで本当に重要なイベントID、なぜolafhartong/sysmon-modularが正しいベースラインなのか、そして実際の攻撃に対してあなたを盲目にする設定ミス。