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

翻訳元: Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1 (英語)

状況を把握していたわけではありませんでしたが、2010 年 7 月 5 日に、あるプログラマーから送られてきたメールに添付され、ルートキットとして認識されたドライバー ファイル (Mrxnet.sys) を受け取ったときに初めて Stuxnet の存在を知りました。ルートキットの機能を実装したドライバーは珍しくありませんが、このドライバーのバージョン情報には、これがマイクロソフト製のドライバーであると表示され、合法的なコンピューター コンポーネントメーカーであるリアルテック セミコンダクターが発行した有効なデジタル署名がなされていたという点が珍しく、私の目に留まりました (Malware Protection Center ポータルを使用するのが、マイクロソフトにマルウェアを報告する公式な方法ですが、このプログラマーが、私にルートキット ドライバーを委ねてくれたことに感謝します)。

私は、このファイルをマイクロソフトのマルウェア対策チームとセキュリティ調査チームに転送しました。社内の調査により、Stuxnet の冒険物語が始まり、このドライバー ファイルが、これまでで最も悪名高いマルウェアの 1 つであることが判明しました。その後、数か月にわたる調査により、Stuxnet では、Windows のゼロデイ脆弱性を悪用して、勢力を拡大し、コンピューターの管理者権限を獲得していることが判明しました (この脆弱性は、発見後、すぐに修正されました)。また、リアルテックJMicron から盗用した証明書で署名されていることも判明しました。最も興味深かったのは、アナリストが原子力発電所の制御システムで使用されている独シーメンス社 SCADA (Supervisory Control and Data Acquisition) システムのプログラムを作り直すコードを発見したことです。また、多くのアナリストは、Stuxnet が、ウランを濃縮するというイランの核開発プログラムで使用されている制御システムを破壊する目的で開発されたのではないかと推測しています。また、イラン政府は、核施設を対象としたウイルスを検出したことを発表しています

