脅威の調査

ESXiサーバーを暗号化するPythonランサムウェアスクリプト

設定ミスが仮想マシンのハイパーバイザーへのランサムウェア攻撃に発展

** 本記事は、Python ransomware script targets ESXi server for encryption の翻訳です。最新の情報は英語記事をご覧ください。**

最近の調査により、仮想マシンのハイパーバイザー上で不正な Python スクリプトを実行してすべての仮想ディスクを暗号化し、標的組織全体の仮想マシンを無効化するランサムウェア攻撃が発見されました。

今回の攻撃において、最初の侵害からランサムウェアのスクリプトが展開され、VMware ESXi サーバー上の仮想ディスクが暗号化されるまでの間、攻撃者が標的のネットワーク上留まったのはたったの 3 時間あまりでした。過去にソフォスが調査した中で最も素早い攻撃の 1 つです。

ランサムノート (身代金要求文書) を埋め込む Python スクリプト

攻撃者はまず、標的のネットワークでドメイン管理者の資格を持つユーザーのコンピューター上でバックグラウンド実行されている TeamViewer の (多要素認証が設定されていない) アカウントにログインし、攻撃の足場を固めました。アカウントへのログインは標的組織での現地時間午前 0 時 30 分に行われ、その 10 分後には Advanced IP Scanner というツールがダウンロードおよび実行され、ネットワーク上の攻撃対象が特定されました。

午前 2 時前、攻撃者は Bitvise と呼ばれる SSH クライアントをダウンロードし、このクライアントを利用して Advanced IP Scanner で特定した VMware ESXi サーバーにログインしました。ESXi サーバーには ESXi Shell と呼ばれる、管理者が任意で有効化できる SSH サービスが組み込まれています。このサービスは通常、デフォルトで無効になっています。

この組織の IT 管理者は普段から ESXi Shell を使ってサーバーを管理しており、攻撃を受ける前の 1 か月間にシェルの有効化および無効化を何度も繰り返していました。しかしながら、この管理者は攻撃を受ける直前にシェルを有効化した際に、再び無効化するのを忘れていたようです。攻撃者はシェルが有効になっていることに気づき、この状況を利用しました。

Python で書かれたランサムウェア

攻撃者はネットワークをスキャンしてから 3 時間後に、取得した認証情報を使って ESXi Shell にログインし、fcker.py というファイルを ESXi データストアにコピーしました。このデータストアには、ハイパーバイザー上で動作する仮想マシンが使用する仮想ディスクイメージが格納されていました。

この Python スクリプトは、ESXi Shell の vim-cmd コマンドを使ってサーバーにインストールされているすべての仮想マシンのリストを作成し、それらのマシンをすべてシャットダウンします。

攻撃者は、各データストアディスクボリュームのパスを引数として Python スクリプトに渡し、それぞれのボリュームに対して実行しました。
各ボリュームには複数の仮想マシン用の仮想ディスクと設定ファイルが格納されていました。

攻撃者は Python スクリプトを削除する直前に別のデータで上書きしていましたが、綿密な調査の結果、Rapid Response チームは Python スクリプトのコピーを復元しました。

わずか 6KB しかないこのスクリプトは、そのサイズからは想像できないほど強力です。このスクリプトでは、攻撃者が複数の暗号化鍵や電子メールアドレス、および暗号化されたファイルに付加されるファイル拡張子を変数として自由に設定できます。

このスクリプトには、暗号化されたファイルに付加するファイル拡張子 (ext) と、身代金支払いのため攻撃者に連絡する際に使用する電子メールアドレス (mail、mail2) が変数として埋め込まれています。

このスクリプトはまずデータストアのファイルシステムを「散策」してドライブのディレクトリマップを作成し、ハイパーバイザー上のすべての仮想マシンの名前のリストを vms.txt という名前のファイルに書き込みます。その後、ESXi Shell のコマンド vim-cmd vmsvc/power.off に仮想マシンの名前を引数として渡し、このコマンドを各仮想マシンに対して 1 回ずつ実行します。仮想マシンの電源が切れた後、スクリプトはデータストアボリュームの暗号化を開始します。

このスクリプトは暗号化するファイルごとに関数を実行し、オープンソースのツールである openssl を起動して、以下のコマンドでファイルを暗号化します。

openssl rsautil -encrypt -inkey pubkey.txt  -pubin -out [ファイル名].txt
Python スクリプト内のファイル暗号化関数

