DeepSeek自律攻撃をUnit 42が分析｜460標的で自律フェーズ全失敗、成功3件は手動という実像

2026年7月30日、Palo Alto Networks の脅威インテリジェンス部門 Unit 42 が、DeepSeek をオープンソースのエージェント基盤 Hermes Agent に組み込んで自律的にサイバー攻撃を実行していた攻撃者の分析レポートを公開しました。Telegram で最初の指示を1回与えた後は、エージェント自身が公開システムを探索し、脆弱性を選び、GitHub から公開エクスプロイトを取得して攻撃を試みています。攻撃者のアリアスは「knaithe」「KnYuan」、拠点は中国・珠海と評価されています。

セキュリティ全体の考え方は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

DeepSeekがサーバを攻撃した——Unit 42報告の全体像

まず、何がどう組み合わされていたのかを整理します。役割分担は明確で、Hermes Agent が実行環境、DeepSeek が判断エンジンです。

Hermes Agent は Nous Research が公開しているオープンソースのエージェント基盤で、ターミナルへのアクセス、Telegram を含むメッセージングプラットフォーム経由のやり取り、スキル機構を提供します。攻撃者はここに DeepSeek を推論エンジンとして接続し、コード生成・脆弱性評価・標的選定・意思決定を任せていました。

攻撃者が Hermes Agent に追加していたスキルは3つです。

・godmode：LLMのジェイルブレイク用。フレームワークに同梱されているもの
・web-terminal-exploitation：未認証のWebSocketを悪用するための自作スキル
・fofa-cyberspace-search：インターネット上の資産列挙のため、攻撃者自作の fofoapi.py を使うよう DeepSeek に指示する手順テンプレート

さらに、FOFA の資産検索・Nuclei のスキャン生成・自然言語からFOFAクエリへの変換をエージェント内から直接呼び出せる MCP サーバーも統合されていました。ここで重要なのは、攻撃者が用意したのは既製部品の組み合わせであって、新規開発ではないという点です。Unit 42 も結論で「AIを活用した攻撃の技術的障壁は低く、下がり続けている」と書いています。

Unit 42 が把握したのは、攻撃者が使っていた4つのAIツールの構成です。西側の2ツールは追跡を避けるためサードパーティのプロキシ経由、中国系の2つはネイティブのAPIエンドポイントに直接接続していました。

Unit 42 は、攻撃者が西側のモデルも試したがプロバイダ側の制御によって自律攻撃には使いづらく、結果として最も制約の緩いモデルへ流れたと評価しています。加えて、OpenAI 側でポリシー違反のリクエストが拒否され、試行の継続によって当該キャンペーンに関連するとみられるアカウントが停止されていたことを確認した、とも記載されています。「安全制御は無意味だった」ではなく「安全制御のない選択肢へ移動した」というのが、一次資料に即した読み方です。

AI支援による大規模スキャンという手口自体は目新しいものではありません。攻撃ツール側の実装を追った例としては BISSA Scanner解析：AI支援の大規模脆弱性スキャンと.envクレデンシャル窃取の仕組み も参考になります。今回の事例が異なるのは、スキャンだけでなく「次に何を狙うか」の判断まで委ねられていた点です。

時系列：2026年5月7日の単一セッションで起きたこと

Unit 42 が回収したのは、2026年5月7日の Hermes Agent セッション1本です。報告では、最初のタスク指示以降、追加の操作者入力は回収できなかったとされています。つまりこの区間は、事実上ひと続きの自律実行です。

注目すべきは Phase 1 から Phase 2 への切り替えです。Langflow で行き詰まった DeepSeek は、標的そのものを見限る判断を自分で下しています。報告に引用されたセッションログでは、3台とも公開フローIDが必要で auto_login が無効なため手詰まりであること、設置台数が84台と小規模で悪用可能な数はおそらく0であることを述べ、より大規模な脆弱性を探すという方針転換を自ら決めています。

