JPCERT/CC Eyes

Windows OSのログと言えば、イベントログのことを思い浮かべる人が多いかもしれません。マルウェア感染などのインシデント調査時は、Windows OSのイベントログを調査して、インシデントの解明につながる痕跡を探すことが一般的です。ただし、イベントログはWindows OS上の不審な挙動を検知するために設計されたものではないため、インシデント調査時に欲しい情報が見つかるとは限りません。そのため、監査ログを有効化したり、Sysmonをインストールしてより多くの情報を得るように工夫する必要があります。 Windows OSではイベントログ以外にも、OS内の不審な挙動を検知することができる、Event Tracing for Windows（ETW）と呼ばれる機能が存在します。これは、カーネルやプロセスが発生するイベントを管理するための仕組みで、アプリケーションのデバッグなどに用いられます。またETWは、EDR製品やウイルス対策ソフトの検知ロジックに活用されています。ETWは、イベントとしてOS内のさまざまな挙動をログとして記録できる機能がデフォルトで準備されているので、この機能を活用すれば、イベントログよりも多くの情報を得ることが可能になります。 今回は、ETWの仕組みとETWを活用したフォレンジック手法について解説します。

ETW Internals

ETWアーキテクチャー

ETWは、図1のようなコンポーネントから成り立っています[1]。プロバイダーであるアプリケーションなどからイベントが送信され、バッファーに保存されたのち、EDR製品などのコンシューマーがそれを受信します。

• プロバイダー：イベントを送信するアプリケーションやドライバー
• コンシューマー：イベントを受信するアプリケーション
• セッション：プロバイダーから送信されたイベントをバッファーに保存する中継の役割
• コントローラー：セッションを作成・開始・停止する（logmanコマンド[2]などがコントローラーの機能を持つ）

ETWセッションは、パフォーマンスモニターから確認することができます。また、パフォーマンスモニターは新規にセッションを作成し、イベント収集の準備をすることができます。図2のように1つのセッションに複数のプロバイダーを登録できます。

また、どのようなプロバイダーがWindows OS上に登録されているかは、以下のコマンド実行することで確認できます。デフォルトで1,000以上のプロバイダーが登録されています。

> logman query providers

これだけ多くのプロバイダーがデフォルトで使用可能であれば、これを活用してさまざまなログを収集できるのではないかと思っていただけたのではないでしょうか。特に、インシデント調査やマルウェアなどの不審な挙動を検知するという観点では、以下のプロバイダーが有効です。

• Microsoft-Windows-Threat-Intelligence：マルウェアが使用するプロセスインジェクションなどに関連する挙動を検知
• Microsoft-Windows-DNS-Client：名前解決関連のイベント
• Microsoft-Antimalware-AMFilter： Microsoft Defenderのウイルススキャンの結果
• Microsoft-Windows-Shell-Core：プロセス実行、停止に関するイベント
• Microsoft-Windows-Kernel-Process：プロセス関連のイベント
• Microsoft-Windows-Kernel-File：ファイル操作関連のイベント

ETWイベントフォーマット

ETWイベントを処理する方法（Stream Mode）には、主にETLファイルとして保存する方法とバッファーに保存してリアルタイムで受信する方法があります。どちらの方法でも、ETWイベントは同じフォーマットで保存されます。図3は、ETWイベントのフォーマットです。

先頭は、_WMI_BUFFER_HEADERから始まります[3]。このヘッダーには、バッファーのサイズやオフセット、イベント作成日時などが含まれます。次に来るヘッダーは、以降に含まれる内容によって異なります。ETLファイルの場合は、_SYSTEM_TRACE_HEADERと_TRACE_LOGFILE_HEADERが続きます。これらのヘッダーが含まれる場合は、以降にETWイベントは含まれず、ETLファイルの先頭であることを表しています。 ETWイベントが含まれる場合は、図4のようになります。

先頭が、_WMI_BUFFER_HEADERで始まるのは変わりありませんが、その次のヘッダーとして_EVENT_HEADERがあり、実際のイベントデータが続きます。

ETWイベントにはシグネチャがなく、上記のとおり各ヘッダーに含まれるタイプ情報によって以降のヘッダーも変わってくるため、手動でパースするのは困難です。Windows OSの場合は、tracerptコマンドがデフォルトでインストールされているため、ETLファイルを以下のようにEVTXファイルやCSVファイルなどに変換することが可能です。

> tracerpt test.etl -o test.evtx -of EVTX -lr

> tracerpt test.etl -o test.csv -of CSV

ETW構造体

ETWの設定情報は、先ほど紹介したパフォーマンスモニターやlogmanコマンド、レジストリ情報からある程度確認できます。ただし、これらから確認できる情報はすべてではなく、ETW構造体からもさまざまな情報を得ることができます。ただし、ETW構造体はユーザーモードでは取得できないためデバッガーなどを使ってカーネルモードから取得する必要があります。 ETWプロバイダーに関する構造体は、図5のように参照できます。

ETWプロバイダーの構造体は、プロセス内のハンドルのオブジェクトタイプがEtwRegistrationのオブジェクトからたどることができ、_ETW_GUID_ENTRYと_TRACE_ENABLE_INFOにGUIDなどの情報が含まれています。そのため、どのプロセスがどのETWプロバイダーを使用しているのかを確認することができます。
ETWコンシューマーに関する構造体は、図6のように参照できます。

