何が起きたか
Palo Alto Networksの調査部門Unit 42が、AIエージェントに標的探索から攻撃までを委ねる手口を確認したと、BleepingComputerが2026年7月31日に報じた。Unit 42は、「knaithe」「KnYuan」を名乗る中国拠点の人物による活動と見ている。
発覚のきっかけは、攻撃者側の設定ミスだった。Hermes Agentがホームディレクトリを配信するWebサーバを意図せず立ち上げ、標的リスト、エクスプロイトのスクリプト、シェルの履歴、AIの攻撃ログ、APIキーといった作業環境の中身が外部から見える状態になった。
構成は、推論をDeepSeekのモデルが担い、実行をOSSのHermes Agentが受け持つ形である。Hermesは、モデルの判断で端末のコマンドを走らせ、外部のサービスにも接続できるエージェント基盤で、危険な操作も承認を挟まず実行する「Yolo」モードを備える。運用面では、指示の入口にTelegramのチャネルを充て、攻撃用の独自スキルと、露出資産を検索するFOFAを呼び出せるようにしていた。
Unit 42が復元した2026年5月のセッションで、人が与えたのは最初のタスクだけだったとみられる。エージェントはCVE-2026-33017の影響を受けるLangflowから着手し、公開PoCを入手して、FOFAで見つけた84件の露出インスタンスを調べた。攻略できないと判断すると公開リポジトリを分析し直し、露出が64万7000件超あるn8nへ標的を移す。CVE-2026-21858とCVE-2025-68613を連鎖させるエクスプロイトを入手して脆弱なサーバを絞り込んだが、必要な認証不要のアップロードフォームは見つからず、自律実行分は侵害に至らなかった。
同じ攻撃者は手動でも460台を超えるシステムを攻撃し、Citrix NetScalerのCVE-2026-3055を悪用した3件の侵害が確認されている。Unit 42は影響が限定的だったとしつつ、「end-to-end autonomous offensive capability」（BleepingComputer）が実際に機能したと評価している。
「end-to-end autonomous offensive capability」— BleepingComputer
「hundreds of hours of manual targeting analysis」— BleepingComputer
なぜ重要か
注目すべきは成否ではなく、所要時間だ。Unit 42は、通常なら「hundreds of hours of manual targeting analysis」（BleepingComputer）に当たる作業を、システムが数分でこなしたと指摘している。計算資源の管理まで含めてエージェント側が回していた。候補の列挙、絞り込み、エクスプロイトの選定という、これまで攻撃側の人的ボトルネックだった工程が機械速度に移っている。PoCが公開されてから広範な探索が始まるまでのリードタイムは、従来の想定より短く見積もる必要がある。
もう一つの論点は、外部から効く統制点が乏しいことだ。今回の実行基盤はOSSで、攻撃者が自分の手元で設定を変えられる。承認を求めずに動く運用モードが最初から用意されている以上、実行段階に第三者のチェックは入らない。流出物にAPIキーが含まれていたことから、何らかのサービス経由の利用があった可能性はある。ただし攻撃者はQwen、GLM、Kimi、MiniMax、Claude Code、Codexなども併せて設定しており、実際にはあまり使っていなかったとされる。推論の担い手は差し替えが利き、特定のモデルやサービスを止めても攻撃全体の抑止にはなりにくいとみられる。
段階も上がっている。先に報じられたタイ財務省を狙ったとされる事案では、標的も目的もツールも人が与え、Hermesは侵入後の定型作業を自動化していた。今回は、どこを狙いどう攻めるかの判断自体が自動化されている。一方、実際の侵害は従来型の手動攻撃で、外部公開のCitrix NetScalerに対して起きた。防御の焦点はAIそのものよりも、露出面と対応時間に置くのが妥当だ。
R&Rの視点
日本企業の現場でまず効くのは、AI対策という新しい予算費目ではなく、既存の脆弱性管理に埋め込まれた時間の前提を見直すことである。四半期ごとの資産棚卸し、月次の外部スキャン、変更管理会議を経てからの適用。この周期は、標的の選定が数分で終わる相手を想定して組まれていない。経営層への説明も、AIの脅威一般を語るより、直近の緊急パッチでPoC公開から適用完了まで何日かかったかという一つの数字に落とすほうが通る。予算化の議論は、その日数を縮めるための外部資産の可視化と、緊急時の停止をベンダー保守契約や業務部門との合意に事前に書き込む話になる。
狙われた製品の性質も示唆的だ。Langflowもn8nも、事業部門やデータ分析チームが自力で立てやすいソフトウェアである。情報システム部門の台帳に載らないまま外部に出ているケースは珍しくない。生成AIのガバナンス議論は社員の利用ルールに寄りがちだが、実際のリスクは自前で構築したAI周辺基盤の露出側に偏っている。
過小評価の典型は「今回は失敗したのだから」で片付けることだ。失敗したのは自律部分で、侵害自体は従来型の手動攻撃で成立している。
実務者が今日やること
- 自社の外部公開資産をFOFAなど外部の検索サービスでも取得し、資産台帳に載っていないホストを洗い出す
- Langflowやn8nなど事業部門が自前で立てたAI・自動化基盤の公開状況を、部門ヒアリングと外部スキャンの両方で確認する
- Citrix NetScalerのCVE-2026-3055の適用状況を確認し、未適用機器があれば停止調整を今週の予定に組み込む
- 直近の緊急パッチ3件について、PoC公開から適用完了までの実日数を集計し、経営報告の指標として定義する
- 露出資産へのスキャンと初期侵入を捉える検知ルールが分単位で発報するか、SOCと運用委託先に確認する
