凌（しのぎ）です。暗号化が施されたマルウェアの解析結果および対策を書きます。

■得体の知れないバイナリの解析

7月某日、あるマルウェアに感染した端末からPCAP（通信）データを入手しました。そこには得体の知れないバイナリをHTTPでダウンロードしているアクティビティが見つかりました。このバイナリを「検体」と呼ぶことにします。

この検体がどのようなファイルタイプであるかを把握するためにバイナリエディタを開き、「目grep」を行いました。バイナリデータの可視化の結果は以下の通りです。

凡例）

白色：NULL (0x00)

青色：文字制御コード(0x01～0x1F）

赤色：ASCIIコード（0x20～0x7F）

黒色：命令コード（0x80～0xFF）

図１）バイナリデータの可視化イメージ

様々な領域を含んでいることから実行ファイル（EXE）ではないかと推測しました。しかし、先頭データは一般的な実行ファイルのヘッダーではありませんでした。

図２）検体の先頭データ

　一般的な実行ファイルは以下の通り、先頭に「MZ」ヘッダがあり、「This program cannot be run in DOS mode」、「PE」などの文字列が見られます。

図３）一般的な実行ファイルの先頭データ

図２と図３の先頭データを比較すると、NULL(0x00)バイトの位置が一致しているという特徴がありました。このことから、NULLバイト以外はバイト単位で暗号化されているという仮説を立て、0x4E～0x73「This program cannot 」を比較しました。まずは、XOR（排他的論理和）を試したところ、以下の結果となりました。

[Origin]欄が検体のバイナリ、[Plain]欄がEXEであれば本来あるべきバイナリデータ、[XOR]欄がOriginとPlainのXOR結果であり、XOR暗号化されていれば、暗号鍵そのものとなります。

※Hex・・・16進数、Bin・・・2進数、Asc・・・アスキー

図４）XORの結果

XORのアスキーに注目すると以下の文字列が読み取れます。

「onne tc nnect o e t」

「connect」という文字列が繰り返されているように見えるが虫食い状態です。次にXORの結果がNULLとなっている箇所に注目しました。元の値（Origin欄）を見ると以下の通りとなりました。

図５）XORの結果がNULLとなった個所のAscii

アドレス0x52以外の値については、「connect」に含まれる文字列です。

上述した特徴の通り、もともとのバイナリに含まれるNULLについては、暗号化を施していないことから、暗号化した結果がNULLになる場合は、暗号化せずに元の値を残すアルゴリズムであることが考えられます。そうしないと、復号する際にNULLのバイトをそのままにすべきか、復号すべきが判断できないためです。

これで復号をするためのアルゴリズムがある程度特定できました。

①NULLは復号しない。

②NULL以外のバイトは暗号鍵「connect」でXORする。

③ただし、暗号化した結果がNULL値になる場合は復号せずにそのバイトを残す

一点、解けていない謎として上記のアドレス0x52がなぜそのままであるかということだった。その後、範囲を広げて調べた結果14バイトの周期で同様に暗号化されていないバイトがあったことが分かりました。その結果、鍵長が14バイトであり、暗号化鍵はconnectconne(NULL)tであると特定できました。

これで復号する条件が揃い、以下の処理をするスクリプトを作成し、復号を試みました。

①NULLは復号しない。

②NULL以外のバイトは暗号鍵「connectconne(NULL)t」でXORする。

③ただし、暗号化した結果がNULL値になる場合は復号せずにそのバイトを残す

復号が正常に完了し、平文の検体がやっと入手できました。

解析の結果、コードインジェクションをしたり、外部のサーバ（おそらくC&Cサーバ）と通信するという動作が見つかり、遠隔操作をするためのRATまたはBOTであるという結論に達しました。

≪なぜ犯人はNULLを暗号化しなかったのか≫

XOR暗号化そのものは実装がしやすく、検知回避テクニックとして、標的型攻撃でもよく用いられる手法です。犯人はなぜ単なるXOR暗号化ではなく、NULLをそのまま残したり、若干複雑なアルゴリズムを利用したのでしょうか。その答えは異なる検体を見ていただくとわかります。

図６）異なる「XOR暗号化された」検体

この検体もXOR暗号が施されていたのですが、NULLについては暗号化しています。暗号化鍵は解析をするまでもなく、「binkey」であることがわかります。つまり、NULLをXORすると鍵がそのままバイナリに表れてしまい、解読が簡単にされてしまうのです。

犯人がNULLを暗号化しなかった理由は簡単に解析をされないようにするためだったということが想像できます。

■暗号化されたマルウェアの対策

丸ごと暗号化されたマルウェアは単体では実行できないため、全くもって無害です。通常暗号化されたマルウェアは、「ダウンローダ」と呼ばれる1次検体がダウンロードし、ローカルで復号し、実行します。そこで初めて攻撃用のプログラムが実行されます。

暗号化のアルゴリズム、鍵などはVariability（可変性）が非常に高く、攻撃者は無数の暗号化された検体を作成することができます。そのため、従来のシグネチャベースのゲートウェイ型のウィルス対策ではすり抜ける可能性が極めて大きいです。

・ネットワーク側での対策

ProxyによるURLフィルター機能により、ダウンロード先のIPアドレス、DNS名などのレピュテーションをもとにブロックすることが可能です。ただし、犯人がIPアドレスやDNS名を変更し、真新しいものを利用したり、よく知られているクラウドストレージをダウンロード先として利用している場合はやはり対策が難しいです。

振る舞い検知をする「サンドボックス製品」は有効な対策ですが、注意が必要です。単体のみで実行しようとする製品では対策となりません。上述の通り、単体では攻撃が発動しないためです。「ダウンローダ」と「暗号化されたマルウェア」が同じ仮想環境で実行されることが対策の必須条件となります。これらの製品を検討する際はぜひご確認いただければと思います。

・クライアント側での対策

ローカルで復号されて実行されるため、出回っているマルウェアであれば、ブラックリスト型のウィルス対策で検知できる可能性は高いです。当然ですが、標的型のもので出回っていないものであれば、振る舞い検知、ホワイトリストでの検知が必要となります。

以上