ランサムウェア

知られざるマルウェアファミリ、Vatet、PyXie、Defray777 の詳細

Clock Icon 10 min read

This post is also available in: English (英語)

概要

私たちはセキュリティ実務者として、きわめて大きなダメージをもたらすエクスプロイトを利用したり、膨大な数の被害者に影響を及ぼしたりする攻撃者やマルウェアファミリを長い時間をかけて注視しています。しかし、攻撃者が気付かれることなくゆっくりと行動したらどうなるでしょう。このような攻撃者は、何度も攻撃を仕掛ける脅威グループと比較して、最終的にはより大きなダメージをもたらす可能性があると言えるでしょう。

Vatetローダー、PyXieリモート アクセス ツール(RAT)、およびDefray777ランサムウェアの間に関連がありそうだと弊社が最初に気づいたのは、さまざまなインシデント対応マネージド脅威ハンティングと関わる中で、この3つが揃って現れる形跡や検出結果を見つけたときでした。それぞれのマルウェアファミリを詳細に調査すると、Vatet、PyXie、Defray777はいずれも、2018年には活動を開始していた、金融機関を狙ったのと同じ脅威グループと関連があることが明らかになりました。

この脅威グループは、BlackBerry CylanceではPyXie、SecureWorksではGOLD DUPONTとも呼ばれており、医療、教育、政府、テクノロジなど、多数の分野の組織にダメージを与えたランサムウェア攻撃を実行し、気付かれることなく活動してきました。本稿の狙いは、この脅威グループを解明し、そのマルウェアファミリと攻撃手法の啓発を通じて彼らの攻撃を中断させることです。要するに、このグループの動きを捉えたいのです。

弊社の調査により、この脅威グループがVatetローダーを開発し、メンテナンスしてきたことがわかりました。このローダーの進化と並行して、脅威グループでは、PyXieやCobalt Strikeなどのペイロードを実行するための元のアプリケーションを改変して、複数のオープン ソース ツールを活用していました。次に、脅威グループは、弊社でPyXie Liteと呼んでいるPyXieのカスタマイズ版を使用して、偵察を行い、被害を受けた組織の機密情報と考えられるファイルを見つけて漏出させています。弊社が多数のインシデントを調査したところ、攻撃者は、IcedIDやTrickbotなど、銀行によく仕掛けられるトロイの木馬を使用して、被害者のネットワークに侵入する最初の足がかりを作っていました。攻撃者はその足がかりを利用して、Vatet、PyXie、Cobalt Strikeを展開後に完全にメモリ内だけでDefray777ランサムウェアを実行しました。この結果、ローカルドライブとファイル共有のファイルは、実行終了前に暗号化されます。また、このランサムウェアは、暗号化ファイルと身代金要求文以外には実行の痕跡を残しません。Defray777に関しては、このマルウェアを操るグループも、自分たちのランサムウェアをWindowsからLinuxに移植しており、Defray777が現れる前で同様のものは、標的型ランサムウェアの中ではまだ見つかっていません。Defray777を発見する前は、WindowsとLinuxの両システムに影響を及ぼす能力を持ったランサムウェアは、JavaまたはPythonなどのスクリプト言語で記述された、両システムで機能するランサムウェアに限られていました。Defray777ランサムウェアは、Linuxへの移植により、WindowsとLinux向けにスタンドアロンの実行可能ファイルを持つ最初のランサムウェアの亜種になりました。

3種類のマルウェアファミリすべてを確認すると、考慮すべきコンテンツが数多くあることがわかります。弊社では、各マルウェアファミリの詳細情報を多数入手しておりますが、読者の皆さまは1つのマルウェアファミリに特にご関心をお持ちかもしれませんし、ご自身での調査をご希望かもしれません。ご希望に応じて、以下のリンクから最もご関心の高いマルウェアファミリの説明にアクセスするか、直接IoCをご覧になり、活動を続けるこの脅威グループの捕捉や検出にお役立てください。

目次

最初の記事: Vatetローダー