その後の標的選定も自律です。DeepSeek は FOFA で10の製品群の設置台数を横断比較し、GitHub で2026年のCVEのPoCリポジトリをスター順に探索したうえで n8n を選びました。選定理由として、PoCのスター数が258でCVSSが10.0であること、n8n が Langflow と似たワークフロー自動化ツールでありながらPoCのスター数がはるかに多い点を挙げています。

FOFA での実測は全世界647,017台、中国国内25,209台。ここから DeepSeek は約100IPを抽出し、約40IPに対して curl でバージョンを確認しています。Unit 42 はこの「標的の特定・サンプリング・絞り込み」を自分で管理した点を重視し、手作業なら数百時間かかる標的分析を数分で実行しつつ、自身の計算資源も節約していたと評しています。

自律型のペネトレーションテストをどう評価するかという枠組み自体は整備が進んでいます。基準側の議論は OWASP APTS｜AIエージェント時代の自律型ペネトレーションテスト基準を読む にまとめています。

DeepSeekを止めたのは設定だった——自律フェーズ全失敗という実像

ここが本記事で最も伝えたい部分です。見出しだけを追うと「AIが自律的にサーバを攻撃して侵入した」と読めますが、一次資料を読むと自律フェーズの侵害成功は0件です。

整理すると次のようになります。

失敗の中身も具体的です。Langflow では、脆弱性の成立に公開フローIDまたは auto_login の有効化が必要で、標的はそのどちらも満たしていませんでした。n8n では、PoC が未認証でファイルアップロード可能なフォームを要求するのに対し、見つかったフォームのエンドポイントはすべて認証が有効でした。DeepSeek はこの点を自分で気付いており、報告のログ引用でも、エクスプロイトコードを読み直すと未認証のフォームが必要だがこれらのフォームは認証が有効になっている、と述べて他の標的の確認へ移っています。その後50台超を並列でスキャンしましたが、公開されたフォームを持つものはありませんでした。

一方で手動キャンペーンの被害は具体的です。NetScaler の境界外メモリ読み取り（CVE-2026-3055）で3組織からメモリ内のデータが持ち出され、攻撃者はその中から NetScaler の認証クッキー（NSC_AAAC=）を検索しています。セッション乗っ取りを意図していたとUnit 42は評価しています。マレーシアの政府機関に対しては、メモリ配置を調整するパラメータと読み取り試行の最大化を伴って複数日にわたり執拗に攻撃し、後続の試行ではプロキシによる匿名化を加えていました。

AIに任せた部分は浅く広く、人間が手を動かした部分は深く執拗——これが今回のデータから読み取れる非対称です。

攻撃者の像と、日本の組織にとっての読み方

Unit 42 は攻撃者を、機会主義的なエクスプロイト運用者かつ自称バイナリセキュリティ研究者と評価しています。判断の根拠として挙げられているのが、攻撃者がGitHubで維持していた 1DayNews という脆弱性インテリジェンスの自動パイプラインです。この仕組みは、主にネットワーク境界機器ベンダーを中心とする17のソースからRCEの公開情報を集約し、DeepSeek で悪用可能性を判定し、Telegram で実行可能なアラートとして配信していました。

つまり攻撃者は、攻撃の実行だけでなく「何が新しく出たか」を追う工程にも同じモデルを使っていたことになります。攻撃キャンペーンとして観測されたのは氷山の一角で、その手前に常時稼働する選別パイプラインがある——という構図です。

日本の組織にとっての距離感も、報告のデータから整理できます。自律キャンペーンが対象にしたのは中国国内のインフラで、無差別でした。一方、実害の出た手動キャンペーンは3か国・複数セクターに及び、名前が挙がっているのはマレーシアの政府機関です。現時点の一次資料に、日本の組織が標的になったという記載はありません。ただし、選定ロジックがFOFAの検索結果と設置台数である以上、地理的な条件は攻撃者が指定するクエリ次第で変わります。「今回は対象外だった」ことに安心の根拠を求めるより、FOFAのような資産検索エンジンから自組織のどのサービスが見えているかを確認するほうが実務的です。

悪用された7つのCVEと影響範囲の一覧

攻撃者が実際に攻撃ツールを保持していた脆弱性は7件です。Unit 42 の表に、NVDで確認した影響範囲を突き合わせました。

