台湾在住の1人がAIエージェント12体で11か国を攻撃、Acronisが報告

Acronisが台湾在住の1人による攻撃を公表

セキュリティ企業Acronisの脅威調査部門（TRU）は2026年11月4日、AIエージェントを組み合わせた攻撃の調査結果を公表しました。それによると、国家級の集団に似た規模の攻撃を、台湾・花蓮市に住む1人の攻撃者がAIエージェントの集まりで実行していました。

Acronisはこのエージェントの集まりを「BOSSAI」と呼んでいます。発見のきっかけは、設定に不備のある開発用サーバーと思われた1台でした。Acronisが調べたところ攻撃の基盤一式が見つかり、ファイルは9万件超・合計9GBにのぼったそうです。AIとの会話や攻撃者のコマンド履歴、盗んだデータまで残っていました。

攻撃者を1人と判断した根拠は、身元の使い回しです。攻撃用のサーバーと、攻撃者が営むガス配達や自社サービスの事業が同じ自宅の回線で運用されていて、GitHubのアカウントやロゴも共通していました。Acronisはこの判断に強い確信があるとしています。一方で、攻撃者が特定組織に属しているのか、何を目的にしていたのかは、解明に至っていない状況にあります。

AIを攻撃に使う事例は、他の調査でも報告されています。韓国では10月、AIを使う侵入テストツールで金融機関が攻撃されました。

稼働は12体のうち9体、標的は11か国の数百組織

BOSSAIを構成するAIエージェントは12体です。ただし調査時点で稼働していたのは9体で、残る3体は用意されたまま未使用でした。それでも、12日間の観測で、救急サービスや銀行、大学、軍のシステムまで11か国で数百もの組織が標的になりました。

標的には電話帳やECサイト、ギャンブルサイトも含まれ、業種にまとまりはありません。Acronisは、侵入できる組織をできるだけ増やし、それを金銭に換えることが狙いだったとみています。1人でここまで手を広げられる攻撃者を、Acronisは「AIで強化された脅威」（AAT）という新しい分類で呼び始めました。

侵入が確認されたのは3か国の約10の標的

BOSSAIの攻撃で、データの持ち出しかシステムへの侵入が確認されたのは、3か国の約10の標的でした。つまり、数百の組織が狙われたわりに侵入に至った先はごく一部で、約15の標的は攻撃を受けましたが、侵入は確認されないままとなっています。

残る8か国の組織は、偵察か攻撃準備の段階にとどまっています。日本の組織を探す検索も用意されていましたが、調査時点では実行されていませんでした。

BOSSAIによる攻撃の規模（Acronisの報告より）

対象	内容
攻撃者	台湾・花蓮市に住む1人（Acronisの評価）
AIエージェント	12体（調査時点で稼働は9体）
観測期間	12日間
狙われた国	11か国（数百の組織）
侵入を確認	3か国の約10の標的
攻撃されたが侵入は未確認	約15の標的
偵察・攻撃準備のみ	8か国

台湾の救急記録が流出、メキシコでは電話番号20万件超を収集

主に盗まれたのは、認証なしで閲覧できた救急患者の記録と、氏名と住所が分かる住民の電話番号でした。 侵入が確認された3か国は、台湾・メキシコ・タイです。最も多く狙われたのは台湾で、救急サービスや金融機関、政府のポータル、消防の出動システムを開発する業者が標的になっています。

台湾の貸付サービス会社では、データベースにSQLインジェクションを仕掛けられる場所が16か所見つかり、口座情報が持ち出されました。消防の出動システムを開発する業者は、管理画面に初期設定のまま残った管理者の認証情報でログインされ、18以上のテーブルが閲覧できる状態になっています。

メキシコでは、侵入とは別の形で個人情報が集められています。エージェントは3つの都市と12の高級住宅地を対象に電話帳を作るよう指示され、公的な統計や郵便番号の情報を組み合わせました。まとめた住宅電話番号は、名前・住所・郵便番号つきで約20万6,800件にのぼります。イエローページから集めた約12万4,000件も別にあります。

台北の救急患者記録は認証なしで閲覧可能な状態

台北の消防局では2018年の心電図や救急車の映像が認証なしで閲覧できる状態で、別の119番の出動システムからは台北市内7区の出動記録が持ち出されました。 心電図などは救急患者の記録を残す仕組みに保存されていて、患者のバイタルサインも含まれていました。Acronisは、確認できた被害の中で最も重いものとしています。

出動記録には、発生時刻や出動の種類、対応の状態、通り単位の場所が入っていました。ただし、取られたのはシステムのAPIに残る過去の記録です。Acronisによると、走っている救急車の現在地がリアルタイムで流出したわけではありません。

タイの3大学からSQLインジェクションでデータを持ち出し

タイでは45の大学が自動で狙われ、うち3つの大学でデータの持ち出しが確認されました。 タイの標的は、ほぼ大学だけです。エージェントは検索エンジンで489の標的候補を見つけ、点数の高い大学から順に入口を試しています。

