新しい ESXiArgs ランサムウェア バージョンにより、VMware ESXi の回復が妨げられる

新しい ESXiArgs ランサムウェア攻撃は現在、より大量のデータを暗号化しているため、暗号化された VMware ESXi 仮想マシンを復元することは、不可能ではないにしても、はるかに困難になっています。

先週の金曜日、大規模かつ広範な自動化されたランサムウェア攻撃が、新しい ESXiArgs ランサムウェアを使用して、インターネットに公開された 3,000 を超える VMware ESXi サーバーを暗号化しました。

予備レポートでは、古い VMware SLP の脆弱性を使用してデバイスが侵害されたことが示されました。ただし、一部の被害者は、デバイスで SLP が無効になっているにもかかわらず、侵害されて暗号化されていると述べています。

デバイスを暗号化するとき、「encrypt.sh」スクリプトは、次の拡張子に一致する仮想マシン ファイルを探します。

.vmdk .vmx .vmxf .vmsd .vmsn .vswp .vmss .nvram .vmem

見つかったファイルごとに、スクリプトはファイル サイズをチェックし、ファイルが 128 MB より小さい場合は、ファイル全体を 1 MB ずつ暗号化します。

ただし、128 MB を超えるファイルの場合は、「size_step」を計算します。これにより、暗号化プログラムは 1 MB のデータを暗号化するか、チャンク (メガバイト単位の size_step) を暗号化しないかを交互に実行します。

encrypt.sh スクリプトは、次の式 (読みやすくするために少し変更されています) を使用して、使用する size_step を決定します。

size_step=((($size_in_kb/1024/100)-1))

これは、4.5 GB のファイルの場合、「45」の size_step を生成することを意味し、エンクリプターはファイルの 1 MB の暗号化とファイルの 45 MB のスキップを交互に行います。ご覧のとおり、ファイルの暗号化が完了するまでに、かなりの量のデータが暗号化されていないままになっています。

450GB ファイルのようなさらに大きなファイルの場合、スキップされるデータの量が劇的に増加し、size_step が「4607」になり、1MB の暗号化と 4.49 GB のデータのスキップが交互に行われます。

これらの暗号化されていないデータの大きなチャンクのために、研究者は、仮想マシンのディスク データが格納されている、大規模で主に暗号化されていないフラット ファイルを使用して、仮想マシンを回復する方法を考案しました。

その後、CISA によって作成されたスクリプトにより、この回復プロセスが自動化されました。

暗号化プロセスが変更されました

残念ながら、今日、第 2 の ESXiArgs ランサムウェアの波が始まりました。これには、大きなファイル内のはるかに多くのデータを暗号化する、変更された暗号化ルーチンが含まれています。

管理者が ESXiArgs のサポート トピックに、サーバーが暗号化されており、以前は機能していた方法を使用して回復できなかったと投稿した後、第 2 波を初めて知りました。

サンプルを と共有した後、encryptor は変更されていないことに気付きましたが、encrypt.sh スクリプトの「size_step」ルーチンが取り除かれ、新しいバージョンでは単純に 1 に設定されていました。

この変更は、攻撃の最初の波での元の encrypt.sh size_step 計算 (左) と、2 番目の波での新しいシェル スクリプト (右) との比較で以下に示されています。

ランサムウェアの専門家であるMichael Gillespie氏は、この変更により、暗号化プログラムは 1 MB のデータの暗号化と 1 MB のデータのスキップを交互に行うようになると語っています。

128 MB を超えるすべてのファイルは、データの 50% が暗号化され、回復不能になる可能性があります。

この変更により、以前のリカバリ ツールではマシンを正常にリカバリできなくなります。これは、フラット ファイルに暗号化されたデータが多すぎて使用できないためです。

この攻撃の第 2 波では、以下に示すように、身代金メモにビットコイン アドレスが含まれないようにすることで、身代金メモにも小さな変更が加えられました。

ビットコイン アドレスが削除されたのは、セキュリティ研究者が身代金の支払いを追跡するために収集したためと考えられます。

しかし、さらに懸念されるのは、新しいサンプルを共有した管理者が、サーバーで SLP を無効にしたにもかかわらず、再び侵害されたと述べたことです。また、以前の攻撃で確認された vmtool.py バックドアもチェックしましたが、見つかりませんでした。

SLP が無効になっていると、このサーバーがどのように侵害されたかがさらにわかりにくくなります。

CISA のリカバリ スクリプトを使用して、暗号化された ESXi サーバーのリカバリを試行することを引き続き推奨しています。

ただし、新しい暗号化ルーチンを使用した攻撃の第 2 波に感染した場合は、機能しなくなる可能性があります。

ESXiArgs ランサムウェアについて質問がある場合やサポートが必要な場合は、フォーラムに専用のサポート トピックがあります。