Auroraランサムウェアのハッカー集団、Cursor AIエージェントをハンズオン侵害とESXi攻撃に悪用

Auroraランサムウェアの運用者らが、Claude Sonnetを搭載したCursor Agentを使い、10の被害組織にまたがるハンズオン侵入活動を支援していたことが判明しました。同時に、VMware ESXi環境を破壊するために特化して作られたLinux用暗号化ツールも展開していました。

今回の調査結果は、ランサムウェアのアフィリエイトが単独の攻撃手段としてではなく、確立された侵害後のワークフローにエージェント型AIを組み込んでいる実態を浮き彫りにしています。

今回明らかになった環境からは、この攻撃者が使用するツール群や攻撃のワークフロー、そしてESXi対応のランサムウェア検体「encrypt.out」(SHA-256: a4af136d159a8eb96b54924fa80355ca52874913301300f55af7d67ae97edcfe)の実態を確認できました。

2026年4月8日から5月21日にかけて、Auroraの運用者は複数の被害組織の環境において、claude-4.5-sonnet-thinkingを搭載したCursor Agentを使用していました。

攻撃者はエージェントに対して、有効な認証情報や既存の侵入経路(SOCKSベースのアクセスを含む)を与えた上で、偵察、権限評価、内部スキャン、そしてエクスプロイトの実行を指示していました。

復元されたセッションからは、この運用者がAIを反復的な技術アシスタントとして利用していたことがうかがえます。ある場面では、攻撃者はユーザーの実効権限の特定など、大まかな質問を投げかけていました。

別の場面では、特定の攻撃用ツールの使用や、あらかじめ組まれた攻撃計画に沿った作業をエージェントに直接指示していました。

エージェントがタスクを成功させるまでには複数回のコマンド修正が必要になることが多く、実行や意思決定の主導権は依然として人間の運用者側にあったことがうかがえます。

確認されたタスクには、VPNクライアントとProxyChainsの展開、NmapおよびNetExecを使った内部ネットワークのスキャン、BloodHoundによるActive Directory情報の収集などが含まれていました。

また、PetitPotam、Coerce Plus、PrinterBugを用いたNTLMリレー攻撃の試行や、CertipyによるActive Directory証明書サービス(AD CS)攻撃も確認されています。

この運用者は、DCSyncを実行しないこと、アカウントロックアウトを避けること、ドメインへのコンピューターオブジェクトの追加を控えることをAIに繰り返し指示していました。これは検知リスクを下げ、暗号化前の破壊的な変更を防ぐことを狙った運用上の制約とみられます。

AuroraのLinux用ペイロードはCloudflare R2上でホストされており、被害組織内部のホストへ手動でコピーされていました。このマルウェアはChaCha20を使ってデータをその場で暗号化し、各セッションキーは組み込みのRSA-4096公開鍵で暗号化します。

ダウンロード参考アプリ

コマンドラインオプションでは、部分暗号化、ファイルサイズの上限設定、ワーカースレッド数の制御、対象フォルダーの指定、そして専用の-esxiモードに対応しています。

Gambit Security社の脅威インテリジェンスチームが発見したCursorの関連インフラは、2026年4月頃から活動しており、公開のデータリークサイトを運営しているAuroraの活動に関連したものでした。

Cursor AI搭載ランサムウェア

ESXiオプション付きで実行されると、encrypt.outはesxcli vm process listを実行して稼働中のゲスト仮想マシンを列挙し、そのWorld IDを取得します。

NetExecによるLDAPおよびSMBの探索、パスワードポリシーの取得、ASREPRoasting、Kerberoasting——毎回同じ手順、同じ出力ファイルの命名規則が用いられていました。

その後、esxcli vm process kill –type=force –world-id=<world-id>を通じて各ゲストを強制終了し、仮想ディスクファイルのロックを解除した上で暗号化します。標的となるファイルには、VMDK、VMX、VMSD、VMSN、NVRAM、VMEM、VSWP、およびログファイルが含まれます。

注目すべきは、このマルウェアがBOOTBANK*やOSDATA*といったESXiのシステムボリュームを避けている点です。この選択によってハイパーバイザー自体は起動可能な状態のまま残り、管理者は仮想マシンがオフラインになった後もホストにアクセスでき、そこで脅迫文を目にすることになります。

Auroraは/etc/ssh/sshd-bannerに身代金要求メッセージを書き込み、SSHログインプロンプトの前に管理者へ提示します。

また、このグループはカスタムのNetExec LDAPモジュールであるesxi_finder.pyを使い、ESXiおよびvCenterのインフラを発見していました。

このモジュールは、Active Directoryまたは運用者が指定したIPレンジのリストを通じて内部サブネットを特定し、ポート443と902をスキャンして、ESXiの署名がないかTLS証明書を調べ、/sdk、/ui/、rootパスに問い合わせることでVMware製品と正確なビルドバージョンを特定します。

CloudSEK社による別の調査では、露見したディレクトリから、4月から7月にかけて9カ国20組織以上を標的にしていたロシア語圏のAuroraアフィリエイトとの関連が確認されています。

このディレクトリには、認証情報、Kerberosチケット、シェル履歴、Cursorのチャットログ、カスタムのNetExecモジュール、そして共通のZigコードベースからコンパイルされたWindows版・Linux版のAuroraロッカーが含まれていました。ここで記録されていた4件の被害組織は、後にAuroraのリークサイトにも掲載されています。

CloudSEKとTRM Labsは、共通のマネーロンダリング用インフラを通じて、決済が完了した被害組織の支払いも追跡しました。その結果、Aurora被害者による確認済みの支払いが2件、さらに別の被害組織のものと見られる資金の流れが2件確認されています。

これらの証拠は、この攻撃者が単にネットワークアクセスを仲介する存在ではなく、アクセス取得とドメイン侵害からデータ窃取、暗号化、そして脅迫へと一貫して手を下す、直接的なランサムウェアのアフィリエイトとして活動していたとの見方を裏付けています。

ダウンロード参考アプリ

今回のキャンペーンは、ESXiプラットフォーム、Active Directory証明書サービス、バックアップインフラ、そしてリモート管理経路を、ランサムウェアによる侵害の優先度が高いポイントとして扱う必要性を浮き彫りにしています。

組織は、管理ネットワークの隔離、SSHおよびESXiアクセスの制限、esxcli vm process killの動作監視、SMB署名とExtended Protection for Authenticationの強制、そしてAD CSテンプレートにおけるESC1、ESC6、ESC8の設定不備の監査を行うべきです。

Auroraの運用モデルは、より大きな懸念も改めて浮き彫りにしています。AIエージェントは侵害後の反復作業に要する時間とスキルの敷居を下げることはできますが、盗まれた認証情報や有効なアクセス経路、そして従来型の攻撃用ツールへの依存をなくすわけではありません。

今回のケースでは、AIという要素が、Active Directoryの侵害、ラテラルムーブメント、データ窃取、そして仮想化層の破壊を軸に構築された、すでに成熟したランサムウェアのワークフローを加速させる役割を果たしていました。

IOC(侵害指標)

注: IPアドレスおよびドメインは、意図しない名前解決やハイパーリンク化を防ぐため、意図的に無害化表記(例: [.])としています。再有効化は、MISP、VirusTotal、SIEMなど管理された脅威インテリジェンス基盤上でのみ行ってください。

★ どのセキュリティツールを削減すべきか? 1ページで診断 – 「引き継いだセキュリティスタック」ガイドをダウンロード

比較セキュリティシステム