ある大学では、修正されていないOracleのデータベースから2,563行の管理者のテーブルが持ち出されました。数百の標的を同時に素早く調べられる以上、見つかりにくいことはもう対策にならないとAcronisは指摘しています。一方で、認証や通信制限が正しく設定されたシステムでは、エージェントの攻撃はほとんど通用しなかったそうです。

侵入が確認された主な被害（Acronisの報告より）

国	狙われた先	確認された被害
台湾	台北の消防局の救急患者記録	2018年の心電図・救急車の映像・バイタルサインが認証なしで閲覧可能
台湾	ある市の119番の出動システム	台北市内7区の出動記録を持ち出し
台湾	貸付サービス会社	SQLインジェクションの入口16か所、口座情報のテーブルを持ち出し
台湾	消防の出動システムの開発業者	初期設定の管理者の認証情報でログインされ、18以上のテーブルが閲覧可能
メキシコ	住民の電話帳	名前・住所つきの住宅電話番号約20万6,800件をまとめた
タイ	大学	45大学のうち3大学でデータを持ち出し

AIエージェントは役割を分け、攻撃者が結果を手作業で中継

10月には、中国系の集団がAIエージェントで攻撃を自動化していたことも公表されています。BOSSAIの特徴は、1人がエージェントを役割ごとに分けて使っていた点です。

BOSSAIを構成するエージェントの役割（Acronisの報告より）

役割	主なエージェント	使われたモデル
攻撃の基盤を組み立てて保守する	Grok、OpenClaw、Claude Code、Codex	主に商用のモデル（Claude CodeとCodexは攻撃用のモデルへつなぎ替え）
標的を調べて攻撃する	Hermes、Cursor、Trae、CyberStrike	安全対策を除去したモデル
脆弱性を探して報告する	HalberdStrike、不正に入手したAcunetix	主にローカルモデル

エージェント同士は直接つながっておらず、1人の攻撃者がある画面の出力を別の画面へ貼り付けて攻撃を進めていました。 例えば台湾の救急サービスへの攻撃では、HalberdStrikeが作った診断の報告をHermesがまとめ、その報告を受け取ったCursorが攻撃を実行しています。指示は繁体字中国語で出され、HermesはWeChat、OpenClawはLINEからも操作できました。

エージェントは最も多い時でMCPサーバー13台につながり、nmapやsqlmap、Metasploitといった攻撃用のツールを、攻撃者の操作なしで呼び出せる状態でした。

攻撃役のほぼすべてで、安全対策を除去したモデルが動作している

攻撃を実行したエージェントのほぼすべてが、安全対策の調整を除去したDeepSeekやGLM、Qwen系のモデルを使っていました。主な攻撃役のHermesは、約95回のセッションで1万8,311件のメッセージを出しています。

さらに、攻撃役は確認なしで操作を自動承認する設定になっており、Hermesのメッセージの83.5%がツールの自動実行とその結果でした。 攻撃者の指示はURLだけのことも多かったそうです。

Hermesへの指示には、「判断はすべて任せる。悪用できると確認したときだけ報告せよ」という趣旨の文がありました。モデルは19日間で少なくとも9種類を入れ替えていて、攻撃者がローカルに置いた、RTX 4090を積むサーバーなどで実行されていました。

商用のGrokとMiniMaxは攻撃の指示に応じず

攻撃者は当初、商用のモデルを使う計画でした。ところが、商用のモデルは合法である証明を求め、証明が無いと攻撃指示を実行しなかったため、攻撃者は性能の低いローカルモデルに頼りました。

Grok 4.5は14回のセッションで基盤づくりに使われましたが、攻撃をはっきり求める指示は、ほぼすべて拒否しています。例外は、壊れた検証用スクリプトを修正した1回だけです。MiniMax M3も約17回のセッションで攻撃指示を一度も実行せず、タイのコンピューター犯罪法に言及し、書面許可が無ければ手伝えないと回答しました。

ただし、偽の許可書を作って見せていたらどうなったかは分からないと、Acronisは付け加えています。

AIの報告は誤りが多く、存在しない脆弱性も含まれる

AIエージェントは結果を大量に出す一方で誤りも多く、その出力は1人で確認しきれる量を超えていました。 Acronisの報告には、エージェントの失敗事例が数多く記録されています。Acronisによると、侵入がなかなか成功しなかった理由の1つは、エージェント自身が脆弱性を捏造し、成果を大きく報告したことです。

AIが深刻と判定した結果の半分以上は誤検知か分類の誤り

脆弱性を探すHalberdStrikeは、性能の低いローカルモデルで実行されていました。深刻度「高」と「重大」と判定した結果のうち、半分以上が誤検知か分類の誤りだったそうです。接続に失敗しただけの結果を「重大な遠隔操作の脆弱性」と報告した例もあり、攻撃者は途中から、捏造を防ぐ指示をツールに追加しています。

同じ誤りは台湾の公的機関でも見つかっています。国の災害対応センターには存在しないApacheの深刻な脆弱性が報告され、ツール自身の見直しで全件が誤検知か分類の誤りに改められました。 該当する通信の口は閉じていて、Apacheが使われていることすら確認できていませんでした。

