Sysinternals のツールを使用して Stuxnet の感染状況を分析する - 第 2 部

第 1 部では、Sysinternals のツールを使用して悪名高い Stuxnet ウイルスの感染例について調査を始めました。ウイルスに感染したシステムの調査には、Process Explorer、Autoruns、および VMMap を使用しました。Autoruns では、Stuxnet の主要コンポーネントである 2 つのデバイス ドライバー (Mrxcls.sys と Mrxnet.sys) を特定しました。また、これらのドライバーを無効にして、システムを再起動すれば、Stuxnet が無効になる (再感染を予防できる) こともわかりました。Process Explorer と VMMap では、Stuxnet が、さまざまなシステム プロセスにコードを挿入し、ウイルスの追加ホストとして機能するシステム実行可能ファイルを実行するプロセスを作成することを特定しました。第 1 部のブログ記事では、スナップショット ベースで感染の状況について確認できることは、確認しました。第 2 部では、Stuxnet ウイルスに感染したシステムに与える影響と、ウイルスの動作を調査するために、ウイルス感染時にキャプチャした Process Monitor のログを解析して調査を進めます (これらのブログ記事、サイバー セキュリティ、および Tom Clancy と Michael Crichton の作品がお好きな場合は、拙著『Zero Day』をぜひチェックしてください)。

イベントをフィルター処理して関連イベントを特定する

Process Monitor では、感染状況を監視している間に、約 30,000 件のイベントをキャプチャしました。ですが、これは個別に調査して手掛かりを探すには、数が多すぎます。このイベントの大半は、エクスプローラーで新しいフォルダーに移動するためにバックグラウンドで実行される Windows の処理と操作で、ウイルス感染とは直接関係ありません。Process Monitor の既定の設定では、詳細なイベント (ページング ファイル、IRP 内部関数、システム プロセス、NTFS メタデータ操作) は除外されます。ですが、ステータス バーに示されているように、Process Monitor では、依然として 10,000 件以上のイベントが表示されています。

特定すべきものが定かではないときに Process Monitor を効率的に使うためのポイントは、表示されるデータを管理できる量まで絞り込むことです。これにはフィルターが便利です。Process Monitor には、このようなシナリオに対応したフィルターが用意されています。つまり、ファイルやレジストリ キーに変更を加えたイベントのみを表示するフィルターです。このフィルターは、[Process Monitor Filter] (Process Monitor フィルター) ダイアログ ボックスで “Category is Write then Include” (カテゴリが書き込みの場合に含める) という設定を使用して構成できます。

多くの場合、システム プロセスで生成されたイベントは、トラブルシューティングの対象になりませんが、Stuxnet にカーネル モードのコンポーネントがあることを把握しているので、万全を期すために、システム プロセスのコンテキストで実行されたイベントを含める必要がありました (システム プロセスでは、一部のデバイス ドライバーがシステム スレッドを実行します)。既定のフィルターは、[Filter] (フィルター) メニューの [Enable Advanced Output] (詳細な出力を有効にする) をクリックして無効にできますが、ページ ファイルと NTFS メタデータの操作を除外する他の既定のフィルターを削除したくなかったので、システム プロセスを除外するフィルター (上記のフィルターの上から 2 つ目) のみ削除しました。その結果、イベントの件数は 600 に減りました。

今度は、ウイルス感染と確実に関連がないイベントを除外する必要がありました。関連のないイベントを識別するには、一般的な Windows の処理に精通していなければならないので、経験が必要になります。たとえば、この 600 件のうち数百件は、エクスプローラーが HKCU\Software\Microsoft\Windows\ShellNoRoam\BagsMRU レジストリ キーの値を参照するときに行われる処理に関するものです。

このキーは、エクスプローラーがウィンドウの状態を格納する場所なので、これらのイベントは除外できます。これには、Process Monitor のクイック フィルター機能を使用しました。いずれかのレジストリ パスを右クリックして、クイック フィルターのコンテキスト メニューを表示し、[Exclude filter] (フィルターを除外する) をクリックしました。

このキーのサブキーや値を参照しているイベントも除外したいので、新しく作成したフィルターを開いてダブルクリックして、フィルター エディターを起動し、"is" (の場合) を "begins with" (で始まる) に変更しました。

