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

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

サポート情報

ホーム > サポート情報一覧 > CryptoWallの暗号化処理の準備

CryptoWallの暗号化処理の準備

目次へ

 CryptoWallでは、暗号化処理を行うにあたって、「再展開されたプログラムのImportテーブル」で見られた「CryptoAPI」を利用しています。通信でダウンロードした公開鍵を用いて準備を行っているので、その流れを追ってみましょう。

 なお、解説中でCryptoAPIに関する操作がありますが、筆者はCryptoAPIを用いたプログラムの作成を行ったことがありません。そのため、マニュアルを参照して記事を書いています。もし、処理の解釈に誤りがあれば、ご指摘いただきたいと思います。

 まず、CryptAquireContext関数で暗号化サービスプロバイダ(CSP)のキーコンテナへのハンドルを取得します(【図133】参照)。

IDA_Cryptowall_PublicKey_AcquireCtxt

【図133】キーコンテナへのハンドル取得

 

 次に、「CryptoWallの通信(2回目)」でバイナリ化された公開鍵情報(【図118】)をデコードしています(【図134】参照)。

IDA_Cryptowall_PublicKey_DecodeObj1

【図134-1】公開鍵バイナリデータのデコード処理

 

IDA_Cryptowall_PublicKey_DecodeObj2

【図134-2】公開鍵バイナリデータのデコード結果

 

 さらに、デコードされた公開鍵情報をImportします(【図135】参照)。このようにして、ダウンロードしてきた公開鍵を用いて暗号化をする準備を行います。

IDA_Cryptowall_PublicKey_ImportPublicKey1

【図135-1】公開鍵情報をCSPにインポート

 

IDA_Cryptowall_PublicKey_ImportPublicKey2

【図135-2】公開鍵情報をCSPにインポートした結果(公開鍵ハンドル取得)

 

 また、この直後に別のCSPのハンドルを用いて、MD5のハッシュ値の計算を行っていました(【図136】参照)。計算の対象は、「CryptoWallの通信(2回目)」でバイナリ化された公開鍵情報(【図118】)を対象としています。

 ここで得たハッシュ値は、後々重要な意味を持つため、意識しておく必要があります。

IDA_Cryptowall_PublicKey_Hash1

【図136-1】X509公開鍵バイナリデータのハッシュ計算処理

 

IDA_Cryptowall_PublicKey_Hash2

【図136-2】X509公開鍵バイナリデータのハッシュ計算結果取得処理

 

IDA_Cryptowall_PublicKey_Hash3

【図136-3】X509公開鍵バイナリデータのハッシュ計算結果

 

 こうして、暗号化に必要なハンドルの取得や、処理で使われる見込みのハッシュ値の準備ができました。

 ここで、ちょっと気になることがあります。今回の調査では、何度かCryptoWallを起動していて、ある程度メモリ情報をメモしているのですが、このハッシュ値は以前に実行したときの値と同じでした。これは、同じ公開鍵であることを示しています。一見すると、PC固有の情報を送っているため、既に登録されたPCの場合は同じ公開鍵を送ってくるのだろう、と思うところです。しかし、「通信先URLの展開」で述べたとおり、アクセス先のURLはランダムにシャッフルされるため、「通信が成功した対象」であることを前提としても、以前と同じサーバと通信しているとは限りません(もっとも、多数あるアドレスのうち、1つ以外は全てダミーであれば、通信先は自ずと一意になりますが・・・)。

 そうなると、複数のサーバ間で被害者のPC情報とそれに紐づく鍵情報を並列化しているか、マスターになっているサーバから取得する必要があります。とはいえ、前者は仕組みが複雑ですし、後者はC&Cサーバが差し押さえられた場合、マスターのサーバが割り出される恐れがあり、いずれも攻撃者にとって得策ではありません。また、公開鍵と秘密鍵のペアを、被害者のPCがアクセスしてきた度に作成しているのか、という疑問もあります。ひょっとすると、限られた数の秘密鍵と公開鍵のペアしか用意していないのかもしれませんね。

 続いて、暗号化処理の開始です。ここでも、CryptoWallは新たなスレッドを起動しています。

 まず、論理ドライブの文字列を取得しています(【図137】参照)。

