Telegram経由でDeepSeekを操る自律攻撃：成功3件にとどまったが、コスト曲線が折れたことの意味は重いです

今日の深掘りポイント

• メッセージング基盤（Telegram）＋オープンソースのエージェントフレームワーク（Hermes Agent）＋LLM（DeepSeek）の組み合わせで、探索・選定・悪用が一連自動化されたこと自体が本丸です。
• 成功は3件と少数でも、攻撃コストが劇的に低下し“失敗コストが限りなく小さい”ため、量（反復）で押す運用が成立しはじめています。
• 標的はLangflowやn8nなど“開発者向けワークフロー系の外部露出”で、要件未充足により多くが不発でした。逆に言えば、最小限の設定不備が“自律攻撃に刺さる面”で残っている状況です。
• C2/運用の外形はTelegramボットとHTTP(S)中心で、既存のネットワーク制御をすり抜けやすいレイヤーです。Egress制御・監査の粒度が勝負どころです。
• 現場対応はEASM（外部資産の継続棚卸し）、不用な公開UIの閉塞、認証必須化、WAF/EDR連携、そして“AI運用痕跡”の検知ルール整備が要諦です。

はじめに

中国語話者の脅威アクターが、Telegramで指示を投げ、Hermes Agentフレームワークを介してLLMのDeepSeekを実働させ、インターネット露出システムの探索から既知エクスプロイトの適用までを自律的に回した事案が報じられました。460超の標的試行に対し成功は3件にとどまったものの、運用の組成が軽く、繰り返しが利くことこそが本件の本質です。いまや攻撃者は“人手の時給”をボトルネックにせず、メッセージング＋エージェント＋既存PoCで回る“常時・広域の当たり”を仕掛けられます。

この“成功3件”は、守る側にとって“あと一歩で刺さる”質感でもあります。Langflowやn8nのような便利ツールの外部露出は、利便と引き換えに“設定条件次第でワンショット成立”の面が残りがちです。攻撃の巧拙より、露出と設定が結果を決める局面が増えていることを押さえておきたいです。

参考とした公開情報は以下の報道です（本稿はこの情報に依拠し、追加の一次情報調査は行っていません）。

• The Hacker News: Chinese Hacker Commands DeepSeek via Telegram to Launch Autonomous Cyber Attacks

深掘り詳細

事実関係（報道ベースで確認できる点）

• 脅威アクターはTelegramで初期指示を投稿し、Hermes AgentがDeepSeekを用いて自律的にタスクを分解・実行したと報じられています。
• エージェントはインターネット露出システムを同定し、公開PoCを選択して攻撃を試行しました。
• 460超の標的試行のうち、成功は3件にとどまり、多くはLangflowやn8nなどの脆弱性要件を満たさず不成立だったとされています。
• 報道は、組織に対して当該システムのパッチ適用と不必要な公開アクセスの削除を促しています。
• 情報源は上記の公開記事であり、技術分析の一次資料（パケットキャプチャ、C2ログ、具体的IoC一覧など）は本稿では未確認です。

編集部のインサイト：なぜ“成功3件”が重要か

• コスト構造の断絶です。従来は“スキャン→選定→手動悪用→結果確認”のオペレーションに人手が必要でしたが、今回のようなエージェント連携は“無限に近い反復を低コストで”回せます。失敗が大半でも、回数が収益を生みます。これは攻撃側の“学習速度”と“打席数”を飛躍させます。
• 露出資産が“攻撃の難易度”を規定します。Langflowやn8nは“便利な開発運用UI”ですが、認証未設定や既定ポートのまま、あるいは内部前提の設定を外部で晒すと、一撃で成立する構成が紛れます。AIエージェントはそうした“薄い弱点”を機械的に拾い続けられます。
• C2/運用の不可視化が進みます。Telegramは正規のHTTPSに埋まるため、国・業界を問わず通信は珍しくありません。プロキシや次世代FWの“既知悪性C2”検知に頼るだけでは捕捉漏れが出やすいです。

いま見えた限界と、すぐ埋まる溝

• 今回多くが失敗したのは、脆弱性成立の前提条件（バージョン、設定、プラグイン構成など）を満たさなかったためとされています。これは裏を返せば、前提条件の自動判定精度が上がれば成功率が跳ねることを意味します。
• LLM＋ツール実行の“安全策”として設けられるコンテキスト制限が、攻撃者側でも“過保護”だと手数が出ず、逆に“解放”すると成功率が上がるはずです。攻撃側の探索アルゴリズム（例：失敗ログの自己要約→次手提案）を更新するたび、成功率は段階的に伸びると見るのが自然です（仮説です）。

脅威シナリオと影響

以下は、報道内容に基づき編集部が推定したMITRE ATT&CKマッピングを含む仮説シナリオです。実際のTTPはフォレンジックにより異なる可能性があります（仮説であることに留意ください）。

• 初期準備・偵察
  • T1595: Active Scanning（検索エンジン・Shodan等の結果をもとに自動スキャン）
  • T1590: Gather Victim Network Information（露出サービスのメタ情報収集）
• 初期侵入
  • T1190: Exploit Public-Facing Application（Langflow/n8nなどの公開UIに対する既知PoCの適用）
