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

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

サポート情報

ホーム > サポート情報一覧 > CryptoWallの通信(2回目)

CryptoWallの通信(2回目)

目次へ

 1回目の通信では、暗号化に用いられそうな重要な情報はありませんでした。さらにステップを進めて行くと、新たなスレッドが起動された後、そのスレッドで通信を行っていることが判明しました。この通信で、重要な情報を取得していました。通信の流れと内容を解説していきたいと思います。

 まず、1回目の通信と同様、通信文を作成します。再び、「crypt13001」やハッシュ値を含んだテキストを作成します。1回目とは、数字パラメータが少々違うため、このパラメータによってサーバの応答が変わるのかもしれません(【図110】参照)。

IDA_Cryptowall_Comm2_SendData1

【図110】通信に用いられるテキストのパラメータ

 

 この後、1回目と同様にランダムな文字列を2つ生成します(【図111】参照)。2つ目のランダムな文字列は、さらにバイナリ値を文字列に変換しています。

IDA_Cryptowall_Comm2_SendData2

【図111-1】ランダムな英小文字を取得し、さらに一部をランダムな数値に置き換え(1つ目)

 

IDA_Cryptowall_Comm2_SendData3

【図111-2】ランダムな英小文字を取得し、さらに一部をランダムな数値に置き換え(2つ目)

 

 1回目の通信と同様に、【図110】の文字列をある法則で変換します。さらにバイナリ値を文字列に変換しています(【図112】参照)。

IDA_Cryptowall_Comm2_SendData4

【図112】PC固有の情報を変換した値

 

 これらの情報を元に、1回目と同様にURLのパラメータおよびPOSTパラメータを生成します(【図113】参照)。

IDA_Cryptowall_Comm2_SendData5

【図113-1】POSTのために編集されたパラメータ

 

IDA_Cryptowall_Comm2_SendData6

【図113-2】URLのために編集されたパラメータ

 

 このことで分かるのは、CryptoWall側で任意にコントロールできる値はPOSTの後半部のバイナリの値だけであることが分かります。これを用いて、C&Cサーバはレスポンスを決定していると考えるのが妥当でしょう。「crypt13001」の前の数値の違いなどが重要な役割を果たしているのかもしれません。

 この通信も、サーバが既にC&Cとして機能していない場合、失敗します。返信データに、File not foundや、エラーを表示するためのhtmlが返ってきてしまいます。今回の調査でも、何箇所かのURLについては失敗しました。成功したとき、【図114】のようなデータを受信しました。

IDA_Cryptowall_Comm2_RecieveData1

【図114】CryptoWallがC&Cとの通信に成功したときに得られる受信データ

 

 このデータは「16進数のバイナリ値を文字列に変換したデータ」です。そのため、sscanf関数を用いてバイナリ値に変換しています(【図115】参照)。この状態では何を意味するかわかりませんが、1回目と比べて非常に大きな受信データとなっており、重要な情報が隠されている可能性があります。

 この情報をCryptoWallがどのように解読しているか、少し詳細にみていきたいと思います。

IDA_Cryptowall_Comm2_RecieveData2

【図115】CryptoWallの受信データのバイナリ変換結果

 

 まず、このバイナリデータに対し、1回目の受信時と同様に、やはり独自のバイナリテーブルとxorを用いた変換を行っています。その変換の結果を【図116】に示します。

IDA_Cryptowall_Comm2_RecieveData3

【図116】受信データバイナリ値に対するテーブル変換結果

 

 結果を見ると、この情報だけでも十分重要な情報が見てとれます。

 最初の部分には、torに用いられているアドレスに関する情報が入っています。その後ろに国の情報(jp)があり、その後ろには4つのURLがあります。これは、このCryptoWallに感染した場合、アクセスするように指定している4つのURLのドメイン名となっています。

 そして、最も特徴的なのが、その後ろにある文字列です。見覚えがある方も多いと思いますが、「公開鍵」のX509形式の情報が格納されているのです。CryptoWallによる暗号化で重要な役割を果たす可能性が考えられるため、このパラメータがどのように利用されるか、注目する必要があるでしょう。

 【図116】では表示されていませんが、この公開鍵の後ろには、さらにバイナリデータが格納されています。こちらのバイナリデータに関しては、ぱっと見で何のデータか分かりませんが、この後展開されると思われます。

 このように展開された後、中身のデータの切り出しを行います。さらに、文字列の結合などを行い、torのアドレスとURL文字列を作成します。これは、CryptoWallによって暗号化されたことを示す「脅迫文」の中で、アクセス先として利用されているのです(【図117】参照)。

IDA_Cryptowall_Comm2_RecieveData4

【図117-1】受信データから編集されたtorのアドレス

 

IDA_Cryptowall_Comm2_RecieveData5

【図117-2】受信データから編集されたURL

 

 さらに、公開鍵の情報を、CryptAPIで利用するためにX509のバイナリ形式に変換しています(【図118】参照)。

IDA_Cryptowall_Comm2_PublicKey1

【図118-1】公開鍵のバイナリ変換(変換元テキストデータ)

 

IDA_Cryptowall_Comm2_PublicKey2

【図118-2】公開鍵のバイナリ変換(CryptStringToBinaryA API)

 

IDA_Cryptowall_Comm2_PublicKey3

【図118-3】公開鍵のバイナリ変換(変換後バイナリデータ)

 

 最後に、バイナリ部分の変換処理を行っています。このバイナリデータについても変換処理をおこなっていますが、内容的にはこれまで行われてきた独自マップを使う方法とは異なる方法を用いていました。詳しくまでは分析しませんでしたが、BASE64の展開かそれに類する方法のように見受けられます(【図119-1、2】参照)。

IDA_Cryptowall_BASE64_PNG1

【図119-1】受信データのバイナリ部分の展開(展開前)

 

IDA_Cryptowall_BASE64_PNG2

【図119-2】受信データのバイナリ部分の展開(展開後)

 

 この結果、PNG形式のデータが展開されます。この情報を抜き出しでファイルに保存し、拡張子を「PNG」に変更すると、予想通り画像を表示することができました(【図119-3】参照)。内容は図を見てのとおり、CryptoWallによる「脅迫文」の画像です。

IDA_Cryptowall_Comm2_PNGData

【図119-3】受信データのバイナリ部分の展開結果をPNGとして表示した結果

 

 このことから、このランサムウェアを用いて「攻撃する側」は一人である必要はなく、攻撃者各々がそれぞれのtorのアドレス、htmlでのアクセス先を用意し、その案内のためのPNGファイルを用意して、通信文に埋め込むことで、それぞれの攻撃者にアクセスできるようにできることがわかります。つまり、このプログラムの作成者は、不特定多数の攻撃者が利用できるツールにすることを目的としていることが、プログラムの仕組みから分かる、ということです。

 こういった仕組みは、被害の拡大、蔓延を招きます。標的型攻撃で用いられるマルウェアも、異なる攻撃者によって利用されているとみられる話を聞くことがありますが、こういったことを考慮されて作成されている可能性が考えられます。

 では、この後、受信データを用いてどのような処理を行っているのでしょうか?また、受信され、バイナリ変換された公開鍵は、どのように利用されているのでしょうか?さらに解析を進めてみましょう。

 

< CryptoWallの通信(1回目) 目 次 CryptoWallの脅迫文の生成とファイル出力 >