31秒で失敗を修正 考えながらランサムを仕掛けるAI攻撃者の実態：侵入から暗号化まで、攻撃の全貌

Sysdigは、侵入から内部探索、権限奪取、ランサムウェア実行までをLLM主導で進めたと可能性が高い攻撃を報告した。特に研究者が注目したのは、人間の判断では難しい速度で失敗を修正しながら攻撃を続けた点だ。従来の自動化とは何が違うのか、その実態を追う。

[＠IT]

　クラウドセキュリティベンダーSysdigは2026年7月1日（米国時間）、LLM（大規模言語モデル）がランサムウェア攻撃を自律的に実行した可能性が高い事例について報告した。

　脅威リサーチチーム「Sysdig Threat Research Team」（TRT）は、この攻撃者を「JADEPUFFER」と命名。JADEPUFFERは、インターネットに公開されていたオープンソースのローコード開発プラットフォーム「Langflow」環境の脆弱（ぜいじゃく）性（CVE-2025-3248）を悪用して侵入し、最終的に本番データベースサーバに到達したという。

　Sysdigは同攻撃について、人間が個別に操作する従来型ではなく、AIエージェントが侵害後の判断や操作を担う「エージェント型脅威アクター」によるものと分析している。

31秒で失敗の修正から再実行まで完了　考えながら侵入するAI脅威アクター

　Langflowは、LLMアプリケーションやAIエージェントのワークフローを構築するためのオープンソースフレームワークだ。CVE-2025-3248はコード検証エンドポイントの認証不備により、未認証の攻撃者がホストで任意のPythonコードを実行できる脆弱性である。

　Sysdigによると、LangflowサーバはAPIキーやクラウド認証情報など機密情報を保持していることが多い一方、短期間で構築され、十分なネットワーク制御が施されないままインターネットに公開されるケースもある。そのため、攻撃者にとって格好の侵入口になりやすい。

　観測された攻撃は2段階で進行した。

　第1段階では、JADEPUFFERがLangflowホストでシステム情報を収集した後、LLMサービスのAPIキーやクラウド認証情報、データベース認証情報、暗号資産ウォレット、設定ファイルなどを広範囲に探索した。Langflowが利用する「Postgres」データベースから保存済み認証情報やAPIキーなどを取得し、一時的にローカルに保存して内容を確認した後、削除する動きも確認された。

　その後は内部ネットワークの探索を進め、データベースやオブジェクトストレージ、シークレットストアなどへのアクセスを試行した。特に「MinIO」に対しては既定認証情報で接続を試み、バケットや設定ファイルを探索。最初はJSON形式で応答を取得しようとして失敗したが、直後には「Amazon S3」互換APIのXML形式に合わせて取得方法を変更して再試行した。Sysdigは、このように環境の応答に合わせて処理方法を即座に切り替えた点を、自律性を示す根拠の一つとして挙げている。また、Langflowホストには30分ごとに攻撃者インフラに接続するcronジョブも追加されていた。

　第2段階では、攻撃対象が別のインターネット公開サーバに移った。標的サーバでは「MySQL」と「Nacos」が稼働しており、JADEPUFFERは取得済みのroot認証情報を使いMySQLへの接続を試みた。ただし、その認証情報をどこで入手したかは確認できなかったという。

　続いてNacosに対し、認証回避や既知のJWT署名鍵を利用したトークン偽造、MySQLへの直接書き込みなど複数の手法を並行して試した。

　特にSysdigが注目したのは、管理者アカウント作成時の挙動だ。最初に投入したペイロードではbcryptハッシュを生成して管理者アカウントを登録したが、ログイン検証は失敗した。しかし31秒後には失敗原因を考慮した修正版のペイロードが投入され、既存アカウントを削除した上で、より単純なパスワード「admin123」を利用した管理者アカウントを再登録。その直後のログイン検証は成功した。

　失敗から原因の推定、修正版の生成、再実行までが約31秒で完了しており、Sysdigは、人間がエラー内容を確認し、原因を分析して修正版スクリプトを作成したと考えるには短過ぎる時間だと指摘している。

　その後も攻撃は、MySQLのファイル操作機能を利用したコンテナ脱出の可能性を調査するなど状況に応じて探索を継続した。テスト用テーブルを作成・削除した他、必要な確認を終えると完了マーカーを書き込むなど、固定スクリプトではなく、その場の状況に応じて目的達成に向けて行動する構造化されたAIエージェントの特徴が見られたとSysdigは分析している。

復旧させる気なし？　自律実行されたランサムウェアの手口とは

　最終段階では、Nacosが管理する1342件の設定データがMySQLの「AES_ENCRYPT()」関数で暗号化され、元の設定テーブルと履歴テーブルが削除された。さらに「README_RANSOM」という脅迫文テーブルが作成され、Bitcoinによる支払い先や「Proton Mail」の連絡先が記録されていた。

　脅迫文ではAES-256による暗号化を主張していたものの、Sysdigによると、実際に使用されたMySQLのAES_ENCRYPT()関数は既定設定ではAES-128-ECBを利用するため、記載内容は実態より強い表現だった可能性があるという。一方で、暗号鍵はUUIDv4を基に生成され、一度標準出力に表示された後は保存も外部送信もされなかったことから、身代金を支払ったとしても復旧できない可能性が高いと分析している。

　その後、攻撃はデータベース全体の削除に移行した。ペイロードには「価値が高いデータベースを削除する」といった趣旨のコメントや、IPアドレス「64.20.53[.]230」にバックアップ済みとする記述も含まれていた。ただしSysdigは、実際にデータが外部送信された証拠は確認していないとしている。また、DROP DATABASEが外部キー制約によって失敗すると、次のペイロードではFOREIGN_KEY_CHECKSを無効化して削除を成功させるなど、状況に応じた処理の変更も確認された。

　Sysdigは、自己説明的なコードの生成、失敗時の高速な原因分析と修正、自然言語による文脈理解に加え、600件を超える目的指向のペイロードを短時間で生成・実行した点などから、JADEPUFFERはLLMが攻撃の中心的な役割を担った事例である可能性が高いと評価している。

　対策としてSysdigは、Langflowを修正済みバージョンに更新することに加え、コード実行エンドポイントをインターネットに公開しないこと、AI関連サーバから認証情報を分離すること、Nacosの既定鍵を変更して外部公開を避けること、データベース管理ポートを公開しないこと、外向き通信の監視やcronジョブなど異常な永続化の検知を徹底することを推奨している。