Video Screencast Help
Security Response

W32.Xpaj.B の特殊例: 感染第 1 号

Created: 28 May 2012 09:30:08 GMT • Translations available: English
Andrea Lelli's picture
0 0 Votes
Login to vote

しばらく前に、シマンテックは W32.Xpaj.B ウイルスの新しい亜種を確認し、その新機能に関する初期段階の詳細と、感染第 1 号の爆発的感染の状況について以前のブログで報告しました。その後さらに解析を進めましたが、結論として爆発的な感染はなく、少なくとも当面の間は W32.Xpaj.B の再来もないと考えるに至っています。

解析から明らかになったのは、以下の点です。

  • 第 1 号に感染したサンプルは、他のサンプルに感染する機能を持っていない。
  • 64 ビットカーネルモードのペイロードは、標的とするプロセスに DLL(ダイナミックリンクライブラリ)をインジェクトするが、その DLL は空である。
  • 感染したサンプルは第 1 号からウイルス本体のコピーを引き継いでおらず、それよりはるかに小さいウイルスによって感染している。

こうしたすべての事実から、この感染第 1 号は単なるテストサンプルであったと推測され、ウイルスは実質的なペイロード機能を実行しようとはせず、自己複製機能も存在しないと考えられます。これは、シマンテックの遠隔測定データからも裏づけられます。活動が確認されているマスターブートレコード(MBR)の感染を調べても(MBR 感染は W32.Xpaj.B の新しい亜種によるものだけで、古い亜種では発生していません)、その数は現時点で 50 に満たず、これは驚くほど少ないと言えます。

このサンプルは、爆発的な感染を狙って公開されたものではなかったようです。小規模なテストの目的で一部の特定の標的に宛てて送信されたか、作成者の手元から何らかの理由で漏えいしたかのどちらかでしょう。
 

基本構造

第 1 号は、MBR に感染し、そのペイロードをディスクの末尾にコピーします。感染したコンピュータが起動されると、MBR はこのペイロードを抽出してロードします。
 

図 1: ペイロードがディスクにインストールされる
 

ペイロードは以下のとおりです。

  • 64 ビットユーザーモード DLL: 64 ビット Windows 上で、標的のプロセスにインジェクトされた DLL
  • 32 ビットユーザーモードウイルスの本体: 感染したサンプル(32 ビット .exe ファイルと DLL のみ)は、第 1 号からではなくこのウイルス本体を運搬
  • 64 ビットカーネルモードペイロード: 64 ビットカーネルモードで実行するコード
  • 32 ビットカーネルモードペイロード: 32 ビットカーネルモードで実行するコード

前回のブログ記事で書いたとおり、このウイルスはカーネルモードドライバには感染せず、カーネルモードペイロードが MBR を介してロードされるだけです。
 

ウイルス本体のペイロードの縮小

テスト中に小さな問題が持ち上がりました。感染したサンプルを実行しても、他のサンプルには感染しなかったのです。言い換えれば、感染を複製するには、感染第 1 号を実行して第一世代の感染ファイルを生成するしかないということです。テストしたファイルのどれを実行してもまったく感染しないため、第二世代の感染を再現することはできませんでした。

そこで、今度はもっと深く問題を探ってみたところ、第 1 号で見つかったウイルス本体と、第一世代の感染サンプルで見つかったウイルス本体には、大きな違いがあることが判明しました。それはファイルサイズで、第 1 号のウイルス本体は約 170 KB ですが、感染サンプルのウイルス本体は約 50 KB と、かなり違っています。

感染サンプルのウイルス本体は、第 1 号による感染で物理ディスクの末尾に圧縮して格納されたペイロードに由来しています。この小さくなったウイルス本体を解析したところ、他のサンプルへの感染を実行する部分のコードが欠落していることがわかりました。また、MBR に感染するコードもなくなっており、圧縮されたペイロードも伴っていません。

