Sysinternals のツールを使用して Stuxnet の感染状況を分析する - 第 3 部 翻訳元: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 3 (英語) このブログ記事シリーズの第 1 部では、Autoruns、Process Explorer、および VMMap を使用して、Windows XP における Stuxnet の感染を統計的に分析しました。第 1 部の調査では、Stuxnet が複数のプロセスに影響を及ぼし、システム実行可能ファイルを実行しているように見せかけたウイルスに感染したプロセスを起動し、2 つのデバイス ドライバーをインストールして読み込んでいることが判明しました。このブログ記事シリーズの第 2 部では、ウイルス感染時にキャプチャした Process Monitor のログを解析し、感染中に Stuxnet が、上記以外に複数のプロセスを起動していることを特定しました。また、Stuxnet が C:\Windows\Inf ディレクトリに .PNF という拡張子のファイルを 4 つ配置していることも判明しました。このシリーズを締めくくる第 3 部では、Sysinternals のツールを使用して、PNF ファイルの目的を特定することに挑戦し、標準ユーザーの権限を管理者権限に昇格するために Windows 7 のゼロデイ脆弱性をどのように悪用したのかを見てみます (この脆弱性は修正済みです)。 .PNF ファイル .PNF ファイルに関する手掛かりを探すために、まず、ファイルのサイズを確認しました。サイズが小さければ、データが格納され、大きければコードが格納されていることが予想されます。問題となっている 4 つの .PNF ファイルは下記のとおりで、サイズ (バイト単位) はエクスプローラーで確認したものです。 MDMERIC3.PNF 90 MDMCPQ3.PNF 4,943 OEM7A.PNF 498,176 OEM6C.PNF 323,848 また、Sysinternals の Strings ユーティリティを使用して、印刷可能な文字をダンプしてみましたが、判読可能な文字はありませんでした。ファイルは圧縮または暗号化されていると思っていたので、これは驚くべき結果ではありませんでした。 Stuxnet で .PNF ファイルを参照している方法から、.PNF ファイルの目的について何か手掛かりを得られるかもしれないと考えました。PNF ファイルの用途の全容を解明するため、Process Monitor を使用して、ウイルスに感染した後にシステムを再起動したときのブート ログをキャプチャしました。[Options] (オプション) メニューの [Enable Boot Logging] (ブート ログを有効にする) をクリックしてブート ログを構成すると、次回起動時の早い段階から処理をキャプチャし、Process Monitor を実行するかシステムをシャットダウンするとキャプチャを停止します。 私がシステムに再度ログオンするときの処理を含むブート ログをキャプチャしたら、Process Monitor ウィンドウで、このブート ログを読み込み、ウイルス感染時にキャプチャしたログを別の Process Monitor ウィンドウで読み込みました。どちらのトレースでもフィルターをリセットし、システム プロセスの処理を除外する詳細なフィルターを削除し、Mdmeric3.pnf を含めるフィルターを追加して、1 つ目のファイルを対象としたすべての処理が表示されるようにしました。ウイルス感染時にキャプチャしたログには、ファイルの作成に関連するイベントのみが含まれており、ブート ログでは、このファイルは一切参照されていませんでした。Stuxnet では、ウイルス感染時とそれ以降のアクティブ化で、このファイルを使用していないことがわかりました。ファイルのサイズは 90 バイトと小さいので、これがデータ ファイルであることがわかりますが、ログに記録されている情報が少なく、このファイルの目的は特定できませんでした。実際、公開されている Stuxnet に関する調査報告では、このファイルがデータ ファイルであるということ以外は触れられていないため、このファイルには有益な目的がないのかもしれません。 今度は、Mdmcpq3.pnf についても同じようにフィルター処理を行いました。ウイルス感染時のログでは、Services.exe プロセスが、ファイルのコンテンツを 3 回書き込んでいることを確認しましたが、それ以降、ファイルへのアクセスはありませんでした。ブート ログでは、Services.exe が、起動直後に、このファイルを読み取っていることを確認しました。 Stuxnet が、感染時にファイルを書き込み、システム起動時のアクティブ化でファイルを読み取っているという事実とファイルのサイズが比較的小さいということから、このファイルは Stuxnet の構成データを保持していることが考えられます。また、これはウイルスの調査会社が公開した公式な調査報告に記されていることです。 3 つ目のファイル (Oem7a.pnf) は、4 つの中で一番大きなファイルです。第 2 部で感染時のログを分析したときには、感染時に悪意のある Lsass.exe がファイルを書き込むと、ウイルスに感染した Services.exe プロセスと同様に、別の悪意のある Lsass.exe のインスタンスがファイル全体を読み取っていることが判明しました。また、ブート ログの調査から、Services.exe の起動時に、このファイル全体を読み取っていることが判明しました。 特異な点は、システム DLL の Ntdll.dll が読み込まれるよりも前に、Services.exe で読み取り処理が実行されていることです。Ntdll.dll は、ユーザー モードのコードが実行される前に読み込まれます。つまり、その前に、この処理が行われているということは、カーネル モードのコードがからんでいると考えられます。スタックから、これらの処理が、Stuxnet ドライバーの 1 つである Mrxcls.sys によってカーネル モードで開始されたことが見て取れます。 また、Mrxcls.sys が PsCallImageNotifyRoutines カーネル関数によって呼び出されていることもわかります。つまり、Mrxcls.sys が PsSetLoadImageNotifyRoutine を呼び出して、DLL やデバイス ドライバーなどの実行可能イメージがメモリにマップされたときに Windows が、この関数を呼び出すようにしているということになります。ここでは、Services.exe イメージ ファイルをメモリに読み込んで、Services.exe プロセスを起動していることを Windows がドライバーに通知しています。Stuxnet では、コールバックに登録して、Services.exe の起動を監視するようにしています。皮肉にも、Process Monitor では、このコールバック機能を使用して、イメージの読み込みを監視しています。 この現象は、Mrxcls.sys が、ウイルス感染後にシステムを起動したときにユーザー モード プロセスの感染を引き起こす原動力になっていることを示唆します。また、ファイルのサイズは 498,176 バイト (487 KB) で、これは、第 1 部で確認した Stuxnet の処理が開始された仮想メモリの領域のサイズ (488 KB) とほぼ一致します。仮想メモリの領域には実際の DLL が格納されるので、Oem7a.pnf は、Stuxnet の主要な DLL がディスク上で暗号化されたものであるように思えます。これは、マルウェア対策の調査会社が立てた仮説です。 4 つ目のファイル (Oem6c.pnf) は、ブート ログで一切参照されていませんでした。感染時のログで唯一確認できたアクセスは、他のファイルを書き込んでいる最初の Lsass.exe プロセスによる書き込みだけでした。そのため、このファイルは、感染時に書き込まれたものですが、その後、読み取られることはないようです。この動作に関しては、いくつかの仮説を立てることができます。1 つは、このファイルが、私のテスト環境で再現できない特定の状況下で読み取られる可能性があるというものです。もう 1 つは、Stuxnet の開発者が後で収集して確認する目的で感染に関する情報を記録するログ ファイルであるというものです。この 2 つのログからは判断できませんが、マルウェア対策の調査会社では、これがログ ファイルだと結論付けています。 Windows 7 における権限の昇格 Stuxnet で実行される多くの処理 (Services.exe プロセスなどのシステム プロセスへの感染、デバイス ドライバーのインストールなど) には、管理者権限が必要です。管理者権限を持たないユーザーがログインしているときにシステムをウイルスに感染させることができなければ、Stuxnet の感染力は大幅に制限されていたでしょう。特に、多くのユーザーが標準のユーザー権限で実行する可能性の高い機密度の高いネットワークについてはなおさらです。標準ユーザー アカウントで実行中に管理者権限を獲得するために、Stuxnet では、2 つのゼロデイ脆弱性を悪用しました。 Windows XP と Windows 2000 では、Stuxnet は、特別に作成したキーボード レイアウト ファイルを読み込むことでトリガーできる Win32ｋ.sys のインデックス チェックに関するバグを悪用しました (このバグは、MS10-073 で修正済みです)。このバグにより、Stuxnet では、カーネル モードにコードを挿入して、カーネルの権限でコードを実行することができました。Windows Vista 以降では、Stuxnet は、スケジュールされたタスクのアクセス保護に関する欠陥を悪用して、管理者権限を獲得していました (このバグは、MS10-92 で修正済みです)。標準ユーザーは、スケジュールされたタスクを作成できますが、作成したタスクは、作成者である標準ユーザーと同じ権限で実行されるべきです。ですが、このバグが修正されるまで、スケジュールされたタスクが格納されるファイルには、標準ユーザーがファイルを変更できるアクセス許可が設定されていました。Stuxnet では、新しいタスクを作成し、タスクが管理者権限のあるシステム アカウントで実行される必要があることを指定するフラグを設定し、タスクを実行することで、この脆弱性を悪用していました。 Stuxnet が Windows 7 の脆弱性を悪用する状況を確認するため、テスト システムにインストールされている、このバグに関連する修正プログラムをアンインストールし、Process Monitor を使用して Stuxnet の感染状況を監視しました。ログをキャプチャしたら、第 2 部で使用したのと同じ手順でファイルとレジストリ キーを変更する処理以外を除外するフィルター (“Category Is Write then Include” (カテゴリが書き込みの場合に含める)) を設定し、関連のないイベントを機械的に除外しました。このフィルターを適用すると、Process Monitor ウィンドウは、次のような状態になりました。 最初の一連のイベントは、Stuxnet が、後で C:\Windows\Inf ディレクトリの PNF ファイルにコピーする一時ファイルの配置に関するものでした。その後に、タスク スケジューラー サービスに関連していると思われる Svchost.exe のイベントが続きました。Scvhost.exe プロセスでは、C:\Windows\System32\Tasks に新しいスケジュールされたタスクのファイルを作成し、関連するレジストリ値をいくつか設定しました。イベントのスタック トレースから、タスク スケジューラー サービスを実装いている DLL (Schedsvc.dll) が、この処理を実行していることがわかります。 そのいくつか後の処理では、エクスプローラーによって、新しいタスク ファイルにデータが書き込まれています。 標準ユーザー アカウントではシステム ファイルを処理できないようになっているので、この処理は可能ではないはずです。第 2 部で確認したように、<unknown> というエントリがあることから、これが Stuxnet による仕業であることがわかります。 ログに記録されているタスク ファイルと関連がある最後の一連の操作は、タスク スケジューラーによるファイルの削除です。つまり、Stuxnet では、タスクを変更してタスクを起動してから、タスクを削除していることがうかがえます。 実際にタスク スケジューラーがタスクを実行していることを確認するため、書き込みのフィルターを削除し、タスク ファイルに関連するもののみを表示する別のフィルターを適用しました。この操作により、Stuxnet がタスク ファイルに書き込んだ後に、Svchost.exe でファイルが読み取られていることを示すイベントが表示されます。 最終確認として、処理のスタックで、タスク スケジューラー サービスの SchRpcEnableTask 関数を確認しました (名前からわかるように、この関数はタスクのアクティブ化に関連しています)。 Sysinternals のツールによって明らかになった Stuxnet の情報 3 段階に分けて行った Stuxnet の調査の最終段階では、Process Monitor のブート ログ機能を使用して、Stuxnet が感染時にシステムに配置するさまざまなファイルの目的を解明する手掛かりを収集しました。また、Windows 7 のタスク スケジューラー サービスの欠陥を悪用して、管理者権限を獲得した方法も解明できました。 このブログ記事シリーズでは、Sysinternals のツールを使用すると、マルウェア感染時と感染後の動作の概要を特定し、ウイルスを駆除するためのガイドも提供できることを実証しました。また、比較的簡単に Stuxnet の主要動作 (プロセスの起動、ファイルの配置、デバイス ドライバーのインストール、タスク スケジューラーによる権限の昇格など) も明らかにしました。第 1 部の冒頭でお伝えしたとおり、このブログ記事シリーズで紹介した調査方法は、本格的なセキュリティ調査からはほど遠いものですが、Sysinternals のツールを使用することで、Stuxnet の動作の正確な概要と今後の分析のための構想は入手できたと思います。統計の分析だけでは、これだけのことを理解するのは不可能ですが、Sysinternals のツールを使用すれば、ここで紹介した情報を 30 分程度で入手できます。 トラブルシューティングやマルウェアの分析に Sysinternals のツールを使用する詳細な方法を知りたい場合は、2011 年 7 月 23 日 (土) に米国シアトルで開催する Zero Day Malware Cleaning with the Sysinternals Tools (Sysinternals のツールによるゼロデイ脆弱性を悪用したマルウェアの駆除) セミナーにご参加ください。 ページのトップへ

共有 ブログにコピー: ([Ctrl] + [C] でコピーしてください)