暗号化を終えると、スクリプトは元のファイルの内容を fuck という単語で上書きし、削除します。さらに、ディレクトリのリストおよび仮想マシンの名前を含むファイルやスクリプト自体も、上書きした後で削除します。

暗号化鍵の逐次作成

今回調査対象となった Python スクリプトには、ハードコードされた複数の暗号化鍵と、さらに多くの暗号化鍵のペアを生成するルーチンが組み込まれています。通常のランサムウェア攻撃では、攻撃者は自分のマシンで作成した「公開鍵」を埋め込み、標的のコンピューター上のファイルの暗号化に使用します。しかし、このランサムウェアは実行されるたびに固有の鍵を作成するようです。

Python で書かれたランサムウェアに埋め込まれた公開鍵

一体どのような操作がされているのでしょうか。

攻撃者は暗号化したい ESXi データストアごとにスクリプトを実行しており、ランサムウェアはその度にファイルの暗号化に使用される固有の鍵ペアを生成していました。今回調査した例では、攻撃者は 3 つのデータストアを標的としてスクリプトを個別に実行していたため、データストアごとに 1 つずつ、計 3 つの固有の鍵ペアが作成されました。

異なる ESXi データストアに対してスクリプトが実行されるたび、固有の暗号化鍵が生成されます。 (ESXi データストアのパスにはモザイクがかけてあります。)

スクリプトには、生成した鍵をどこかに送信する機能はなく、攻撃者が生成された鍵を予測する方法もありません。そのため、秘密鍵 (攻撃者がファイルを復号する際に必要な鍵) のコピーは標的のコンピューターのファイルシステム上に残しておく必要があります。しかし、秘密鍵をそのまま放置してしまうと、その鍵が発見された場合、被害者は身代金を支払わずにすべてのファイルを復号できてしまいます。そのため、スクリプトは生成した秘密鍵のコピーを書き出した後、埋め込まれたハードコードされた公開鍵を使って暗号化を行います。

このスクリプトは、実行時に指定されたパスに存在するすべてのファイルをリストアップする処理を実行します。各ファイルに対して、スクリプトは aeskey と名付けられた固有の 32 バイトのランダムコードを生成します。このランダムコードをソルトとして使用してファイルが暗号化され、/tmp というパスに格納されます。

最後に、暗号化されたファイルの先頭に aeskey の値を付加し、ファイル名に新しい拡張子を追加します。暗号化前のファイルは中身を「fuck」という単語で上書きしてから削除され、暗号化されたものが /tmp から元のファイルが保存されていたデータストアの場所に移されます。

ハイパーバイザーが狙われる理由

ESXi に搭載されているような Linux ライクの OS 上で動作するマルウェアはまだ比較的珍しいものですが、その分 IT 管理者がサーバーにエンドポイント保護をインストールしていることも稀です。ハイパーバイザーは、ビジネスに不可欠なサービスや機能を実行する仮想マシンをホストしていることが多いため、この種の攻撃にとって非常に魅力的な標的になります。

ESXi 管理ツールでは、ツール内から、またはサーバーに接続されたコンソール上で、ESXi Shell を有効化/無効化することができます。ESXi Shell はデフォルトでは無効になっています。

ESXi やその他のハイパーバイザーをネットワーク上で運用している管理者の方は、セキュリティのベストプラクティスに従い、パスワードの使い回しを避け、複雑で総当たり攻撃が困難な、適切な長さのパスワードを使用してください。また、可能な限り多要素認証を使用し、ドメイン管理者などの強い権限を持つアカウントには多要素認証を強制してください。

ESXi では、マシン本体に接続されたコンソール、または VMware が提供する通常の管理ツールを通じて ESXi Shell のオン/オフを切り替えることができます。システム管理者は、従業員が使用する間のみシェルを有効にし、メンテナンス (パッチのインストールなど) が完了したらすぐに無効にするなどの対策を取る必要があります。

また、VMware 社は、ESXi ハイパーバイザーの管理者向けに、セキュリティを確保し、ハイパーバイザー上での攻撃を抑止する方法についてのベストプラクティスを公開しています。

この種の Python スクリプトはソフォスのエンドポイント保護製品では Troj/Ransom-GJR として検出されます。

謝辞

SophosLabs は今回の調査への貢献に対し、Rajesh Nataraj、Andrew O’Donnell、および Mauricio Valdivieso に謝意を表します。