CryptoWallの「本丸」と思われるプログラムの展開まで発見することはできましたが、このプログラムはどのように扱われるのでしょうか?【表1】を見ると、展開後は[01042]でVirtualProtectを実行した後、早くもRtlZeroMemoryとVirtualFreeを行っており、メモリをクリアして開放してしまっています。ということは、この間に展開されたコピーをどこかに出力しているはずです。
ここで、VirtualProtectのパラメータを見てみると、「コミット済みページ領域アドレス = 0x00400000 (exe本体)、希望アクセス保護 = 0x00000004 (PAGE_READWRITE)」があることに気づきます。ここから、出力先はexeの領域のどこかではないか、ということが疑われます。そのため、VirtualProtectの後の処理を追いかけてみましょう。
Step overで順に実行し続けると、すぐに怪しい処理が見つかりました。[01060]で「rep stosb」を行っていますが、このときのediの値が0x00400000で、実行プログラムのある場所を指しているのです(【図53】参照)。そのため、このプログラムが起動したときの本体の領域が0クリアされてしまいます(【図54】参照)。
さらに進めていくと、今度は[01081]で「rep movsb」の処理を行っていました(【図55】参照)。コピー元のesiが先ほどRtlDecompressBufferで展開されたデータのアドレス、コピー先のediが0x0040000で実行プログラムの先頭を指しています。実行すると、ecxのサイズ分(0x0400)コピーされることが確認できます(【図56】参照)。
さらに続けて実行すると、[0111E]でもまたメモリの領域からプログラム本体の領域へのコピーがありました(【図57】、【図58】参照)。この処理はループで数回繰り返されており、メモリへのプログラムの展開を擬似的に自分で行っているように見えます。
【図57】rep movsbによるコピー前の状態([0111E]の箇所)
【図58】rep movsbによるコピー後の状態([0111E]の箇所)
試しに、0x00400000に展開されたプログラムを、先ほどと同様にファイルに出力し、IDA Proで解析してみました(【図59】参照)。Importテーブルは空ですが、Exportテーブルには、プログラムのスタート箇所が1つだけありました。そのアドレスは、0x00413C10。【表1】の処理の最後のあたりで、自身のスレッドを終了する前に行うCreateThreadで起動する、プログラムの実行アドレス「スレッドの機能」の指し示すアドレスと一致するのです。ただし、コードの実行部分のパースは、あまり上手くいかないようです。
【図59】展開後のプログラムを抜き出してIDA Proで解析した結果
では、CreateThreadで実行されるCryptoWallの「暗号化」処理をはじめとする処理への遷移を追ってみましょう。
< 新たな仮想メモリに展開された情報の内容 | 目 次 | 新しいスレッドの追跡 > |