ETWコンシューマーの構造体は、PsGetCurrentServerSiloGlobals関数から得られるデータからアクセスすることができます。_WMI_LOGGER_CONTEXTと_ETW_REALTIME_CONSUMERには、さまざまな情報が含まれており、バッファーのサイズや現在のバッファーの使用状況、ロストしたイベントの数なども調べることができます。

ETWイベントの復元

ETWイベントとETW構造体の関係

ETWイベントは、デフォルトでファイルとして保存する設定となっているものもありますが、バッファーからETWコンシューマーにリアルタイムで読み込まれるものも多く、自身で設定しなければファイルとしてシステム上に保存されるものは多くありません。ただし、バッファーにはETWイベントが保存されているため、そのデータを収集できればインシデントレスポンスなどに活用できる可能性があります。また、攻撃者によってETLファイルが削除されたとしても、バッファーにはETWイベントが保存されていることもあります。
先ほど紹介したとおり、ETWイベントフォーマットはシグネチャがなくファイルカービングによってディスクやメモリ上から復旧することは不可能です。そのため、ETW構造体から取り出す方法を調査しました。

調査の結果判明した、ETWイベントが保存される構造体のメンバーは以下のとおりです。

• GlobalList（_WMI_LOGGER_CONTEXT）
• BufferQueue（_WMI_LOGGER_CONTEXT）
• BatchedBufferList（_WMI_LOGGER_CONTEXT）
• CompressionTarget（_WMI_LOGGER_CONTEXT）
• UserBufferListHead（_ETW_REALTIME_CONSUMER）

GlobalListとBufferQueueは、LIST_ENTRYになっており、バッファーに保存されているETWイベントが双方向リンクリストとして図7のように連結しています。そして、すべてのバッファーのETWイベントが連結しているのがGlobalListです。

ETW構造体は公式の情報がなく、このように複数のメンバーがバッファーと関係している正確な理由は不明ですが、挙動から推測するとETW Stream Modeの設定が影響している可能性があります。図8に、ETW Stream Mode別の関連すると考えられるメンバーを記載します。ETLファイルに保存する設定になっている場合は、BufferQueueを使用し、Real time設定になっている場合は、UserBufferListHeadを使用しています。このようにメンバーによって使用方法は異なるものの、GlobalListにはすべてのETWイベントがリンクされているため、ETWイベントを復元する場合はGlobalListを参照するのがよいでしょう。

ETW Scanner for Volatility3

上記の調査結果をもとに、メモリイメージからETWイベントを復元するツールを作成しました。これは、メモリフォレンジックツールであるThe Volatility Framework（以下Volatilityと記載する）のPluginとして実現しています。本Pluginを使用すれば、ETWイベントの復元だけでなく、ETWプロバイダーの情報やETWコンシューマーの情報も確認することができます。図9は、Pluginの実行例です。

このPluginは、以下のGitHubレポジトリからダウンロードできます。ぜひご活用ください。

GitHub: JPCERTCC/etw-scan
https://github.com/JPCERTCC/etw-scan

復元したETWイベントのインシデント調査での活用

では、実際に復元したETWイベントをどのようにインシデント調査に活用するのか、事例をもとに紹介します。ETWイベントを復元する場合は、以下のようにオプション--dump（GlobalListのみ）または--alldump（すべてのメンバー）を指定します。環境によって復元できるETWイベントは異なりますが、図10のように多数のETWイベントをETLファイルとして復元することができます。

復元されたETLファイルを実際にパースして、重要な情報がないか確認していけばよいのですが、例えば、デフォルトで有効になっているETWセッションの中に、LwtNetLogというものがあります。このETWセッションでは、複数のネットワーク関連のETWプロバイダーが設定されており通信パケットやDNSアクセス、DHCPなどの情報が収集されています。復元されたETWイベントを確認すると図11のようにマルウェアの通信先情報が確認できます。なお、ETLファイルのパースにはtracefmt[4]を使用しています。tracefmtは、デフォルトではインストールされていないため、手動でインストールする必要があります。

さらに、EDR製品やウイルス対策ソフトがインストールされている場合は、これらのアプリケーションが収集しようとしていたETWイベントが復元できるかもしれません。どのETWプロバイダーからデータを収集しようとしているかはアプリケーションによって異なるため、それぞれ違いがあると思いますが、Microsoft-Windows-Threat-Intelligenceなどの有用なETWイベントが復元される可能性があります。

おわりに

Windows OSではデフォルトでETWを利用してさまざまな情報を収集することが可能です。今回は紹介しませんでしたが、ETWの情報収集能力に検知ロジックを融合した簡易EDRを作ってシステム監視することも出来ます。今後は、ETWをシステム監視やインシデントレスポンスにも活用してみてはいかがでしょうか。

インシデントレスポンスグループ 朝長 秀誠

参考情報

[1] Microsoft：イベント トレースについて
https://learn.microsoft.com/ja-jp/windows/win32/etw/about-event-tracing

[2] Microsoft：logman https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/logman

[3] Geoff Chappell, Software Analyst：Kernel-Mode Windows
https://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/index.htm

[4] Microsoft：Tracefmt
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/devtest/tracefmt