いくつか、点検時に効いてくる細かい点を補足します。

n8n の3台は「両方に脆弱」ではありません。 Unit 42 は脆弱なバージョンとして v1.18.0・v1.117.3・v1.108.2 の3件を挙げていますが、NVDの影響範囲と突き合わせると、v1.108.2 と v1.117.3 は2件とも範囲内である一方、v1.18.0 は CVE-2025-68613（0.211.0以上）の範囲には入るものの、CVE-2026-21858（1.65.0以上）の範囲には入りません。自環境のバージョンを照合するときは、2つのCVEを別々に確認してください。

Tomcat の CVE-2026-34486 は修正の副作用です。 NVD の説明によれば、これは CVE-2026-29146 に対する修正が EncryptInterceptor のバイパスを許してしまったというもので、対象は 11.0.20・10.1.53・9.0.116 という特定バージョン。修正版は 11.0.21・10.1.54・9.0.117 です。「上げたから安全」ではなく「その版に上げたことで対象になった」型なので、バージョン一覧を見るときに読み飛ばしやすい部類です。

PAN-OS の1件は実行されていません。 攻撃者は公開リポジトリをクローンしていますが、そのコードはプレースホルダ値を含む非機能のもので、改変や実行の形跡は確認されていません。攻撃ツールの保持と実際の攻撃は分けて数える必要があります。

自環境の確認手順——Langflow・n8n・marimoを今すぐ点検する

ここからは読者が自分の環境で実行できる内容です。攻撃の再現手順は扱いません。確認と緩和のみを示します。

まずバージョンを確認します。

# Langflow（1.9.0 未満が CVE-2026-33017 の影響範囲）
pip show langflow 2>/dev/null | grep -i ^version
docker ps --format '{{.Image}}' | grep -i langflow

# n8n（2つのCVEで下限が違うため、版数を控えて個別に照合する）
npm ls -g n8n --depth=0 2>/dev/null | grep n8n
docker ps --format '{{.Image}}' | grep -i n8n

# marimo（0.23.0 未満が CVE-2026-39987 の影響範囲）
pip show marimo 2>/dev/null | grep -i ^version

次に、認証を経ずに到達しうるエンドポイントが外から見えていないかを確認します。以下はNVDの脆弱性説明に記載されたパスで、自分が管理するホストに対してのみ実行してください。

# 自ホストのアクセスログに、外部からの到達痕跡がないか確認する
# Langflow: 未認証で公開フローを構築できてしまうエンドポイント
grep -R "/api/v1/build_public_tmp/" /var/log/nginx/access.log* 2>/dev/null | tail -20

# marimo: 認証検証が欠落していたターミナルWebSocket
grep -R "/terminal/ws" /var/log/nginx/access.log* 2>/dev/null | tail -20

# 短時間に多数のパスを舐める挙動（自律スキャンの特徴）を上位IPで俯瞰する
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

設定面では、次の3点が今回の分かれ目に直結しています。

・Langflow の auto_login を無効にする（環境変数 LANGFLOW_AUTO_LOGIN=False）。今回の標的が助かった理由そのもの
・n8n のフォームエンドポイントに認証をかける。未認証かつファイルアップロード可能なフォームの有無が成立条件だった
・marimo をインターネットへ直接公開しない。/terminal/ws は認証検証を欠いていたため、到達できること自体がリスクになる

NetScaler については、CVE-2026-3055 が SAML IdP として構成されている場合の入力検証不備によるメモリ超過読み取りです。自組織の構成が該当するかをまず確認し、該当する場合は認証クッキーの失効を含めた対応を検討してください。持ち出されるのはメモリ内容であり、攻撃者が実際に NSC_AAAC= を検索していた以上、セッションが有効なままである限り被害は継続します。

検知の勘所——ログに残る痕跡とAIスキャンの見分け方

自律実行のスキャンには、人間の手作業とは異なる痕跡が残ります。今回の報告から読み取れる特徴を、検知の観点で整理します。