このフィルターにより、イベント件数は 450 に減りました。だいぶ管理しやすい数に近づきましたが、まだ除外できるイベントがありました。それは、システム プロセスによる、レジストリ ハイブのファイルの読み取りと書き込みに関するイベントです。レジストリ ハイブのファイルにはレジストリ データが格納されていますが、ここで関心があるのは、レジストリ ハイブのファイルに対する読み取りと書き込みの処理ではなく、レジストリの操作自体です。このイベントを除外すると、イベント件数は 350 に減りました。ログの調査を続けて、他の関連のないイベントを除外するフィルターをいくつか追加し、すべてのバックグラウンド処理をフィルターで除外すると、[Process Monitor Filter] (Process Monitor フィルター) ダイアログ ボックスは、次のような状態になりました (私が追加した一部のフィルターはスクリーン ショットには含まれていません)。

この時点で、イベントの件数は 133 まで減りました。ざっと確認したところ、すべてのイベントは Stuxnet に関連しているようでした。これで、イベントを解読する準備ができました。

Stuxnet によるシステムの変更

この一覧の最初にあるイベントでは、Stuxnet がエクスプローラーのコンテキストで動作して、Stuxnet が作成した一時ファイルの 1 つの先頭の 4 KB を上書きしたことがわかります。

この書き込みが Explorer.exe ではなく Stuxnet によって行われたことを確認するため、このイベントをダブルクリックして、イベントのプロパティ ダイアログ ボックスを表示し、[Stack] (スタック) タブをクリックしました。NtWriteFile API の 1 つ上のスタック フレームのモジュール名には "<unknown>" と表示されています。これは、プロセスに読み込まれている DLL にスタック アドレスが存在しないことを示しています。

標準の呼び出し規則に従っていない場合、サードパーティが記述したコードのスタックにも <unknown> というエントリが表示されることがあります。これは、Process Monitor が使用しているスタック追跡 API で採用しているアルゴリズムの動作を妨げるからです。ただし、VMMap を使用してエクスプローラーのアドレス領域を確認すると、書き込みと実行の両方のアクセス許可が設定された不明なスタック アドレス 0x2FA24D5 を含むデータ領域がありました。これは、ウイルスによって挿入されたコードであること示す動かぬ証拠です。

Explorer.exe の処理の後には、アカウントの一時ディレクトリに 4 つのファイル (~Dfa.tmp、~Dfb.tmp、~Dfc.tmp、および~Dfd.tmp) を作成する Lsass.exe プロセスの処理が続いていました。多くの Windows コンポーネントでは一時ファイルを作成するので、これらのファイルが Stuxnet に関連するもので、標準的な Windows の処理に関連していないことを検証する必要がありました。この 4 つの一時ファイルに Stuxnet が関連していることを示す強力な手掛かりとなったのは、300 という Lsass.exe プロセスのプロセス ID (PID) がシステムの正規の Lsass.exe プロセスの PID と一致しないという事実です (これは第 1 部で特定した情報です)。実際、この PID は、ウイルスに感染した後に実行されていた 3 つの Lsass.exe のいずれとも一致しなかったので、Stuxnet によって起動された別の悪意のある Lsass.exe であることは間違いありませんでした。

この Lsass.exe が他のプロセスとどのように関連しているのかを確認するため、Ctrl + T キーを押して、Process Monitor のプロセス ツリー ビュー ダイアログ ボックスを表示しました (このダイアログ ボックスは、[Tools] (ツール) メニューからもアクセスできます)。プロセス ツリーから、3 つの Lsass.exe プロセス (PID が 300 のものも含む) は、ウイルス感染時に実行されていたことが判明しました。また、アイコンが灰色表示になっていることから、これらのプロセスは Process Monitor によるキャプチャが停止する前に終了したことがわかります。

この段階で、これが悪意のある Lsass.exe プロセスであることは間違いありませんでしたが、これらの一時ファイルが、Lsass.exe の定型処理によって作成されたものではないことを検証する必要がありました。これらのファイルのスタックを確認すると、Explorer.exe による処理のスタックと同じようにモジュール名の列に <unknown> というエントリが表示されていました。

後続のエントリは、さらに興味深いものでした。というのも、Lsass.exe が 2 つある Stuxnet ドライバーのうちの 1 つ (MRxCls.sys) を C:\Windows\System32\Drivers に配置して、対応するレジストリ キーを作成していたからです。

WriteFile の処理をダブルクリックして、スタックを確認すると、CopyFileEx API への呼び出しがあり、Stuxnet がドライバーのコンテンツを別のファイルからコピーしたことが判明しました。

コピー元のファイルを特定するため、[Process Monitor Filter] (Process Monitor フィルター) ダイアログ ボックスでカテゴリが書き込みのエントリを除外するフィルターのチェックを外して、このフィルターを一時的に無効にしました。