• 実行・永続化
  • T1059: Command and Scripting Interpreter（PoCやOSコマンドの実行）
  • T1105: Ingress Tool Transfer（外部から追加スクリプトやペイロード取得）
• 指揮統制（C2）
  • T1071.001: Application Layer Protocol: Web Protocols（Telegram Bot API等のHTTPS経由での制御・結果回収）
• 資格情報・横展開（成立時）
  • T1003: OS Credential Dumping（権限獲得後の資格情報収集）
  • T1021: Remote Services（獲得資格情報による内部横移動）
• 収集・流出
  • T1056/T1005相当（インタラクティブ収集やローカルデータの収集）
  • T1041: Exfiltration Over C2 Channel（Telegram経由の結果送出）

想定影響

• 機密情報の断続的漏えい：成功率が低くても打席数が多ければ“薄く広い”漏えいが発生しうる構図です。
• DevOps系ワークフローの改ざん：n8nやLangflowは“自動処理の入口”で、認証不備だとフロー書き換え→二次被害（SaaS連携の踏み台化）が成立します。
• 防御側運用コストの逆転：C2が一般的なHTTPSや人気SaaSドメインを経由すると、組織は“止めると業務影響、通すとリスク増”の難題に晒されます。

セキュリティ担当者のアクション

優先度高から提示します。既存の体制・ツールで“今日から回せること”に重心を置いています。

1. 外部露出資産の常時棚卸し（EASM/EDR連携）

• 目標は“Langflow/n8n/LLM管理UI/ジョブオーケストレータ等の管理コンソール露出ゼロ”です。
• CI/CD用の一時テスト環境・PoC環境のDNS登録や短期公開を含めて検知・自動通報のルール化を行います。

2. 不要公開の遮断と認証強制

• 管理UIはすべてVPN/ゼロトラストの背後へ。どうしても外部公開が必要な場合はSAML/OIDCで強固な認証を必須化し、IP制限を併用します。
• 既定ポート・既定パスのままの公開をなくし、ベンダが推奨するハードニングガイドに沿って設定します。

3. パッチ適用と“前提条件潰し”

• 報道で言及のあった対象群（Langflow/n8nなど）は、最新安定版への更新と既知CVEの確認を定例化します。
• 脆弱性の“成立条件（バージョン×設定×プラグイン）”を資産台帳に明記し、前提条件を潰す設計（不要機能の削除、機能分離）を推進します。

4. Egress制御とTelegram等の業務上不要通信の扱い

• api.telegram.org等のボットAPI宛通信は、業務で正当化できない限り遮断・検知対象にします。許可が必要な部署はプロキシ経由・審査制にします。
• “正規SaaSをC2に使う”回避のため、汎用SaaS宛のPOST/PUT頻度異常や小さなPOSTと応答の反復など、アプリ層のアノマリ検知を導入します（仮説に基づく検知強化です）。

5. WAF/IDSの“エージェント臭”の捕捉

• 短時間に異種PoCを次々投下→異なるエンドポイントにリクエストが飛ぶパターン、GitHub等からのPoC取得直後の攻撃リクエストといった“試行→即実行”のトレースを相関検知します（仮説です）。
• User-Agentやヘッダが固定・テンプレート然としている場合の重み付けを上げ、連続失敗の後に微修正される挙動（プロンプト反復の痕）を特徴量に加えます（仮説です）。

6. EDRでの“自動化実行”の振る舞い検知

• シェル/スクリプトの短サイクル反復、ファイルDL→即実行→失敗→削除のループ、標準ツールの機械的羅列実行を高リスク行動として扱います（仮説です）。

7. 監査・ロギングの前提再設計

• 開発系UI（Langflow/n8n等）に対するアクセスログを長期保全し、管理操作（フロー作成・変更・実行）を監査対象に入れます。
• “外部からの自動実行を前提にした”アラート（操作数/分の急増、テンプレ的命名のフロー大量作成など）を用意します。

8. インシデントレスポンスの想定更新

• “多数の失敗試行→少数成功”を前提に、単一ホストの痕跡だけでクローズせず、同一攻撃キャンペーンの拡散をサンプリング確認します。
• C2がTelegram等の一般プロトコルに隠れる前提で、プロキシ/Firewall/EDRの横断相関をルーチン化します。

9. ベンダ・内製チームへの“公開禁止”ポリシー明確化

• PoC環境、デモUI、機械学習パイプライン管理画面の外部公開を“原則禁止”。例外承認と観測・廃止期限を必須化します。

10. 教育・広報

• エンジニアに“便利UIの公開＝攻撃対象化”の直観を持ってもらうため、今回の事例を社内Tech Talkの題材にします。開発スピードと安全の両立策（ローカルリバースプロキシ、認証強制テンプレート）を配布します。

最後に、今回のスコアリング的な示唆を整理します。新規性は高く、信頼性・蓋然性も高い一方で、当面の成功率は限定的というバランスです。だからといって優先度を下げる理由にはなりません。成功率は“学習と自動化”で右肩上がりになりますし、守る側の“露出削減”は今や最も費用対効果の高い手当です。今日できる“外に出ているものを減らす”作業こそが、攻撃者の学習曲線を鈍らせる最短距離だと考えます。

参考情報

• The Hacker News: Chinese Hacker Commands DeepSeek via Telegram to Launch Autonomous Cyber Attacks