バージョン確認が先行する。 DeepSeek は約40のIPに対して curl でバージョンを確認してから攻撃を試みています。総当たりではなく、まず版数を読み、影響範囲に入るものだけを狙う動きです。ログ上は「特定のバージョン情報を返すエンドポイントにだけアクセスが集中し、その後ごく一部にだけ攻撃らしきリクエストが続く」という形になります。

サンプリングされる。 25,209台のうち実際に触られたのは約100IPで、そのうち約40IPが精査されています。Unit 42 はこれを計算資源の節約とみています。自組織が「調べられただけで攻撃されなかった」場合でも、母集団には入っているという前提で考えるべきです。

行き詰まると製品ごと乗り換える。 人間の攻撃者なら粘る場面で、自律エージェントは標的クラスごと捨てて次に移ります。裏を返せば、設定を締めておけば「割に合わない」と判断されて離脱する可能性がある、ということでもあります。

攻撃者側にも痕跡が生まれる。 今回の露見は Hermes Agent が /home/worker で python3 -m http.server 8888 を起動したことによるものでした。攻撃者は使用後にエクスプロイトディレクトリを空にし、Codex の会話ログを無効化するなど運用上の注意を払っていましたが、自律実行が生んだ1回のミスがすべてを露出させた形です。Unit 42 はこれを「手動実行では存在しなかったフォレンジック上の痕跡を、自律実行そのものが作り出した」と表現しています。

同じ構図は防御側にも当てはまります。自分たちが業務で動かしているAIエージェントも、コマンド実行権限を持つ以上は同じ事故を起こしえます。ワークフロー自動化ツールの選定と運用については AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 も併せて確認してください。

露出を減らす——自分のAIエージェントを攻撃基盤にしないための設定

最後に、今回の事例を自組織の運用に折り返します。攻撃者が使っていた設定は、そのまま「やってはいけない設定」のリストになっています。

具体的な点検としては、以下が出発点になります。

# エージェントが意図せず公開サーバを立てていないか（自ホストで実行）
ss -tlnp 2>/dev/null | grep -E ':(8888|8000|8080|7860) '

# ホームディレクトリ直下でHTTPサーバが動いていないか
ps aux | grep -E 'http\.server|SimpleHTTPServer' | grep -v grep

そのうえで、運用として次の3点を推奨します。

・エージェントの作業領域を隔離する。ホームディレクトリや資格情報の置き場と同じ階層で動かさない。今回の露見はこれ1点で防げた
・承認スキップは環境を限定する。yolo 相当の設定を使うなら、本番資格情報の無い使い捨て環境に閉じる
・インターネットへの直接公開をやめる。Langflow・n8n・marimo はいずれも、認証の前段に置くだけで今回の攻撃条件が崩れる

AIエージェントを狙う攻撃面そのものについては GitHubコメントがAIエージェントを乗っ取る：「Comment and Control」攻撃の仕組みと防御策 で別の角度から扱っています。

Unit 42 は結論で、意義は個別キャンペーンの結果ではなく軌跡にあると書いています。攻撃者は現在も反復中——ツール構成の調整、独自スキルの開発、プロキシ基盤の構築、自律攻撃サイクルの実行を続けており、技術的障壁は下がり続けている、と。今回助かった環境が来月も助かる保証はありません。今回の分かれ目が「設定」だったことは、防御側にとって最良の知らせです。パッチ適用より先に、今すぐ変えられるからです。

参照ソース

・Unit 42 — Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks（2026年7月30日公開・本記事の一次ソース）
・NVD — CVE-2026-33017（Langflow / 1.9.0未満）
・NVD — CVE-2026-21858（n8n / 1.65.0以上1.121.0未満）
・NVD — CVE-2025-68613（n8n / 0.211.0以上1.120.4未満）
・NVD — CVE-2026-39987（marimo / 0.23.0未満）
・NVD — CVE-2026-3055（NetScaler ADC / Gateway）
・NVD — CVE-2026-34486（Apache Tomcat）
・BleepingComputer — Hacker uses DeepSeek AI to autonomously attack vulnerable servers（媒体報道） </content> </invoke>