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

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

サポート情報

ホーム > サポート情報一覧 > CryptoWallの脅迫文の生成とファイル出力

CryptoWallの脅迫文の生成とファイル出力

目次へ

 通信によって、暗号化に必要な鍵の取得と、被害者へメッセージを表示するために必要な情報が揃いました。

 実際の暗号化を行う前に、これらの情報を用いて、脅迫文の編集を行っています。また、それらの情報を元に、実はファイル出力を行っています。これは、「マルウェアを動作させてみる」では見落としていた部分です。こういったことも、実際のプログラムを解析することで判明することもあるので、利点かもしれません。

 脅迫文の画像については、「CryptoWallの通信(2回目)」で触れたとおり、受信データから展開できました。一方、テキストについては、torのアドレスやURL情報のみでした。そのため、これらを「埋め込んだ」脅迫文を作る動きをします。

 データ自体は埋め込まれており、何度か触れてきた「独自のテーブルを用いた展開処理」を用いて脅迫文のテキストを抽出しています(【図120】参照)。

IDA_Cryptowall_ThreatMsg1

【図120-1】脅迫文の元データ

 

IDA_Cryptowall_ThreatMsg2

【図120-2】脅迫文の変換テーブル(使用中のもの)

 

IDA_Cryptowall_ThreatMsg3

【図120-3】脅迫文を独自テーブルで展開した結果

 

 このデータはLZ圧縮データのため、さらにRtlDecompressBufferで復号しています(【図121】参照)。なお、解凍元のデータである【図120-3】の先頭4バイトに、解凍後のサイズが予め設定されています。

IDA_Cryptowall_ThreatMsg4

【図121-1】圧縮されているデータを展開する処理

 

IDA_Cryptowall_ThreatMsg5

【図121-2】圧縮されているデータを展開した結果

 

 内容は、HTML形式のテキスト文書と.txt用のデータが混在していました。

 この脅迫文の容量は大きく、このバイナリをファイル出力すると、200kB余りのサイズがありました。脅迫文の内容を調査した方々は概ねのサイズを知っているかと思いますが、HTMLとテキストのファイルサイズを合計しても、そのようなサイズにはなりません。では、なぜこんなに大きいのでしょうか?データの中身を見ると、驚くことがわかりました。

 テキストのデータは、5ヶ国語分用意されていたのです。内訳は、

 

 ・ドイツ語

 ・英語

 ・スペイン語

 ・フランス語

 ・イタリア語

 

となっていました(【図122】参照)。つまり、攻撃者は、被害者のロケール情報を用いて、被害者の言語に合ったメッセージを出す準備まで行っていたのです。なお、用意した言語に合致しない場合は、英語のメッセージを出力するようです。

 プログラムの仕組みとしては、展開されたデータを言語ごとに分割した後で、どの言語を使うか判定しています。そのため、ヘッダ部分+HTML文+ヘッダ部分+テキスト文のレイアウトを守れば、さらに言語を追加できるのではないかと予想されます。もっとも、それはマルウェアのサイズが大きくなり、不利になるため、好んではやらないかもしれませんが。

 CryptoWallの亜種以外で、プログラムのつくりが違っても脅迫文の文章が同じものがある、ということを聞いたことがありますが、その理由はこの処理を流用しているからかもしれません。攻撃者が知らない言語の脅迫文もそのまま流用できる、という点が攻撃者にとって有用、というわけです。

IDA_Cryptowall_ThreatMsg_German

【図122-1】ドイツ語の脅迫文メッセージ

 

IDA_Cryptowall_ThreatMsg_English

【図122-2】英語の脅迫文メッセージ

 

IDA_Cryptowall_ThreatMsg_Spanish

【図122-3】スペイン語の脅迫文メッセージ

 

IDA_Cryptowall_ThreatMsg_French

【図122-4】フランス語の脅迫文メッセージ

 

IDA_Cryptowall_ThreatMsg_Italy

【図122-5】イタリア語の脅迫文メッセージ

 

 脅迫文の原文を復号した後は、5つある言語のうち、どの言語を用いるかを判定します。その判定のための文字列を、【図123】のように編集している処理がありました。これを32ビットの値に変換しており、その値と照合して合致した言語を用いていると考えられます。なお、日本語の脅迫文は残念ながらありませんでしたので、デフォルトの英語が使われています。

 実際の処理はHTMLのテキスト抽出を行い、その編集を行ったあと、txtファイルのテキスト抽出を行い、その編集を行っています。ただし、行っていることは同じであるため、HTML文のみを例に解説させていただきます。

IDA_Cryptowall_LocalInfo

【図123】脅迫文の言語を判定するための文字列編集

 

 脅迫文の言語が決まり、そのテキストを抽出すると、文字列の変換を行います。脅迫文の中身は、差し替える箇所は【図124】のように”%”でパラメータを囲って目印にしています。%TOR%はtorのアドレス、%HTTP_1%~%HTTP_4%はURLが入ります。これらの情報は、「CryptoWallの通信(2回目)」で既に展開されていることが分かっています。

 差し替えの処理は、愚直にこれらのパラメータを、memcpyを駆使して置き換えています。そのために度々仮想メモリの再取得を行うなど、解析する側としては煩雑ですが、内容的には単純で目新しいこともないので、「置き換えを行って、HTMLと.txtの脅迫文を完成させている」という理解で十分でしょう。

