台湾政府、AIエージェントを併用したサイバー攻撃を公表

台湾のデジタル発展部は8月13日、7月に政府機関がAIエージェント併用の攻撃を受けたと公表した。前日にはイスラエルのDreamが多エージェント型の攻撃基盤の分析を公開している。ただし両者が同一事案かは確認されていない。

台湾のデジタル発展部が公表した7月のサイバー攻撃

デジタル発展部（数位発展部）は8月13日付の報道資料で、7月に政府機関を標的とした異常な攻撃を検知したと明らかにした。攻撃元・手口・影響範囲の調査はいずれも終わり、影響を受けた機関の処置も順次完了したという。

7月に異常な攻撃を検知し、20日から警戒情報を発出

サイバーセキュリティの監視を担う部署が異常な攻撃を検知したのは7月だった。7月20日からは国家サイバーセキュリティ研究院（資安院）が警戒情報を順次発出し、同時に調査とインシデント対応も始まっている。

発表は攻撃の規模や被害の程度に触れていない。標的となった具体的な機関名も示されておらず、公表されたのは検知の時期・調査の完了・影響機関の処置完了という範囲にとどまる。

人手の操作とAIエージェントを組み合わせた混合型

調査結果として示されたのは、海外を発信元とする明確な特徴と、人手の操作にOpenClaw（発表の表記はOpen Claw）などのAIエージェントによる支援を組み合わせた混合型の手口だ。完全な自動化ツールでも、人手だけの侵入でもない。

デジタル発展部は、AIエージェントが複数の攻撃手法を素早くつなぎ合わせる点を指摘した。予備系や試験系といった二次的なシステムを踏み台に使えることで、攻撃は速度が速く・費用が低く・規模が大きいという性質を帯びるとしている。

AIエージェントは、目的に応じて手順を組み立て、外部ツールを使いながら作業を進める仕組みを指す。OpenClawの公式サイトは同ソフトをオープンソースの個人向けAIアシスタントと説明しており、攻撃専用に作られたツールではない。

攻撃元の国名は特定していない

デジタル発展部の発表は中国に言及していない。台湾はこれまで、日常的に受けるサイバー攻撃の多くを中国によるものとしてきたが、今回は特定の国名を挙げなかった。

台湾の国家安全局が公表した2025年の分析では、中国による台湾の重要インフラへの侵入試行は1日平均263万件だった。2024年からは6%増えている。

Dreamが報告した多エージェント型の攻撃基盤

イスラエルのセキュリティ企業Dreamは8月12日、アジアの政府機関を対象とした多エージェント型AI攻撃基盤の分析を公開した。同社は標的国を明かしていない。一方、Financial Timesは標的を台湾と報じ、ロイターはFTがDreamの説明を最初に受けた媒体だと伝えている。

Dreamの初回ブログと後日の説明に食い違い

Dreamの初回ブログは「現実の政府インフラへの侵害を確認した」との趣旨で攻撃基盤を説明している。85件の認証情報・2,564件超の人事記録なども、同社が復元した作業領域に基づく結果として掲載された。

一方、Dreamの広報担当者は8月13日のCSO Onlineへの回答で、同社の調査では対象組織のシステムが侵害されたと確認した証拠は得ていないと説明した。初回ブログの表現と後日の説明は整合していない。

そのため、以下の数値はDreamの自社調査で報告された内容として扱う必要がある。台湾政府が同じ数値を公表した事実も、第三者が被害規模を独立検証した事実も確認できない。

160MB・1,395ファイルの作業領域から分析

Dreamによると、同社のThreat Researchチームは7月上旬に攻撃基盤の作業領域を発見した。容量は160MBを超え、1,395件のファイルが含まれていたという。

同社はこの記録から攻撃工程を再構成したとしている。ただしロイターの取材に対しては、データの共有も標的政府の名指しも断った。

最大8体のサブエージェントが12回の攻撃波を実行

Dreamは、基盤がオープンソースのAIエージェントであるHermesとOpenClawの上に構築されていたと報告した。Hermesの公式サイトはNous Researchが開発したMITライセンスの自律型AIエージェントと説明しており、OpenClawも公式サイトでオープンソースと明記している。

Dreamの記録では、7月1日から4日までに12回の攻撃波があった。1回の波で最大8体のサブエージェントが同時に展開され、AからQまでの識別記号が確認されたという。