その結果、Stuxnet は、最先端のマルウェアとして全世界で認知されるようになりました。コードに含まれる明らかな動機と手掛かりから、国家によるサイバー テロを対象としたマルウェアの最初の事例だと考えている調査会社もいます。皮肉にも、最近刊行された拙著サイバー サスペンス『Zero Day』では、インフラストラクチャ システムをターゲットにしたマルウェアの例をいくつか紹介しています。この書籍は数年前に執筆しましたが、当時は、少し大げさに書いのではないかと思っていました。Stuxnet は、この書籍で取り上げた例が発生し得るものだということを証明しました (『Zero Day』を読んでくださった方は、ぜひ Amazon.com でレビューを書いてください。

マルウェアと Sysinternals のツール

ここ数回のブログ記事 (英語) では、Sysinternals のツールを、マルウェアを駆除する方法を紹介すると同時に、マルウェアの調査会社が、マルウェアの分析に Sysinternals のツールを使用していることを紹介しました。本格的なマルウェアの解析は、厳格で退屈な作業で、マルウェアを分解して、その動作をリバース エンジニアリングする必要があります。ですが、Sysinternals の Process MonitorProcess Explorer などのシステム監視ツールを使用すると、マルウェアの動作の概要を把握できます。また、マルウェアの目的を把握する手掛かりを得て、マルウェアが実行される場所と詳しい調査が必要なコードを特定するのにも役立ちます。ここ数回のブログ記事で説明したように、これらのツールを使用して特定した情報は、マルウェア対策製品に含めるマルウェア駆除メカニズムを作成するガイドとして使用することもできます。

今回のブログ記事では、Sysinternals のツールを Stuxnet ウイルスに感染したときの初期対策として使用したときに得られた手掛かりを紹介することにしました (この記事を執筆するにあたって、被害を受けた核施設の制御システムは存在しないことをお伝えしておきます)。Windows XP システムがウイルスに感染したときの状態を紹介してから、管理者特権を持たないアカウントで Windows 7 を実行している場合に、ゼロデイ脆弱性を悪用して、管理者特権に権限を昇格するためにウイルスが使用する方法を紹介します。Stuxnet は、非常に巧妙なマルウェアであることをお忘れなく。Stuxnet では、複数の方法を使用して繁殖および通信を行い、ウイルスに感染したオペレーティング システムのバージョンとインストールされているソフトウェアに応じて、実行する操作を変えています。このブログ記事では、Stuxnet の表面を引っかいて、リバース エンジニアリングの専門知識がなくても、Sysinternals のツールを使用すると、マルウェアの感染状況を特定できる方法を示します。Stuxnet の動作の詳細な分析結果については、Symantec の「W32.Stuxnet の調査詳細」を参照してください。

Stuxnet の感染経路

Stuxnet は、2010 年の夏、主に USB メモリを経由して広まりました。そこで、私は、ウイルスがインストールされている USB メモリを使用して、調査を開始することにしました。このウイルスは 6 つのファイルで構成されています。Copy of Shortcut to.lnk という名前に基づいた名前が付いている 4 つのショートカット ファイルと、一般的な一時ファイルのように見える名前の付いた 2 つのファイルです。ショートカット ファイルは、すべて同じ目的を持っているため、この分析では、ショートカット ファイルは 1 つしか使用しませんでした。

この感染経路では、Stuxnet は、Windows のエクスプローラー シェル (Shell32.dll) のショートカットを解析するコードのゼロデイ脆弱性を悪用して、ユーザーによる操作を必要とすることなく実行を開始します。ユーザーが、エクスプローラーで Stuxnet のファイルを含むディレクトリを表示するだけで、ウイルスが実行されます。システムがウイルスに感染するようにするため、シェルの欠陥を修正するプログラム (KB2286198) をアンインストールしました。この修正プログラムは 2010 年 8 月に Windows Update によって配信されました。この修正プログラムが適用されていないシステムのエクスプローラーでショートカット ファイルがあるディレクトリを表示して、ショートカットのリンク先ファイルを検出してアイコンが表示されるようにすると、システムは Stuxnet に感染します。Stuxnet では、ルートキットの技法を使用して関連ファイルを非表示にして、これらのファイルがエクスプローラーに表示されないようにします。

Windows XP における Stuxnet

システムでは、ウイルスに感染する前に、Process MonitorProcess Explorer、および Autoruns を起動しました。Autoruns は、[Hide Microsoft and Windows Entries] (マイクロソフトと Windows のエントリを非表示にする) と [Verify Code Signatures] (コードの署名を検証する) のチェックを入れた状態で、スキャンを実行するように構成しました。

この設定により、マイクロソフトや Windows のデジタル署名がなされているエントリが一覧に表示されなくなります。その結果、Autoruns では、サードパーティのコードによって設定されたエントリのみが表示されるようになります (これには、他の発行元によって署名されたコードも含みます)。後で結果を比較して、Stuxnet によって追加されたエントリを特定することができるように、スキャン結果を保存しました。また、スペース キーを押して Process Explorer の表示を一時停止しました。このようにすると、システムがウイルスに感染した後に画面の表示を更新して、Stuxnet によって開始されたプロセスを確認できます (Process Explorer では、新しいプロセスは緑色で強調表示されます)。Process Monitor でレジストリ、ファイル システム、DLL のアクティビティをキャプチャしながら、USB メモリのルート ディレクトリにアクセスして、一時ファイルが突然消えるのを待って、システムを完全にウイルスに感染させるために 1 分待機してから、Process Monitor を停止し、Autoruns と Process Explorer の両方の画面を更新しました。

Autoruns の画面を更新したら、[File] (ファイル) メニューの [Compare] (比較) をクリックし、ウイルスに感染する前に保存したスキャンの結果と感染後のエントリの状態を比較しました。Autoruns では、Mrxnet.sys および Mrxcls.sys という 2 つの新しいデバイス ドライバーが登録されていることが検出されました。

Mrxnet.sys は、例のプログラマーが私に送信してくれたドライバーで、ファイルを非表示にするルートキットを実装しています。一方、Mrxcls.sys は、システムの起動時にマルウェアを起動する Stuxnet の 2 つ目のドライバー ファイルです。Stuxnet の開発者は、Mrxnet の偽装メカニズムを簡単に拡張して、Autoruns などのツールに対して、これらのファイルを非表示にすることは可能でした。ですが、有名なハードウェア会社の有効なデジタル署名があれば問題ないと判断したようです。つまり、Autoruns では、このウイルスを駆除するのに必要なすべての情報が提供されました。それは、この 2 つのドライバー ファイルを削除または無効にするという簡単なものでした。

Process Explorer では、緑色で強調表示されたエントリが 2 つあり、どちらもローカル セキュリティ機関サブシステム (Lsass.exe) のプロセスでした。

この 2 つのインスタンスの直下にあるピンクで強調表示された Lsass.exe のインスタンスに注目してください。通常、Windows XP のインストールには、システムの起動時に Winlogon プロセスが作成する Lsass.exe のインスタンスが 1 つだけ存在します (Windows Vista 以降では、Wininit が、このインスタンスを作成します)。このプロセス ツリーでは、(スクリーン ショットには含まれていませんが) この 2 つの新しい Lsass.exe のインスタンスが Services.exe (サービス コントロール マネージャー) によって作成されたことが判明しました。これは、Stuxnet がなんらかの方法で Services.exe プロセスにコードを埋め込んだことを示しています。

Process Explorer では、ファイルのデジタル署名を確認することもできます。これには、プロセスまたは DLL のプロパティ ダイアログ ボックスを表示して、[Verify] (検証) ボタンをクリックするか、[Options] (オプション) メニューの [Verify Image Signatures] (イメージの署名を検証する) をクリックします。これらの悪意のある Lsass.exe プロセスを確認すると、正規の Lsass.exe のイメージを実行していることが判明しました。

当然、この 2 つの Lsass.exe プロセスには、有害な目的がありますが、主要な実行可能ファイルとコマンド ラインからは手掛かりを得られませんでした。この 2 つのプロセスには、Services.exe の子プロセスとして実行されている以外にも、怪しい特徴があります。それは、Process Explorer の DLL ビューで確認できるように、この 2 つのプロセスで読み込まれる DLL の数が少ないことです。

本物の Lsass.exe プロセスでは、もっと多くの DLL が読み込まれます。

Service.exe、Lsass.exe、または Explorer.exe で読み込まれたモジュールの一覧にはマイクロソフト以外の DLL は表示されていないので、これらのプロセスでは挿入された実行可能コードがホストされている可能性が高いと思われます。コードの調査には高度なリバース エンジニアリングのスキルが必要になりますが、Sysinternals の VMMap ユーティリティを使用すると、このスキルを持った人が分析を行うのと同じように、これらのプロセスのどこに挿入コードがあるのかを特定できるかもしれません。VMMap は、特定のプロセスが使用するアドレス領域を視覚的に表示するプロセス メモリ分析ツールです。コードを実行するには、コードは実行のアクセス許可があるメモリ領域に格納されている必要があります。また、挿入コードは、データ用のメモリに格納される可能性が高く、多くの場合、実行することができないため、実行のアクセス許可がある DLL または実行可能ファイルでホストされていないメモリを探すことで挿入コードを特定できる場合があります。メモリ領域に書き込みのアクセス許可がある場合、さらに怪しいということになります。というのも、コードの挿入には書き込みのアクセス許可が必要で、ウイルスがコードの挿入後に、アクセス許可を削除することに対応していない可能性があるからです。正規の Lsass.exe には実行のアクセス許可が設定されたデータ領域はありませんが、新しく作成された 2 つの Lsass.exe プロセスには、同じ場所とサイズのアドレス領域に対して実行と書き込みのアクセス許可があります。

VMMap の [Strings] (文字列) ダイアログ ボックスには、選択した領域にある印刷可能な文字列が表示されます (このダイアログ ボックスには、[View] (表示) メニューからアクセスできます)。488 KB の領域の先頭には "This program cannot be run in DOS mode" という文字列があります。これは、Windows のすべての実行可能ファイルのヘッダーに格納されている標準的なメッセージです。これは、ウイルスが、コード スニペットでなく、DLL 自体を挿入することを示しています。

この領域には、解読不能な文字列はほとんど格納されていないので、圧縮されている可能性が高いと思われますが、この領域の末尾にある Windows API の文字列は DLL のインポート テーブルから取得されたものです。

Explorer.exe (最初にウイルスに感染したプロセス) と Services.exe (Lsass.exe プロセスを起動したプロセス) では、疑わしい DLL は読み込まれてませんが、他とは異なる実行可能データの領域があります。

2 つの Mrx ドライバーは、読み込まれたドライバーの一覧に表示されています (これは Process Explorer のシステム プロセスの DLL ビューで確認できます)。これらのプロセスが目立つのは、バージョン情報では製造元がマイクロソフトだとされているのに対して、リアルテックの署名が使用されているからです (証明書は失効していますが、テスト システムはインターネットに接続していないので、証明書失効リストのサーバーに問い合わせることができません)。

深く掘り下げる

Autoruns と Process Explorer を使用して調査できることは、すべて調査しました。この時点では、Stuxnet が、システムに 2 つのドライバー ファイルを配置し、これらをシステムの起動時に実行するように登録して、これらのファイルを実行していることを特定しました。また、Services.exe がウイルスに感染して、2 つの Lsass.exe プロセスを作成することも特定しました (これらのプロセスは、システムがシャットダウンされるまで実行されます)。ただし、コマンドラインやプロセスで読み込まれる DLL から、このプロセスの目的を特定することはできませんでした。ですが、VMMap では、挿入コードの手掛かりを得て、Autoruns では、ウイルスを駆除する簡単な方法が判明しました。また、Process Monitor でウイルス感染に関して追跡したイベントが約 30,000 件あります。このイベントから、感染時に何が行われていたのか、挿入コードがディスクのどこに格納されているのか、Stuxnet が起動時にコードをアクティブにする方法について詳しい情報を得ることができます。詳細については、第 2 部をお読みください。

ページのトップへ

共有

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