AIが31秒で攻撃を自己修正した。初のエージェント型ランサムウェア記録

ランサムウェア攻撃は、キーボードの前に人がいることを前提に成り立ってきた。クラウドセキュリティ企業Sysdigが7月1日に公開した報告書は、その前提が崩れた最初の記録を提示している。

ログインに失敗してから31秒後

Sysdigの脅威調査チーム（TRT）がJadePufferと名付けた攻撃者は、LLMエージェントだった。偵察、認証情報の窃取、横展開、永続化、権限昇格、データの暗号化と破壊。ランサムウェアの全工程を、人の介在なく実行した。

この攻撃の性質がよく表れているのが、Alibaba Nacosサーバへの侵入過程で記録された一連の動作だ。

エージェントはまず、MySQLデータベースに直接アクセスしてバックドア管理者アカウントを作成した。bcryptハッシュを生成し、アカウントを挿入し、管理者ロールを付与する。ここまでは典型的な攻撃手順に見える。

問題は次に起きた。ログイン検証が失敗した。12秒後、エージェントは2つの仮説を並行して検証し始めた。Nacosのデフォルト認証情報（nacos:nacos）の試行と、より単純なパスワードでのbcryptハッシュ再生成を同時に実行している。さらに19秒後、エージェントは原因を特定した。subprocess.run()経由でのハッシュ生成が、PATHの問題で空文字列を返していた。修正ペイロードはbcryptライブラリの直接インポートに切り替え、バージョン確認、既存アカウントの削除、正しいハッシュでの再挿入までを1つのコードにまとめて実行した。

失敗したログインから、原因の診断、複数の修正案の検証、正しいペイロードの送信まで、31秒。15行のコードが、PATHの不備というOSレベルの問題を特定し、修正した。攻撃者がエラーメッセージを読み、原因を推定し、修正スクリプトを書いて送信する時間とは比較にならない。

攻撃はリアルタイムで適応し、修正されたパラメータで失敗した手順を再試行した。あるシーケンスでは、失敗したログインから修正完了まで31秒だった（Sysdigのブログ）

このパターンは31秒の一場面に限らない。MinIOオブジェクトストアの列挙では、APIリクエストがXMLを返すとJSONパーサーの代わりにXMLパーサーへ即座に切り替えた。JWT（JSON Web Token）トークンの偽造が失敗すると、そのアプローチ自体を放棄して別の攻撃経路に移行した。データベース削除がテーブル間の外部キー制約で失敗すると、次のペイロードでSET GLOBAL FOREIGN_KEY_CHECKS=0を追加してから再実行した。いずれも、失敗の原因に応じた的確な対処であり、単純なリトライとは異なる。

攻撃経路の全体像

JadePufferの侵入口は、CVE-2025-3248だった。LLMアプリケーション構築用のオープンソースフレームワークLangflowに存在する認証不備の脆弱性で、CVSSスコアは9.8。コード検証エンドポイントに認証が実装されておらず、未認証の攻撃者が任意のPythonコードを実行できる。Langflowは2025年3月31日リリースのバージョン1.3.0で修正済みであり、同年5月にはCISA（米国サイバーセキュリティ・インフラストラクチャ安全保障庁）がKEV（悪用が確認された既知の脆弱性）カタログに追加している。

修正から1年以上が経過しているにもかかわらず、インターネットに露出したLangflowインスタンスは依然として多数存在する。AIワークフローの試作環境として立ち上げられ、プロバイダーのAPIキーやクラウド認証情報がそのまま残されたサーバが、攻撃の起点になった。

Langflowへの侵入後、エージェントの行動は組織的だった。Base64エンコードされたPythonペイロードをRCE（リモートコード実行）エンドポイント経由で送り込み、ホストの偵察を開始する。

システム情報の収集、環境変数の走査、LLMプロバイダーのAPIキー（OpenAI、Anthropic、DeepSeek、Geminiなど）の探索、クラウド認証情報の収集を並行して実行した。対象にはAWSやGCPだけでなく、Alibaba、Aliyun、Tencent、Huaweiなど中国系プロバイダーのキーも含まれている。

次にLangflowのバックエンドであるPostgreSQLデータベースをダンプし、保存されていた認証情報やユーザー記録を抜き取った。MinIOオブジェクトストアに対してはデフォルト認証情報（minioadmin:minioadmin）でアクセスし、バケットの一覧取得からTerraformの状態ファイル、認証情報JSONの取得まで段階的に範囲を広げた。

Langflowサーバには30分ごとに攻撃者のインフラへビーコンを送るcrontabエントリが設置され、永続化が確立された。

しかし、Langflowは中継点に過ぎなかった。本来の標的は、別のサーバで稼働していた本番MySQLデータベースとAlibaba Nacosだった。Nacosはマイクロサービスアーキテクチャで広く使われるサービスディスカバリ・動的設定プラットフォームで、認証バイパスの脆弱性（CVE-2021-29441）と広く知られたデフォルト署名鍵がそのまま残されていた。

エージェントはこのサーバのMySQL管理ポートにroot認証情報で接続した。Sysdigによれば、この認証情報が被害者の環境から窃取された痕跡はなく、入手経路は不明だ。

身代金を払っても復号できない

Nacosサーバに到達したJadePufferは、1342件のサービス設定項目をMySQLのAES_ENCRYPT()関数で暗号化し、元のテーブル（config_infoと履歴テーブル）を削除した。脅迫テーブルREADME_RANSOMには身代金の要求、ビットコインの支払先アドレス、Proton Mailの連絡先が記録された。

