Endpoint Protection

 View Only

W32.Stuxnet - ネットワーク上の動作 

Nov 16, 2010 05:51 AM

Stuxnet に関する以前のブログ記事では、インストール手口の詳細と、この脅威に関連する多くのファイルについてご報告しました。今回は W32.Stuxnet のネットワーク通信とコマンド & コントロール機能を取り上げます。Stuxnet が実行する処理のうち一部は自動化されていますが、なかには Stuxnet がコマンド & コントロールサーバーに接続し、特定の命令を受け取ってから実行される処理もあります。今回説明するのは、この側面についてです。

自身をインストールしてファイルを投下した Stuxnet は、そのシステムに関する情報を収集した後、ポート 80 でコマンド & コントロールサーバーに接続し、侵入先のコンピュータに関する基本的な情報の一部を攻撃者に送信します。現在までに確認できたサンプルをすべて解析し、そこからコマンド & コントロールサーバーに関する情報を抽出したところ、参照されているコマンド & コントロールサーバーは今のところ次の 2 つだけであることがわかりました。

www[.]mypremierfutbol[.]com
www[.]todaysfutbol[.]com

内部に IP アドレスがハードコードされているサンプルも確認されましたが、以前のブログで示した URL も、ハードコードされた同じ IP アドレスに解決されていました。この 2 つの URL は、以前はマレーシアとデンマークにあるサーバーにリンクしていましたが、侵入されたコンピュータを攻撃者が制御することのないように、その後はリダイレクトされています。Stuxnet には、新しいコマンド & コントロールサーバーの URL で自身を更新する機能がありますが、設定が更新されたファイルはまだ確認されていません。設定を更新するには、%Windir%\inf\mdmcpq3.PNF という名前のファイルを読み込む必要があります。このファイルから更新された設定情報がメインの dll に書き込まれ、その情報が正しいことを確認するために dll のチェックサムが再計算されます。

最初の接続は、侵入先のコンピュータからインターネットアクセスが可能かどうかを確認する目的で行われます。そのために、著名ないくつかの安全なサイトのアドレスが設定ファイルにエンコードされていますが、その URL が使われたことは確認されていません。代わりに、この脅威は上に示した悪質な URL のひとつに接続してインターネット接続を確認します。

インターネット接続を確認すると、脅威は侵入先のコンピュータに関する情報が含まれている http 要求をサーバーに送信します。この情報は、次の URL に対する要求によって送信されます。
Hxxp://[コマンド & コントロールサーバーのアドレス]/index.php?data=[DATA]

DATA の部分は、収集されたシステム情報を表しています。データは平文ではなく、31 バイトキーを使って XOR で暗号化されてから送信されます。データセクションには、このデータを記述するフィールドもいくつか含まれています。コマンド & コントロールサーバーから返信される応答も XOR で暗号化されていますが、このとき使われるのは別の 31 バイトキーです。侵入を受けたコンピュータでは、どちらのキーも悪質な .dll ファイルに含まれているので、これらのキーを使えばコマンド & コントロールサーバーとの間で送受信されるトラフィックを復号化できることになります。

感染したコンピュータからコマンド & コントロールサーバーに送信される最初の暗号化データには、システムに関する以下の情報と、少量の追加データが含まれています。

  • Windows のバージョン情報
  • コンピュータ名
  • ネットワークグループ名
  • SCADA ソフトウェアがインストールされているかどうかを示すフラグ
  • すべてのネットワークインターフェースの IP アドレス

この情報を受信すると、コマンド & コントロールサーバーは 2 種類の応答を行います。1 つ目の応答は、この脅威のコード内にすでに存在するプロシージャのいずれかを実行するよう Stuxnet に指示するものです。実際には、この応答からのデータはメインの .dll ファイルに記述されているさまざまな RPC ルーチンに転送されます。2 つ目の応答は、追加の .dll ファイルをクライアントに送信したうえで、その .dll ファイルをロードし、ダウンロードした .dll ファイルの内部から序数 1 を呼び出すようにクライアントに指示します。





1 つ目の応答は、ローカルコンピュータに転送される RPC のラッパーとして機能します。クライアント側で実装される RPC 呼び出しは、次の処理を実行できます。

  • ファイルを読み込む
  • ファイルに書き込む
  • ファイルを削除する
  • プロセスを作成する
  • .dll を lsass.exe に挿入する
  • 追加の .dll ファイルをロードしエクスポート 1 を実行する
  • メインの .dll ファイルからリソース 210 を抽出する(このリソースは他のプロセスへの挿入に使われます)
  • 脅威の設定データを更新する

このような RPC 呼び出しのパラメータは、上述した 1 つ目の応答を介してクライアントに渡されます。たとえば、lsass.exe に挿入される .dll ファイルは、1 つ目の応答でサーバーからクライアントに渡されます。

コマンド & コントロールサーバーはしばらくオフラインにしてあったため、侵入を受けたコンピュータにどのようなコマンドが頻繁に送信されていたのか、私たちは監視できませんでしたが、前回のブログで触れたように、侵入を受けたコンピュータから送信された情報を監視することはできたので、目下のところ関連当局で感染ユーザーの識別と通知を行っているところです。

コマンド & コントロールサーバーとの通信だけでなく、Stuxnet はネットワーク共有を経由した拡散も試みます。この拡散を行うために、アクセス権があるネットワーク共有のルートに「DEFRAG[RANDOM NUMBER].tmp」として自身をコピーし、.dll ファイルを起動するジョブを作成しようとします。

この脅威は少なくとも 1 年前から常に進化を続けており、シマンテックでは現在、入手した古いサンプルを解析して、その間にどのような変化を遂げてきたのか解明に努めているところです。

W32.Stuxnet について詳しくは、こちらをご覧ください。

----------------

備考: この脅威の解析にご協力いただいた Karthik Selvaraj 氏と Nicolas Falliere 氏に感謝します。

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.