ボットネットの観測方法をさらに詳しく分析する(2) - Krakenの狙いとは

前回に引き続き、今回もKrakenボットネットについてDVLabsが行った調査を紹介する。とくに今回は暗号化プロトコルの分析結果と、分析によって得られたKrakenの全体像を説明したい。

Krakenの使用する暗号プロトコル

前回の続きからになるが、Krakenが行う通信の最初の8バイトは固定値をとる。たとえば、SANS Internet Storm Centerは"Kraken Technical Details: UPDATED x3"という記事において、図1のようなパケットを例として示している。

このように先頭の8バイトが固定値なのである。そして、この固定値こそが暗号化プロトコルで使用される鍵そのものであるというのだ。DVLabsによると、この固定値は感染端末毎に異なり、図2のように感染端末のハードウェアの値を使用して算出されるのであるという。

したがって、通信さえ受信できれば、暗号鍵を使って復号できるということになる。また、さらに暗号化プロトコルを分析するとKrakenの使用する通信のヘッダは、図3のような構造であることがわかるという。

興味深いことに、命令(command)は従来のように可読性のある文字ではなく、整数として定義されている。したがって、トラフィックの内容を復号できたとしても、そこからコマンドの内容までをうかがい知ることはできないということになる。Krakenの難読化その2、である。DVLabsでは、アップデート命令を通じた一連の処理におけるコマンドのやりとりは、次のようなものであると述べている。

1. 感染端末から最初のパケットを受け取る(コマンド番号1)
2. サーバによってXORされた暗号鍵を返信する(コマンド番号2)
3. 感染端末から設定情報を受け取る(コマンド番号3)
4. 新しいモジュールを使用するよう更新を命じる(コマンド番号8)
5. アップデートファイルのXMLデータを感染端末に送信(コマンド番号0x14)
6. 感染端末がファイルをダウンロードするためにTCP447番ポートで接続を待ち受ける
7. 感染端末に暗号化されたモジュールを送信(コマンド番号0xA)

XMLで記述されたアップデートモジュールのプロフィールデータを基に、ダウンロードしたファイルのCRCチェックサムが確認される。CRCチェックサムが一致すれば、そのデータはC:\Windows\System32フォルダにランダムなファイル名で書き込まれ、実行される。

このようにして、動作が分析されたKrakenの暗号化プロトコルを完全にエミュレートするサーバのデモが公開されている。法的な問題点などについては、前回述べた通りなのでここでは繰り返さない。ちなみに、難読化についてはこれら2つにとどまらず、そもそも分析可能なバイナリを展開させるためには、ランタイムパッカーとジャンクコードが挿入されたコードからオリジナルのコードを抽出する必要がある(図4)。

まとめ

前回と今回の2回にわたり、Krakenの詳細をご紹介した。その目的は、現在のボットの姿がどのようなモノであるか、その深淵を少しでもご紹介することにあった。実際のところ、Krakenにはメール送信機能が実装されていることから、迷惑メール送信に主に使用されていると考えられる。したがって、ボットならびにボットネットを使用する側の目的はさほど変化がないものと思われる。すなわち金銭目的である。また、XMLデータを使用に代表されるように、現代的なソフトウェア開発の手法がボットの開発にも取り入れられていることが感触として伝わってくる。

他方で、その感染動作を把握するためには通信の内容、コードの分析、難読化の解除といった複数のアプローチを試みる必要がある。そしてこれらに支払われる時間的ならびに技術的コストは非常に大きく、作成者側の優位性を高めてしまっている。しかしながらCWSandboxのように短時間でマルウェアの感染動作を明らかにするソリューションも存在していることから「せめぎ合い」の様相はこれからも続くと思われる。