Vatetは、ローカルディスクまたはネットワーク共有から、XORエンコードされたシェルコードを実行するカスタムローダーです。このローダーは、GitHubやその他のリポジトリにある一般的なオープン ソース アプリケーションですが、攻撃者はこのローダーを変更して自分たちのシェルコードをロードします。ほとんどの場合、ペイロードは最終的にCobalt Strikeのビーコンやステージャーになりますが、最近のペイロードの中にはPyXie RATの更新されたバージョンだったものもあります。Vatetは、エンタープライズ全体に対するランサムウェア攻撃の前触れであることがよくあります。

2020年4月のVatetローダーに関するMicrosoftの記述によると、このローダーは、Cobalt Strikeを実行用のメモリにロードする目的で、2018年の11月には使用されていました。その後このローダーは、以下のようなオープン ソース アプリケーションの複数のバージョンを使用してシェルコードをロードしたのが実際に確認されています。

バージョン 初回確認
再コンパイルされたTetrisゲーム 2019-06-28
再コンパイルされたNotepad 2020-05-03
再コンパイルされたデスクトップ カスタマイズ アプリケーションのRainmeter 2020-06-24
再コンパイルされたNotepad++ 2020-09-24

表1: Vatetのバージョン

弊社の調査では、コンパイル時刻が一番早いもので2019年のVatetサンプルを確認しています。ただし、この亜種は、以降何度か変更されています。

Vatetの最初期のバージョンを分析すると、悪意のあるペイロードは、\\{IP}\{EPOCHTIME}\{PAYLOAD}.datのようなフォーマットのパスを使用し、ネットワーク共有を通じてロードされていました。しかし、分析された最新のサンプルでは、悪意のあるペイロードがディスクからローカルでロードされていました。また、実行中にペイロードをデコードするために使用されるXORキー内の変異を確認しました。弊社の調査ではさらに、VatetローダーがPyXieをロードできるようにペイロード機能を拡大し、さらに最近確認されたCobalt Strikeのビーコンおよびステージャーのロードも可能になったものと判断しました。最後に、弊社が分析したVatetローダーは、悪意のあるペイロードを実行用のメモリにロードした後で消去する、アンチフォレンジック機能を強化する段階へと進化し始めていました。

Vatetの実行フローは、Vatetローダーに始まり、PyXie Liteのロード、またはCobalt Strikeのロードとそれに続くDefray777のロードに分かれます。
図1: Vatet実行フロー

では、Rainmeterの悪意のあるバージョンを使用するVatetを詳細に見ていきます。

Vatetローダー内部の動き: Rainmeterの復習

Rainmeterは、「スキン」を使用してユーザーがデスクトップをカスタマイズできるようにするデスクトップ カスタマイズ ツールです。正規にインストールされたRainmeterは、実行可能ファイルのrainmeter.exeと対応するDLLのrainmeter.dllを作成します。通常、rainmeter.dllは、設定ファイルの読み込みとデスクトップのカスタマイズ支援に対応します。確認された状況では、署名された正規バージョンのrainmeter.exeと悪意のあるバージョンのrainmeter.dllが被害を受けたシステムにコピーされ、Cobalt Strikeビーコンをメモリにロードして実行するために、署名された正規の実行可能ファイルとして使用された可能性があります。

静的特性の確認

弊社はまず、疑わしいrainmeter.exeファイルとrainmeter.dllファイルを確認し、GitHubの公開ページにある、2019年9月に公式にリリースされたRainmeterインストーラを使ってシステムにインストールされるバージョンのRainmeterと、疑わしいファイルを比較しました。

rainmeter.exeを確認したところ、気になることはあまり見つかりませんでした。PEStudioで両方の実行可能ファイルを調査すると、ランサムウェアのシナリオで復元されたサンプルは、標準のRainmeterインストーラによって生成されたものと同じ実行可能ファイルだったことがSHA256ハッシュをもとにわかりました。また、どちらの実行可能ファイルも、同じ有効なデジタル署名を持っていたことも確認しました。

静的特性の初期比較を示すスクリーンショット
図2: 「rainmeter.exe」の静的特性の初期比較