IDA_Cryptowall_GetLogicalDriveStrings1

【図137-1】論理ドライブの文字列の取得

 

IDA_Cryptowall_GetLogicalDriveStrings2

【図137-2】論理ドライブの文字列の取得結果

 

IDA_Cryptowall_GetLogicalDriveStrings3

【図137-3】検証しているPCのドライブの状況

 

 得られたドライブの文字列に対し、繰り返し処理で順に処理を行って行きます。まず、GetDriveTypeW関数で、ドライブの種類を取得します(【図138】参照)。この結果を[11969]で0x05と比較していますが、これはこのドライブがCD-ROM(DVD等を含む)かどうかを判定しているのです。そして、CD-ROM等の場合、次のドライブ文字の判定に移ります。

 つまり、「CD-ROMドライブに対しては暗号化処理を行わない」という判定なのです。

IDA_Cryptowall_GetDriveType

【図138】ドライブの種類の取得と判定

 

 さらに、後続の処理では、ドライブ直下にPNGファイルがある想定のパス名を作成します(【図139】参照)。

 このパスに対して、FILE_READ_ATTRIBUTESでNtCreateFileを行います。実行環境では、Cドライブ直下に当該ファイルはないため、エラー値(EAX=0x00000034)が返ってきました。これは、そのファイルの存在をチェックすることで、暗号化済みかどうかを判定する意図があるのではないか、と推測されます。

IDA_Cryptowall_PNG_CheckPath

【図139】ファイルチェックのためのパス

 

 ドライブがCD-ROMでなく、C直下にPNGファイルが無いと、【図135】で作成した公開鍵ハンドルの複製を行います(【図140】参照)。これは、この後に起動するスレッドに対し渡すものです。

IDA_Cryptowall_PNG_DuplicateKey1

【図140-1】公開鍵ハンドルの複製

 

IDA_Cryptowall_PNG_DuplicateKey2

【図140-2】公開鍵ハンドルの複製結果

 

 これらの準備が整ったところで、CreateRemoteThreadでスレッドを起動します(【図141】参照)。引数のパラメータを見ると、スレッドが暗号化の対象にするドライブ名のほか、【図140】で複製された公開鍵ハンドル、ハッシュ値(のコピー)が格納されたアドレスが設定されていることが分かります。

 スレッドは繰り返し処理により作成され、CD-ROM等のドライブ以外について暗号化処理のスレッドが起動されるのです。つまり、マルチスレッド処理による高速化まで考慮して作成されている、ということです。

 また、「ドライブ文字列」を取得して対象にしている点も重要です。これは、ネットワークドライブに対してドライブ文字を割り当てている場合、そのドライブも暗号化の対象になる、ということです。大抵の場合、ドライブ文字を割り当てたネットワークドライブにはアクセス権があるため、ネットワーク上のファイルまでランサムウェアによる被害が拡大することを意味します。

IDA_Cryptowall_Crypt_CreateRemoteThread

【図141】暗号化処理のスレッド起動

 

 こうして、ドライブ毎に暗号化処理に必要な情報やオブジェクトがコピーされ、暗号化処理のためのスレッドが起動されます。

 親となったスレッドは、暗号化処理スレッドを起動した後は、NtWaitForMultipleObjects関数で全てのスレッドの終了の待ちに入ります。「マルウェアを動作させてみる」での検証では、暗号化が終了した後、Roaming下のマルウェアとファイルを消し、脅迫文がテキスト、ブラウザ、PNGファイルで表示されることが分かっています。このことから、この待ち処理の後に、ファイル削除や脅迫文の表示をする処理があることが予想されます。

 では、暗号化スレッドの処理の解析に移りましょう。

 

< CryptoWallの脅迫文の生成とファイル出力目 次 CryptoWallによる暗号化処理(前編) >