最初の工程では、政府ポータルのJavaScriptから埋め込みURL・APIエンドポイント・OAuthクライアントIDなどを抽出したとDreamは説明する。そこから接続先の21システムと全国SSOの構成を洗い出したとしている。SSOは、一度の認証で複数のシステムを利用できるようにする仕組みだ。

ある標的では36以上のAPIエンドポイントが見つかり、その多くが認証を要求しない状態だったという。Dreamは、氏名・所属部署・SSOアカウントIDを含む職員データベース全体を認証なしで露出させていたシステムがあったと報告した。

Dreamが報告した85アカウントと2,564件超の人事記録

Dreamによると、基盤は認証不要のAPIから職員のユーザー名を集め、ある省庁のオフィス自動化ポータルへパスワードスプレーを仕掛けた。多数のアカウントに対し、推測しやすいパスワードを順に試す手法である。

同社は、CAPTCHA画像をTesseract OCRで全て正解したと報告している。職員IDの表記を変えるなどの規則性を試し、複数回の試行で85アカウントの認証を突破したという。

Dreamのブログでは、85アカウントのうち84件がSSOの連携口を通じて内部情報システムの認証に成功したとされ、割合は98.8%だ。同社は2,564件を超える人事記録・全利用者のJSON形式データベース・SSOクライアントシークレット7件・内部データベースの認証情報6件などを抽出したとも報告した。

人事記録の内訳は、職員1,409人分・認証不要APIから取得した利用者916人分・「Ministry of Justice」の認証不要エンドポイントから取得した法曹239人分だという。

Dreamは標的国を明かしていないため、これを台湾の法務部と断定する根拠はない。また、署名アルゴリズムをnoneに設定したJWTを受け付けるAPIも見つかったと同社は報告している。

原子力安全機関やエネルギー企業にも探索が及んだとDreamは報告

Dreamは、主要な標的以外にも探索範囲が広がったと説明している。対象として挙げたのは政府IT関連の調達先・原子力安全を担う機関・政府の電子メールシステム・7社以上のエネルギー企業だ。

一方、成果が出なかった工程も記録されている。ファイルアップロードAPIを通じてWebシェルを設置したものの、別階層の認証機能に阻まれ、実行には至らなかったという。Webシェルは、サーバー上に置いて遠隔操作に使うプログラムを指す。

Dreamが分析した判断自動化の仕組み

Dreamは、今回の基盤が単純な作業自動化だけではなく、攻撃経路の優先順位付け・技術調査・自己検証まで自動化していたと分析した。同社が挙げた特徴は、確率にもとづく経路の並べ替え・手詰まり時の技術調査・誤検知の自己訂正である。

ベイズ推定で14本の攻撃経路を並べ替え

Dreamによると、基盤は発見した脆弱性ごとに事後確率を割り当て、14本の並列な攻撃経路を継続的に並べ替えていた。確率が0.95を超えた脆弱性は攻撃経路へ昇格させ、0.30を下回るものは追加の労力を割かない設計だったという。

SSOによる横展開を狙う経路には99%の成功確率が付けられていた。Dreamは、後に85件中84件のアカウントが内部システムへの認証に成功し、結果が98.8%だったと報告している。

「学習サイクル」で新しい手口を調査

Dreamの分析では、基盤は「学習サイクル」と呼ぶ調査工程を備えていた。脆弱性データベース・GitHubのリポジトリ・セキュリティ研究の公開資料を検索し、標的の環境に当てはまる手口を集める工程だ。

記録には5回分の学習サイクルが残っていたという。Dreamは、標的国に固有の製品で報告されたCVEや、政府ポータルに共通する弱点まで整理されていたと説明している。

誤検知を取り消す検証工程

Dreamは、基盤に誤りを検出して取り消す工程があったと報告した。12波分の最終集計には、確認済みとされた脆弱性と並んで7件の誤検知が明示されていたという。

同社が示した例は、登録画面へのSQLインジェクションの誤判定だ。21秒の応答遅延を攻撃成功と解釈したものの、再検証で原因が確認メール送信時のSMTPタイムアウトだと判断され、この項目を除外したとしている。

Dreamによると、確認済みと分類する脆弱性には発見したエージェント自身の検証に加え、独立した3体のエージェントによる再検証を2巡課していた。一つの発見について6回の再テストを行う設計だったという。

「認可されたテスト」という説明でガードレールを回避