ここに、この攻撃の構造的な欠陥がある。

暗号化キーはUUID4を2つ連結してBase64エンコードしたもので、実質的にランダムな値だ。このキーは標準出力に1度だけ印字されたが、ファイルに保存されることも、外部に送信されることもなかった。被害者が身代金を支払っても、攻撃者自身がデータを復号する手段を持たない。

身代金メモはAES-256での暗号化を主張しているが、MySQLのAES_ENCRYPT()はサーバ設定を変更しない限りAES-128-ECBが既定だ。Sysdigは、実際にはAES-128-ECBが使用された可能性が高いとみている。

ビットコインアドレスにも疑問が残る。身代金メモに記載された3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLyは、ビットコイン開発者ドキュメントに掲載されているPay-to-Script-Hash（P2SH）フォーマットの標準例示アドレスだ。累計737件の取引と約46BTCの入金記録があるが、残高は常にゼロで、入金は即座に別アカウントへ転送されている。LLMが訓練データからこのアドレスを再現した可能性と、攻撃の設計者が意図的に設定した可能性の両方があり、Sysdigはシステムプロンプトを確認できないため判別できないとしている。

暗号化後、エージェントはさらにデータベーススキーマ全体の削除に踏み込んだ。コードのコメントには「高ROI（投資対効果）データベースを削除（データは既に64.20.53[.]230にバックアップ済み）」と記されていたが、Sysdigの調査ではこのIPアドレスへのデータ送信は確認されていない。エージェント自身のコメントが、実際の動作を過大に申告していた可能性がある。

なぜLLMだと判断できるのか

Sysdigが自律性の根拠として挙げるのは4つの独立した証拠だ。

第一に、ペイロード全体に散りばめられた自然言語のコメント。使い捨てのpython3 -cワンライナーに「ROIの優先順位」「最大のデータベース」「各ステップの目的」を記述する攻撃者はいない。LLMのコード生成は、この種の解説を既定で付与する。

第二に、前述の31秒の修正シーケンスに代表される、機械速度での故障診断と修正。MinIOのXML応答への即時適応、JWTアプローチの即時放棄、外部キー制約の即時回避。いずれも失敗モードに特化した修正であり、汎用的なリトライスクリプトとは挙動が異なる。

第三に、標的が提示した自然言語コンテキストの理解。エージェントは標的環境の自由形式テキストを読み取り、パターンマッチではなく内容の理解に基づいた行動をとった。この挙動は数週間の間隔を空けた複数のセッションで再現されている。

第四に、前述のビットコインアドレスの問題。訓練データに大量に含まれる例示アドレスをそのまま出力するのは、LLMに特有の挙動だ。

600以上の個別ペイロードが圧縮されたタイムウインドウの中で実行され、それぞれが目的を持った一貫した動作を示していたことが、全体の評価を支えている。

ランサムウェアの参入障壁が消える

JadePufferの攻撃で使われた個別の手法に、新しいものはない。2021年のNacos認証バイパス、変更されていないデフォルト署名鍵、インターネットに露出したデータベース管理ポート。いずれも長年知られた問題だ。

新しいのは、LLMがこれらを1つの完結した攻撃作戦に組み上げたことにある。

Sysdigの脅威調査ディレクター、マイケル・クラーク（Michael Clark）氏は報告書で、ランサムウェアの実行に高度なスキルは不要になったと指摘している。LLMエージェントは偵察、認証情報の窃取、横展開、永続化、破壊を、オペレーター自身がどの段階にも深い専門知識を持たなくても連鎖させる。そのエージェントが盗まれた認証情報で（LLMジャッキングと呼ばれる手法で）動いている場合、攻撃者の実質コストはゼロに近い。

一方で、LLMが攻撃を実行する場合に固有の検知機会も生まれる。エージェントは自分の意図をペイロード内に自然言語で記述する。攻撃者がコードにROI分析を書き残すことはないが、LLMはそれを反射的に行う。守る立場から見れば、攻撃コードの中に目的と優先順位が平文で記されている状況は、これまで存在しなかった。

JadePufferが示すのは、AIの能力の問題ではなく、放置されたインフラの問題だ。修正済みの脆弱性、変更されていないデフォルト認証情報、インターネットに露出した管理ポート。AIエージェントがこれらを自動で組み合わせるようになった今、パッチの未適用やデフォルト設定の放置は、かつてとは桁の違うリスクを意味する。

関連記事

• AIゼロデイ初確認、Googleが鳴らした警鐘
• ファイブアイズ、組織内部で動くAIエージェントのセキュリティリスクを警告
• BlueHammer、ランサムウェアに転用。CISAが警告
• 犯罪の3件に1件がサイバーに。INTERPOL報告書が示す現実
• 米CISA、脆弱性の修正期限を最短3日に。リスクベースの新指令を発行
• Anthropicが「Mythos級」AIを一般公開。Claude Fable 5の設計思想
• Active Directoryの「説明」欄にパスワード保存　侵害につながった事例を検証
• LinkedIn求人スパムが古英語表示に　プロフィール設定を使った対策
• AIに嘘を信じ込ませる方法、RITが脆弱性を実証
• 脆弱性の90日開示ルールをAI時代に見直す動き　発見速度の変化を分析