その結果、以前に作成された ~DFD.tmp ファイルが参照されていることが明らかになったので、このファイルにドライバーのコピーが含まれていることを確信しました。

そのいくつか後の処理では、システム プロセスが Mrxcls.sys を読み込んで、ドライバーをアクティブにしました。

次に、Stuxnet では、2 つ目のドライバー (Mrxnet.sys) の準備をして読み込みました。まず、このドライバーを ~DFE.tmp に書き込み、このファイルを目的の Mrxnet.sys ファイルにコピーして、Mrxnet.sys のレジストリ値を定義したことがログの内容から判明しました。

そのいくつか後の処理では、システム プロセスが Mrxcls.sys を読み込んだのと同じように、Mrxnet.sys を読み込みました。

最後に、Stuxnet では、C:\Windows\Inf ディレクトリに 4 つのファイル (Oem7a.pnf、Mdmeric3.pnf、Mdmcpq3.pnf、および Oem6c.pnf) を作成しました。ファイルの作成は、CreateFile の処理のみを含むフィルターを適用したときに明らかになりました。

PNF ファイルは INF ファイルをプリコンパイルしたもので、INF ファイルは、デバイス ドライバーのインストール情報を含むファイルです。C:\Windows\Inf ディレクトリには、PNF ファイルと INF ファイルのキャッシュが格納されており、通常、INF ファイルには対応する PNF ファイルがあります。このディレクトリにある他の PNF ファイルとは異なり、Stuxnet の PNF ファイルと名前が一致する INF ファイルは存在しませんが、Stuxnet の PNF ファイルの名前は、このディレクトリにある他のファイルの名前にうまく溶け込んでいます。ドライバー ファイルを書き込む処理と同じように、これらの処理のスタックには CopyFileEx への参照があります。カテゴリが書き込みのエントリを除外するフィルターを無効にすると、これらのソース ファイルが Stuxnet によって作成された一時ファイルであることが判明しました。次の画像では、Stuxnet が ~Dfa.dmp を Oem7a.pnf にコピーしていることがわかります。

ウイルスに感染した Services.exe プロセスによる Mdmcpq3.pnf への数件の書き込みを除き、これらのファイルへのすべての書き込みは、Lsass.exe プロセスによって実行されました。

コピーが完了すると、Stuxnet では、そのディレクトリに存在する他の PNF ファイルのタイムスタンプに合わせて、ファイルのタイムスタンプを設定して、ファイルをなじませます。このテストを行ったシステムでは、変更後のタイムスタンプは 2009 年 11 月 4 日でした。次の画像に示すとおり SetBasicInformationFile で Oem7a.pnf のタイムスタンプが設定されています。

タイムスタンプを設定すると、Stuxnet では、作成した一時ファイルを閉じるときに、これらのファイルを削除するようマークします (他の一時ファイルを削除する操作は、ログの他の部分に含まれています)。

Stuxnet が、一時ファイルを書き込んで、そのコピーを作成するのは奇妙な動作だと思うかもしれませんが、Stuxnet の調査報告の概要では、一時ファイルの存在についてすら触れられていないので、それほど重要なことではないように思われます。

ログに含まれていて説明できない処理は、HKLM\System\CurrentControlSet\Services\Network\FailoverConfig という名前のレジストリ値を削除しようとしていることです (これについては、公開されている Stuxnet の調査報告のいずれでも触れられていません)。

このレジストリ値はおろか、参照されている Network キーでさえ、Windows や私が知っているコンポーネントでは使用されていません。C:\Windows ディレクトリにある実行可能ファイルを検索してみましたが、手掛かりは得られませんでした。おそらく、Stuxnet では、特定の状況下で、この値をマーカーとして作成し、このコードで、その値を自動的に削除するのではないかと思います。

次のステップ

第 1 部と第 2 部で Sysinternals のツールを使用して Stuxnet ウイルスの感染について行った分析から、Stuxnet に感染したシステムへの影響と感染後にシステムを起動したときにウイルスを再アクティブ化する方法を特定し、感染したシステムで Stuxnet を無効にして駆除する方法を解明しました。第 3 部では、Stuxnet が作成した 4 つの PNF ファイルをどのように使用するのかを調査して、各ファイルの目的を特定します。また、Stuxnet に感染した Windows 7 システムのログも分析し、標準ユーザーの権限で実行しているときに管理者権限を獲得するために Windows 7 のゼロデイ脆弱性をどのように悪用したのかを解明します (この脆弱性は、修正済みです)。第 3 部もお楽しみに。