Dreamの初回ブログは、モデル側の拒否応答を、活動全体を「認可されたペネトレーションテスト」と説明することで回避したと報告している。初回ブログでは、利用されたLLMのモデル名を特定していなかった。

その後、Dreamの広報担当者はCSO Onlineに対し、DeepSeek-V4-Flashの利用を示す証拠を確認したと説明した。ただし、利用されたモデルがそれだけだったかは分からないとしている。

同様に正規の防御テストを装う手法は、Anthropicが2025年11月13日に公表したGTG-1002でも確認されている。Anthropicは、中国政府が支援するグループだと高い確信度で評価した主体がClaude Codeを悪用し、約30組織を標的にしたと報告した。AIが戦術的作業の80～90%を担ったとしている。

Anthropicの報告では、攻撃者はClaudeに正規のサイバーセキュリティ企業の従業員だと説明し、防御目的のテストだと信じ込ませる形で安全機構を迂回した。

台湾政府の公表とDream分析の同一性は未確認

台湾政府の報道資料とDreamのブログは、いずれも7月のAIエージェントを使った政府機関への攻撃に言及している。ただしDream自身は標的国を公開しておらず、台湾と特定したのはFinancial Timesなどの報道だ。

8月13日のCSO Onlineは、Dreamと台湾当局のどちらも両者の関連を明示的に確認していないと報じた。デジタル発展部の公式報道資料にDreamへの言及はなく、Dreamのブログにも台湾との記載はない。

台湾側は規模・被害・標的を明かしていない

デジタル発展部の発表は、攻撃の規模・被害の程度・標的となった機関を具体的に示していない。Dreamが報告した85アカウントや2,564件といった数値に対応する記述もない。

さらにDreamはCSO Onlineへの回答で、対象組織のシステムに確認済みの侵害があったことを示す証拠は得ていないと説明している。台湾政府の発表とDreamの初回ブログにある被害数値を結び付ける根拠は確認できない。

攻撃期間と警戒情報の発出時期は一致しない

Dreamが記録した攻撃期間は7月1日から4日までだ。一方、デジタル発展部が資安院による警戒情報の発出を始めた日は7月20日である。

台湾側は攻撃を7月に検知したとだけ述べており、正確な検知日は公表していない。そのため、7月1～4日の記録と7月20日の警戒情報が同じ事案の時系列に属するかは判断できない。

中国への帰属は確認されていない

Dreamは今回の攻撃を、中国政府にも特定のハッキンググループにも帰属させていない。同社が示したのは運用記録の言語分析であり、内部の状況報告に簡体字が、標的向けの分析に繁体字が使われていたとしている。

Dreamはこの特徴から中国語話者による運用を示唆した。言語の使い分けだけで国家主体を特定することはできず、台湾のデジタル発展部も国名を挙げていない。

Dreamが指摘した攻撃コストの低下

Dreamは初回ブログで、攻撃を実行する費用は大きく下がった一方、防御する費用は同じようには下がっていないと主張した。これは同社による評価であり、今回の数値から独立に検証された結論ではない。

完全な自律ではないという専門家の指摘

セキュリティ研究者で、コードセキュリティ企業Semgrepのセキュリティアドボケイトを務めるCris Thomas氏は、ロイターの取材でAIエージェントの力を誇張すべきではないと述べた。

「どこかに人間がいる。誰を攻撃するかを選び、目的を定め、指示を与えた者がいた。完全に100%自律しているわけではない。指揮を執る有能な運用者がいたということだ」（Thomas氏）

台湾が示した対応と監視

デジタル発展部は、AIから派生した新型の脅威に対して防護指針を定めたと説明している。各機関のシステム監視・機関をまたぐ情報連携を強化し、多層の防護と即時の対応で攻撃の早期遮断を図る方針だ。

今回の攻撃で把握した特徴は、政府全体の防御力を高める材料として使うという。あわせて、他に潜在的な攻撃経路が残っていないかの監視も続けるとしている。

既存の設定不備とAIエージェントの組み合わせ

Dreamの初回ブログは、実際の侵入につながったと分類する経路として、デバッグ用エンドポイント・署名を検証しないJWT・認証のないAPIを挙げている。同社はこれらを、標準的なブラックボックステストで発見できるサーバー側の不備と説明した。

台湾政府も、AIエージェントが複数の攻撃手法を素早くつなぎ、二次的なシステムを踏み台として使う点を警戒している。両者に共通するのは、既存の攻撃手法が連結・並列化された運用上のリスクへの指摘だ。