rainmeter.dllのサンプルを比較したところ、多くの気になる点が見つかりました。まず、ハッシュが順番に並んでいなかったため、明らかに2つのサンプルは同じではありませんでした。ファイルのサイズは2つのサンプル間で大きく異なっており、コンパイル日付もまったく別のものでした。また、インポート、エクスポート、文字列、その他のプロパティにいくつかのばらつきがありました。さらに、悪意が疑われるDLLにはデジタル署名がなされておらず、正規のRainmeter DLLでは見られない追加セクションがありました。

rainmeter.dllのサンプルを比較したところ、ここで示すように、多くの気になる点が見つかりました。悪意が疑われるDLLにはデジタル署名がなされておらず、正規のRainmeter DLLでは見られない追加セクションがありました。
図3: 「rainmeter.dll」の2つのバージョンを比較
この図は、rainmeter.dllサンプル間のセクション比較を詳細に表示しています。悪意が疑われるDLLには、正規のRainmeter DLLでは見られない追加セクションがありました。
図4: 「rainmeter.dll」サンプル間のセクション比較

RainmeterのコードベースがGNU General Public License v2.0の適用を受けたGitHubで公開されていることは、留意すべき重要なポイントです。このため、攻撃者が既存のrainmeter.dllファイルコンテンツを公然と確認して変更し、コンパイルして、弊社の調査で確認された悪意が疑われるDLLを作成できたのだと考えられます。

このような比較を完了してRainmeter DLLに悪意がある可能性を確認してから、サンプルをより詳細に調査するため、デバッガを使用して動的分析を行いました。

悪意のあるRainmeterサンプルの動的分析

より詳細な調査を行うサンプルを特定したので、正規のRainmeterアプリケーションとの比較をここで停止し、復元された疑わしいサンプルの分析に着手しました。私たちは、rainmeter.exeのサンプルと、調査によって復元されたrainmeter.dllのサンプルを分析環境に配置し、Rainmeterのデバッグを始めました。予想したとおり、分析を始めてすぐrainmeter.exerainmeter.dllをロードし、その後序数1でエクスポートした関数を呼び出しました。実行を続けると、CreateFileAの呼び出しがあり、このCreateFileAの中でサンプルはハードコードされたパスC:\Windows\help\options.datを探しました。

サンプルはCreateFileAを呼び出して、ハードコードされたパス「C:\Windows\help\options.dat」を探しています。
図5: ハードコードされたパスを探して「CreateFileA」を呼び出し

CreateFileAを呼び出した後、CreateFileA呼び出しの結果とFFFFFFFFを比較し、ファイルに対して有効なハンドルがあるかどうかを判断します。有効なハンドルがない場合は、プログラムを終了します。

元々、悪意のあるRainmeterサンプルの分析にoptions.datが必要であるかどうかははっきりしていませんでした。.datファイルは通常のRainmeterアプリケーションには含まれていないからです。しかし、分析を継続するため、options.datのバージョンを復元しました。想定した場所に「dat」ファイルが配置されると、プログラムはヒープにスペースを割り当ててoptions.datのコンテンツをメモリに読み込みます。options.datのコンテンツがメモリに読み込まれると、サンプルは、コンテンツに対して値FEとのXOR演算を行い、第1段階のデコードを実行します。

options.datのコンテンツがメモリに読み込まれると、サンプルは、コンテンツに対して値FEを使ってXOR演算をを行い、第1段階のデコードを実行します。
図6: 最初のXORデコードループ

最初のデコードルーチンが完了すると、悪意のあるRainmeterアプリケーションはoptions.datに対するハンドルをクローズします。プログラムがoptions.datに対するハンドルをクローズすると、datファイルはファイルシステムから消去されます。これは、分析を目的とした.datファイルの復元を妨げるために利用される、組み込みの分析回避手法です。この時点ではまだ、プログラムに読み込まれたデータは、コードを認識できないBlobの状態です。しかし、XORデコードルーチン終了時のCALL EBX命令によって、直近にデコードされたデータの実行に移ります。その後逆アセンブル表示されたEBXは、このデータが有効なコードであることを示しています。ここまでの分析で、Rainmeterはoptions.datペイロードをデコードし、メモリにロードして実行していました。その後の分析で、これでVatetローダールーチンは終了し、実行がCobalt Strikeシェルコードローダーに移ったことを確認しました。