IDA_Cryptowall_ThreatMsg6

【図124-1】脅迫文の編集箇所(URL)

 

IDA_Cryptowall_ThreatMsg7

【図124-2】脅迫文の編集箇所(tor)

 

 脅迫文の作成ができると、ファイル出力の処理に移ります。

 まず、ファイルのパスを編集します(【図125】参照)。Roamingまでのパスの取得方法は、「ランサムウェアの自動起動設定」で行っているのと同じ方法を用いています。また、ファイル名の「93cfef」がハッシュ値にふくまれていることも同じです。理由も、先に述べた理由と同じであると思われます。

IDA_Cryptowall_PublicKey_FilePath

【図125】ファイルパスの編集

 

 次に、ファイルに出力されるデータの編集に移ります。

 出力データの先頭には、「CryptoWallの通信(2回目)」でバイナリ化された公開鍵情報が入ります(【図126】参照)。データ本体の前に、データのサイズが設定されています。

IDA_Cryptowall_PublicKey_FileData1

【図126】ファイルに出力されるデータの編集(公開鍵情報)

 

 公開鍵の情報の次には、脅迫文のHTMLが結合されます。このときも、HTMLのデータのサイズがデータの前に4バイトで格納されています(【図127】参照)。

IDA_Cryptowall_PublicKey_FileData2

【図127】ファイルに出力されるデータの編集(HTMLの脅迫文情報追加)

 

 更に、テキストの脅迫文がサイズとともに追加され、最後にPNGの脅迫文がサイズとともに追加されます(【図128】参照)。

IDA_Cryptowall_PublicKey_FileData3

【図128】ファイルに出力されるデータの編集(PNGの脅迫文情報追加)

 

 その結果、以下のようなデータレイアウトのバッファができあがります。

 

[公開鍵のサイズ] + [公開鍵データ] + [HTMLのサイズ] + [HTMLデータ] + [テキストのサイズ] + [テキストデータ] + [PNGのサイズ] + [PNGデータ]

 

 この内容をみると、通信で得られた情報を加工した結果が全て含まれていることが分かります。逆にいえば、このデータさえあれば、通信を行わなくてもよい、ということになります。

 ここから考察すると、このファイルの目的が浮かび上がってきます。

 「ランサムウェアの自動起動設定」の最後でも触れましたが、「ランサムウェアによる暗号化を行っている途中にログオフやシャットダウンをしたときの対策のために自動実行を設定していますが、これにより再度暗号化をする場合、鍵などはどのように扱っているのでしょうか?」という疑問がありました。この答えとして、同じ「公開鍵」を使うための仕組みであることが容易に推測できるのです。また、脅迫文も含んでいるため、「このファイル情報があれば通信が繋がっていなくても処理を再開、継続でき、目的を達成できる」ということが分かります。攻撃者は、処理再開時に同じ鍵を利用するだけでなく、通信ができなくても処理を継続できるようにプログラムを作成しているのです。

 一方、このような重要な情報は、目的達成後は削除されてしまいます。今回の初期の調査でも、処理終了後にはこのファイルは消されていてありませんでした。

 CryptoWallに限らず、マルウェアはこのように重要な痕跡を残すことがあります。仮に、CryptoWallの処理が終わり、ファイルが削除されていても、OSから見えないだけでディスク上に痕跡が残っている場合があります。痕跡が残っていれば、EnCaseFTKといったフォレンジックツールで復元をすることも可能となります。そのため、こういった被害にあった場合は、下手にウィルススキャン等を行う前に、一度シャットダウンし、HDDを100%コピーできるデュプリケータを用いて保全することが重要となります。インシデントレスポンスの手順を作る際には、この「保全」について留意していただければと思います。

 【図128】まで編集されたデータは、このままの形では出力されません。RtlCompressData APIを用いて圧縮を行っています(【図129】参照)。

IDA_Cryptowall_PublicKey_FileData4

【図129】ファイル出力対象圧縮処理

 

 さらに、何度も出てきている「独自の変換テーブルを用いた変換」を行って難読化しています。こうしてできたデータに、ヘッダを付与して、最終的な出力データにしています(【図130】参照)。

IDA_Cryptowall_PublicKey_FileData5

【図130-1】独自変換処理後、ヘッダを付与して出力データが完成

 

IDA_Cryptowall_PublicKey_FileData6

【図130-2】完成した出力データ

 

 ファイルの出力は、APIを用いて単純に出力しているだけです。まず、NtCreateFile APIでRoaming下にファイルを生成しています(【図131】参照)。

IDA_Cryptowall_PublicKey_CreateFile1

【図131-1】ファイルの生成

 

IDA_Cryptowall_PublicKey_CreateFile2

【図131-2】ファイルの生成(0バイトのファイル発生)

 

 次に、NtWriteFileでデータを出力します。書き込みの終了をイベントを利用して検知し、最後にファイルハンドルをクローズしています(【図132】参照)。

IDA_Cryptowall_PublicKey_WriteFile1

【図132-1】ファイルの出力

 

IDA_Cryptowall_PublicKey_WriteFile2

【図132-2】ファイルの出力(出力によるサイズ増加)

 

 これで、受信データの一通りの編集や、そのデータ保持方法が判明しました。

 この後は、いよいよ暗号化処理に移って行きます。

 

< CryptoWallの通信(2回目)目 次CryptoWallの暗号化処理の準備 >