サポート情報 | フォーカスシステムズ サイバーフォレンジックセンター

メールでのお問い合わせ
お問い合わせはこちら
東京証券取引所 プライバシーマーク ISMS JUSE

サポート情報

ホーム > サポート情報一覧 > CryptoWallの暗号化レイアウト

CryptoWallの暗号化レイアウト

目次へ

 CryptoWallの暗号化の処理の流れは、「CryptoWallによる暗号化処理(前編)」および「CryptoWallによる暗号化処理(後編)」で解明されました。

 処理の流れを追えば自ずとそのレイアウトは分かりますが、改めてまとめてみましょう。また、記事では比較的小さなファイルをターゲットにしましたが、「ある一定」のサイズを超えると、ファイルのレイアウトに注意が必要な処理がありましたので、併せて記載しておきます。

 暗号化されたファイルの内容は【図167】のとおりです。

CryptoWall_FileLayout1

【図167】CryptoWallによる暗号化されたファイルのレイアウト

 

 まず最初に、16バイトの「X509公開鍵バイナリデータのMD5ハッシュ値」があります。このパラメータについて考察してみましょう。

 「CryptoWallによる暗号化処理(前編)」で、暗号化対象ファイルかチェックするために、先頭16バイトがこの値と合致しないかを判定していました。このことから、2重で暗号化をしてしまうための防止策として利用されていることがわかります。このためにハッシュ値を埋め込んだのでしょうか?

 これには、もう一つ別の可能性が考えられます。「CryptoWallの通信(2回目)」で個別の情報(今回の場合、「x8NsN4」)や公開鍵を送りつけてきた際、攻撃者は秘密鍵と公開鍵のペアと個別の情報(「x8NsN4」)を紐付けて管理していると考えられます。では、仮にファイル単体だけが与えられた場合、攻撃者は復号できないのでしょうか?

 答えは、「復号できる可能性は十分にある」といえます。攻撃者は、秘密鍵と公開鍵のペアを持っていますが、この公開鍵の情報から「X509公開鍵バイナリデータのMD5ハッシュ値」は容易に計算可能です。「秘密鍵と公開鍵のペア」-「X509公開鍵バイナリデータのMD5ハッシュ値」-「個別の情報(「x8NsN4」)」を紐付けて管理しておけば、ユーザ、ファイルいずれかの条件で「復号に必要な秘密鍵と公開鍵のペア」を特定できる、というわけです。

 また、一つのローカルネットワーク内で複数の端末が感染すると、複数の公開鍵で暗号化されたファイルが混在することになります。復号ツールは、恐らくその可能性も考慮して、被害者がお金を出して得たツールが「秘密鍵と公開鍵のペア」から公開鍵を取り出し、公開鍵のハッシュを計算して、復号する対象のファイルかを判定しているのではないかと思われます。

 こうしたことから、「復号も含めて」正常に動作するために重要な情報として、先頭に設定されていると推測されます。

 2番目に、公開鍵で暗号化されたAESの鍵が格納されています。これは、ファイルごとにAESの鍵を個別に作っていることが解析で判明しています。これは、仮に1つのファイルのAESの鍵が判明してしまっても、他のファイルまで一気に復号されてしまうことを防ぐ目的と考えられます。

 3番目には、 4バイトのバイナリデータが入っています。数値としてみた場合は0x00000020で、この値の意味は残念ながら未確認です。

 4番目には、AES鍵で暗号化されたファイル名のデータの長さおよび暗号化されたファイルが格納されています。これは、復号処理時にファイル名を戻すために必要です。

 最後に、AES鍵で暗号化されたファイル本体のサイズと暗号化されたファイル本体が格納されています。ここで、「CryptoWallによる暗号化処理(後編)」では触れていないトピックが一つあります。

 内部の処理を解析していると、「ある程度のサイズ」以上のファイルを読み込む場合、固定のバッファサイズまでしか読み込まず、読み込んだデータで一度暗号化を行っているのです。これは繰り返し処理になっており、その都度CryptGenKeyで作られた鍵をDuplicateして暗号化しています。「ある程度のサイズ」は0x00080000 = 524,288バイトとなっており、これを超える場合はこの単位ごとにブロック化されて暗号化、ファイル出力が行われます(【図168】参照)。

CryptoWall_FileLayout2

【図168-1】暗号化された524,288バイト以上のファイル

 

CryptoWall_FileLayout3

CryptoWall_FileLayout4

CryptoWall_FileLayout5

【図168-2】524,288バイト以上のファイルの暗号化時ファイルレイアウト

 

 この結果を見ると、単純にはCryptoWallによって暗号化されたファイルの復元を秘密鍵無しで行うことは難しいことが分かります。

 しかし、一方で「攻撃者側にミス」があれば、サイドチャネル的な方法での解読の可能性も見えてきます。

 例えば、攻撃者が「秘密鍵と公開鍵のペア」を個別に作成する仕組みを作るのを怠り、事前に有限数の「秘密鍵と公開鍵のペア」を用意しておいて、使いまわしている、というケースはどうでしょうか?このケースの場合、仮に攻撃者の要求に応じてしまって「秘密鍵と公開鍵のペア」を入手した被害者がいた場合、ファイルの上位16バイトが一致する別の被害者のファイルも復元できることになります。

 別の例としては、捜査機関がサーバを差し押さえ、C&Cサーバから情報を得た場合、仮に「秘密鍵と公開鍵のペア」-「個別の情報」の紐付きが失われていたとしても、「秘密鍵と公開鍵のペア」から公開鍵のハッシュを計算して公開することで、先頭16バイトが合致するファイルの所有者の救済も見えてくる、というわけです。もちろん、この場合は攻撃者から復号ツールを得られないことが考えられますが、【図167】、【図168】のようにレイアウトが分かっていれば、復号ツールも比較的容易に作成が可能だと思います。

 OSの機能を利用する例としては、VSSによる復元の可能性があります。「svchostの起動とVolume Shadow Copyの消去」で削除を試みていますが、記事で触れたとおりAdministrator権限で動作していなければ、削除に失敗し、情報が残っています。もちろん、設定によってバックアップの対象が変わりますし、最後のバックアップ以降に作成、変更された情報は残りません。完全な復元は難しいですが、一部でも復元できるかもしれない方法として挙げておきます。

 一般的なマルウェア調査でも、マルウェアが作成するファイルの内容について、このようにプログラムを解析してデータのレイアウトが分かれば、フォレンジック調査で見つかった「マルウェアが作成したらしいファイル」を分析し、マルウェアが何をしようとしていたかを詳しく知ることに繋がると考えられます。

 

< CryptoWallによる暗号化処理(後編) 目 次 「攻撃する側の論理」からのプログラムの推察 >