XORデコードルーチンの終了時に、CALL EBX命令によって、直近にデコードされたデータの実行に移ります。このデータは有効なコードです。その後の分析で、これがVatetローダールーチンの終了だったことを確認しました。
図7: XORデコード後の有効なコードの実行に移行

この時点で、Vatetのローディングメカニズムが完了したことはわかりましたが、最後のペイロードのIDを検証したかったので分析を続けました。実行がさらに進むと、2番目のデコードルーチンがあり、別の動的XORループを使用して実行可能コードのコンテンツをデコードし、書き換えていました。このルーチンに覚えのある方は、Cobalt Strikeのデコードメカニズムにお気付きかもしれません。このルーチンではまず、インポートされた実行可能コードの最初の4バイトに対するポインタを取得し、最初のXORキーにセットします。次にこのコードは、1度に4バイトを処理するループを実行し、最初のXORキーを使用してインポートされたコードにXOR演算を実行します。ループは次に、XOR演算後の値をデータセグメントに戻し、続いて新しいXORキーをセットします。新しいXORキーは、現在のキーでデコードされた値を使用して現在のXORキーに対してXOR演算を実行することで決定されます。このループが終了すると、サンプルはJMP ECXを使用して、直近にデコードされた実行可能なコンテンツに実行を移します。

Vatetローダーの2番目のデコードルーチンでは、別の動的XORループを使用して、実行可能コードのコンテンツのデコードと書き換えが行われます。
図8: 2番目のデコードループの開始。ダンプ1のメモリ領域に注目。
Vatetローダーの2番目のデコードルーチンが完了したら、ダンプ2のデコードされた実行可能なコンテンツに注目してください。
図9: 2番目のデコードルーチンの完了後、ダンプ2のデコードされた実行可能なコンテンツに注目。

ここまでの分析で、options.datに含まれるコンテンツはシェルコードであり、その後動的XORルーチンでデコードされ、Rainmeterのプロセスメモリの実行可能コードを作り出すことを確認しました。

こうして、メモリで利用できるoptions.datから、XOR演算処理された実行可能コードによる実行可能なコンテンツを確保できたので、x64bdg内のメモリ マップ セクションのコンテンツをダンプに出力し、このコードの機能を明らかにするため分析を進めます。

実行可能コードのサンプルのダンプに移動し、動的分析の結果との明らかな相関が見られるかどうかを判断するため、文字列の分析を行いました。この分析の中で、beacon.dllの参照を確認しました。このDLLは、ほとんどの場合、Cobalt StrikeビーコンのDLLバージョンに対応付けられます。さらに、分離されたPEをPeStudioにロードしたところ、エクスポート関数の_ReflectiveLoader@4を続いて参照していることが示されました。この関数は、Cobalt Strikeの既知のエクスポート関数です。

分離されたPEをPeStudioにロードしたところ、エクスポート関数の_ReflectiveLoader@4を参照していることが示されました。この関数は、Cobalt Strikeの既知のエクスポート関数です。
図10: PeStudioで抽出されたPEを分析

抽出されたペイロードがCobalt Strikeビーコンであるかどうかを確認するために、Cobalt Strikeビーコンの解析ツールを使用し、ビーコンの設定をデコードしてダンプを取得しました。

デコードが完了して確認したところ、このCobalt Strikeビーコンから、適応性の高いC2プロファイルを使用するCobalt StrikeのHTTPSビーコンが標準的な方法で実装されていることが示されています。
図11: Cobalt Strikeビーコンの設定

確認されたCobalt Strikeビーコンから、適応性の高いC2プロファイルを使用するCobalt StrikeのHTTPSビーコンが、標準的な方法で実装されていることが示されています。具体的には、このビーコンでは、harmjoyによって作成されたAmazon browsing traffic profileが使用されていました。

続きを読む: 次の記事: 「PyXie Lite」

Enlarged Image