では、いったいこれはどんな動作をするのでしょうか。その答えは次のようだと考えられます。

  • 暗号化されたデータを読み取り、ランダムな名前で %Windir% に書き込む。
  • 暗号化されたネットワーク接続をコマンド & コントロール(C&C)サーバー宛てに処理する。

ウイルスがそれ自身の更新を受信できる可能性もありますが、現在は C&C サーバーが活動していません(したがって、これは未確認です)。
 

カーネルモードペイロード

カーネルモード機能の一部は、すでに前回のブログや他の記事で報告したとおりですが、さらに解析した結果、興味深い事実が判明しています。一部の API(アプリケーションプログラミングインターフェース)と記号は存在していますが、現在のペイロードでは呼び出されていないということです。今後のバージョンではこの機能が追加されるのかもしれません。この API の一部を挙げておきます。

  • KeServiceDescriptorTable: カーネルモードの関数フックをインストールするために使われている、あるいはセキュリティ製品自体の関数フックを削除してセキュリティ製品を終了させる可能性があります。
  • IoCreateDriver: 任意のドライバをロードできます。作成者は、特定のタスクが必要になったとき他のドライバをロードできるようにする必要があったとも考えられます。

KeGetCurrentIrql も見つかりました。この API 自体は特に注目に値しませんが、コードで特殊な使われ方をしているようです。
 

図 2: KeGetCurrentIrql は、含まれる PE モジュールに基づいて動的にロードされる
 

このコードは、API を取得し、それがどのモジュールにあるかという情報を保存します。このような動作が必要なのは、XP までの Windows では API が hal.dll にあり、Windows Vista 以降では API が toskrnl.exe にあるためです。したがって、マルウェア作成者はこの操作を使って、 Windows Vista でも Windows 7 でも、それどころか Windows 8 でもこのテストを実行できたことになります。

最後になりますが、ウイルス本体(古いバージョン)の中にあったカーネルモードコードの一部が、新しいバージョンではカーネルモードペイロードに移動していました。感染第 1 号のウイルス本体にはまだカーネルモードコードが残っていますが、どうやらウイルスの作成者はドライバに感染するというアイデアを断念し、目的のカーネルモード機能を専用ペイロードに移動したように見受けられます。

この点は、ウイルスが 32 ビット版の .exe ファイルと DDL にしか感染できないという事実からも特定されます。カーネルモードでコードを実行しようと意図するなら、64 ビット版の PE(Portable Executable)ファイルにも感染する機能を追加する必要があり、またドライバもサポートしなければなりません。基本的に、ウイルス本体は 32 ビットと 64 ビットの両方で、またユーザーモードとカーネルモードの両方で実行できる必要があります。このようなマルウェアを作成して維持するだけであれば、そこまでするのは明らかに過剰な行為です。むしろ、マルウェア作成者は専用のペイロードを使うことによってコードにモジュール性を持たせ、開発がスムーズに進むようにしたのでしょう。
 

64 ビット DLL ペイロード

前述したように、標的のプロセスにインジェクトするよう意図された 64 ビット DLL は、基本的に空です。以下の画像でもそのことがわかります。
 

図 3: ダミーの 64 ビットペイロード DLL
 

実際のコードはなく、テスト文字列しかありません。また、DLL PE の形式とデータセクションの文字列から考えると、この DLL は C/C++ コンパイラでコンパイルされたものではなく、直接アセンブリ言語で書かれた節があります。

結論として、今のところ爆発的な感染はありませんが、この第 1 号にマルウェアの危険な進化が垣間見えていることは明らかです。新しい亜種がいつリリースされるのか、そもそもリリースされるのかどうかさえ断言はできませんが、それほど遠いことではないだろうと考えられます。今回のサンプルのおかげで耐性ができました。早期の解析を実行しマルウェアの機先を制することができたことで今はひとまず安心です。今後もこの脅威の監視を続けますが、実際の拡散が始まったときにも準備は万全です。

 

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