範囲外と判断し、ホンジュラス軍のシステムへの攻撃を中止

エージェントは、攻撃者が想定しない判断もしていました。メキシコの電話番号を集める途中で、Hermesはホンジュラス軍の人事システムに行き当たり、一度は攻撃を試みています。ところが、判断を任されたエージェントは、攻撃者に相談しないまま、行き当たった軍の人事システムを範囲外として手放しました。

攻撃者が知っていれば、さらに先へ進めていたかもしれないとAcronisはみています。エージェントは処理が速い分、出す情報が多く、攻撃者は裏で起きていることの多くを見落としかねません。

公開システムの管理者とAIエージェント導入企業の備え

BOSSAIは1人で数百の組織を狙えた一方、侵入が確認されたのは約10の標的でした。AIで増えたのは偵察と攻撃の試行回数であり、適切な認証を突破する能力ではありません。したがって、侵入を許したのは昔からある弱点で、AIエージェントを利用する側も、攻撃者が無効にした安全装置を自社では残しておくことが対策になります。

立場ごとの備え（IPAの資料とAcronisの報告より）

立場	BOSSAIで起きたこと	備え
公開システムの管理者	修正していないデータベースや開いたままのポート、初期設定の認証情報から侵入された	修正プログラムの適用・公開範囲の見直し・認証の強化
AIエージェントを導入する企業	確認の仕組みを無効にしたエージェントが誤りと見落としを重ねた	権限の最小化・危険な操作の承認・ツール呼び出しの記録

公開システムの管理者として：古い弱点を先に塞ぐ

被害は2018年から開いたままのポートや、初期設定のまま残った管理者の認証情報など古い弱点に集中していたため、新しい対策よりも先にこれらを塞ぐ必要があります。 Acronisの報告にある被害は、2018年から開いたままのポートから盗まれた医療データ、APIに残っていた出動記録、本番環境の16か所でSQLインジェクションが可能だった金融機関の口座情報でした。

IPAが10月9日に公開した事業者向けの注意喚起も、外部公開しているアプリケーションの点検を最初に取り組む対策としています。

修正プログラムの適用漏れをなくす

タイの大学では修正していないOracleのデータベースが入口になったため、外部公開システムの未適用パッチを洗い出して、適用しておくといいでしょう。IPAは、外部公開アプリケーションの構成要素に未適用の脆弱性対応パッチが無いかを確認し、見つかればできるだけ速やかに適用するよう勧めています。点検対象には、アプリケーション本体だけでなく、その裏で使われているデータベースも含めましょう。

外部公開する範囲を見直す

2018年の医療データは、認証なしで接続できるポートから盗まれていました。インターネットからの接続が不要な画面やポートは、外部公開をやめましょう。社外から使う必要のない管理画面や古いAPIは、社内ネットワークからしか開けない設定に改めると、エージェントが一度に調べても入口として見つかりにくくなります。

初期パスワードを変更し、多要素認証を導入

消防のシステム業者は、初期設定のまま残った管理者の認証情報で管理画面に入られました。IPAも、外部公開しているアプリケーションの対策に、認証機能（多要素認証・パスワード）の強化を含めています。管理画面のパスワードを変更したうえで、多要素認証を設定しましょう。パスワードが流出しても、スマートフォンに届くコードが無ければ管理画面にログインできない状態にしておきます。

AIエージェントを導入する企業として：自動承認に任せない

BOSSAIの攻撃者は、確認の画面を出さずに操作を自動で承認する設定でエージェントを使っていました。HalberdStrikeでは、範囲と安全を確かめる仕組みも無効でした。

つまり、確認の仕組みを無効にしたエージェントは誤りを重ねるため、自社のエージェントでは権限の制限と人の承認、記録を残します。 IPAの産業サイバーセキュリティセンターが2026年7月に公開した手引書には、そのための基本対策が3つあります。

エージェントの実行権限を最小限にする

AIが本来の権限を超えて操作するリスクが特に高まるのは、最小権限原則が守られていない環境です。エージェントが触れるシステムとデータを業務に必要な範囲だけにすれば、乗っ取られたり誤ったりしても被害が及ぶ先が限られます。手引書は、連携先システムでの実行権限を最小限にすることと、ユーザーごとにAI経由で触れる範囲を制御することを、組み合わせて行うよう勧めています。

削除や外部送信は人の承認を必須に

IPAは、削除や更新、外部への送信、設定の変更といった高リスクな操作の前に人の承認を求めることを、最終防衛線としています。ただし、承認の対象が多すぎると担当者が慣れてしまい、承認が形骸化すると注意を促しました。データの削除や外部への送信といった危険な操作だけは実行前に人の承認を挟み、承認の対象を限定して形だけにならないようにします。

ツールの呼び出しを記録に残す

BOSSAIでは、エージェントの誤りは結果同士が合わない箇所から見つかっていました。どのツールがどの引数で何回呼ばれたかを記録しておけば、AIが存在しない結果を報告しても後から確認できます。IPAも、ツールの呼び出しの記録が、異常な操作に気づくためにも、後から追跡するためにも使えるとしています。