AI が狙うセキュリティの盲点：外部接点から侵害が相次いだ2026年10月

AI が見つけたセキュリティの盲点

2026年10月、韓国と日本で相次いで公表された大規模なサイバー侵害事案の多くは、組織内部の基幹システムではなく、インターネットに公開された Web サービスやアプリのバックエンド API、外部委託先が提供する SaaS（メール配信やバックアップなど、外部事業者がクラウド経由で提供するサービス）など、組織の周辺にある接点が侵入の足掛かりとなっていた。同じ時期には、PHP や Node.js などの Web バックエンドランタイム、GitLab など広く利用されているソフトウェアで、認証なしにリモートコード実行が可能となる脆弱性が相次いで公開された。さらに、ARTEX などの AI エージェントが実際の攻撃に使われたとの報告も相次いだ。

韓国では9月末、大手銀行での被害を皮切りに、貯蓄銀行、信販・リース会社、相互金融機関、暗号資産事業者、保険会社へと被害が金融業界全体へと広がった。企業向け会計ソフトウェア事業者、大規模教会、大学、フランチャイズ企業など、金融業界以外でも情報漏えいが確認された。日本でも同時期に、数百万件から数千万件規模の個人情報漏えいが相次いで公表された。日本の関係機関も、公開されているアプリを解析し、接続先のバックエンドサーバーを狙う攻撃手法に警鐘を鳴らしている。

こうした傾向は、韓国と日本に限らない。同時期には米国、欧州、中南米でも、委託サービスや外部公開 Web サイトを経由した侵害、AI エージェントを利用した大規模な自動攻撃が報告されている。本稿では、報道、各機関の発表、セキュリティ企業のレポートを総合し、特に多くの事例が公表された韓国と日本を中心に共通する攻撃パターンを整理するとともに、同様の傾向が海外でも確認されていることを紹介する。そのうえで、企業が確認すべき予防策と対応策を提示する。なお、個々の事案の原因は現在も調査中である場合が多く、被害組織の名称は伏せ、報道で確認できる業種のみを記載した。

韓国の金融業界で相次いだ侵害

韓国の金融業界では9月末に大手銀行で被害が確認され、約1か月の間に業界全体へ広がった。金融当局によると、10月14日時点でサイバー攻撃の被害が確認された金融機関は、銀行、貯蓄銀行、信販・リース会社、相互金融機関、電子金融事業者、オンライン投資連携金融事業者、暗号資産事業者など計16社に上り、確認された個人情報の漏えい件数は約10万件だった。ただし、被害を受けた金融会社の数に比べると漏えい件数は比較的少なく、大規模なデータベース（DB）そのものが窃取されたのではなく、外部公開の照会サービスなどを介して個別の情報が不正に照会された可能性が考えられる。その後、10月26日には保険業界でも情報漏えいが報告された。

注目すべき点は、攻撃対象が預金や振込を処理する銀行の基幹システムではなかったことである。公開情報によると、融資仲介業者向けの専用照会サービス、従業員向け営業支援システム、共済関連の外部 Web ページなど、主要サービスを支える周辺システムが侵入経路となっていた。

［表1］韓国の金融機関で確認された主な侵害事例

金融当局が10月初旬に金融会社555社を対象に実施した緊急点検では、130社でセキュリティ対策の不備が報告された。主な問題は、最新のセキュリティパッチの未適用、サポートが終了したシステムの管理不備、24時間監視体制の未整備だった。攻撃者が新たな手法を用いたというよりも、管理の行き届いていない周辺システムが攻撃者に狙われたとみる方が実態に近い。

今回の金融業界への攻撃では、AI を利用した自律型ペネトレーションテストツール「ARTEX」の痕跡が確認された。韓国のセキュリティ業界は、攻撃に使われた Web サーバーから ARTEX に関連する文字列を確認した。また、CrowdStrike は、攻撃者のサーバー上で公開状態になっていたフォルダーから、ARTEX の設定ファイルと AI コーディングツールの作業記録を入手した。攻撃者は ARTEX に DeepSeek、GLM、Grok など複数の大規模言語モデル（LLM）を接続して使用していたと分析されている。ただし、攻撃者の身元や国籍は特定されていない。

金融業界以外にも広がる被害

同じ時期、金融業界以外でも情報漏えいが相次いだ。企業向け会計ソフトウェア事業者、大規模教会、コーヒーチェーン、大学、地方教育行政機関など、被害に遭った組織は多岐にわたるが、侵入経路・被害箇所はいずれも従業員の VPN アカウント、外部バックアップソリューション、クラウド上に残された一時ファイル、ポータルサイト、学習用クラウドアカウントなど、基幹業務システムの周辺にある接点だった。

［表2］韓国の非金融分野で確認された主な侵害事例

このうち、企業向け会計・ERP ソフトウェア事業者の事例は、委託先を介して被害が広がるサプライチェーン上のリスクを示している。同社の会計プログラムは11万社以上の企業に利用されており、1件の侵害が顧客企業の従業員の給与情報や納税情報などに波及する懸念が指摘された。ただし、実際の漏えい範囲は現在も調査中である。コーヒーチェーンの事例では、以前のサービス改修用に作成された一時データファイルがクラウド上に残され、そこから情報が漏えいした。不要になったデータを削除せずに残しておくこと自体がリスクになることを示している。

10月下旬には、生成 AI を悪用したハッキング事件の容疑者が韓国で初めて摘発された。警察によると、犯行グループの首謀者は IT を専門に学んだ経歴はなくで、独学で技術を習得した後、セキュリティ企業でペネトレーションテスト業務に従事した経験があった。このグループは ARTEX と AI コーディングエージェントを組み合わせ、韓国企業約90社から個人情報など約820万件を窃取した。特に8月末からの44日間で60社を攻撃したという。警察は、この事件と金融業界の侵害事案との直接的な関連は確認されていないと説明した。

日本でも相次ぐ、周辺システムを狙った攻撃

日本でも同時期に、大規模な情報漏えいの公表が相次いだ。日本のセキュリティ企業マクニカの集計によると、日本国内で Web システムを通じた個人情報漏えいが公表された事例は、2026年10月6日までに119件に達し、2025年通年の84件、2024年の62件をすでに上回った。このうち81件は7月以降に発生している。

日本の関係機関は、アプリの解析を起点にバックエンドを狙う手法にも注意を促している。情報通信研究機構（NICT）は10月13日、公開されている Android アプリを解析し、接続先サーバーや API の構造を把握したうえでサーバー側の脆弱性を攻撃する手法を「A2B（App-to-Backend）攻撃」と呼んだ。主な標的となる脆弱性は、SSRF、リモートコード実行（RCE）、SQL インジェクション、IDOR/BOLA である。アプリ自体に欠陥がなくても、サーバー側の API に問題があれば情報漏えいにつながる。JPCERT/CC も10月8日、既知の脆弱性の探索、アプリ解析を通じた管理用 API の悪用、BI ツール「Metabase」の SQL インジェクション脆弱性（CVE-2026-72898）の悪用、Web シェルの設置を主な攻撃類型として挙げた。ただし、両機関とも個別の被害企業を特定していないため、特定の事案を A2B 攻撃と断定することはできない。

［表3］日本における主な情報漏えい事例と侵入経路・被害箇所

日本の事例でも、多くは基幹システムではなく周辺システムが侵入口となっていた。特に百貨店グループの事例は、単一の予約サイトへの侵害がグループ共通 ID の会員全体に影響を及ぼしたケースである。電子書籍サービスの事例は、会員 DB を保護していてもログに同じ情報が残っていれば漏えいにつながり得ることを示している。

ARTEX の使用は日本でも確認されている。日本のセキュリティ企業「GMO サイバーセキュリティ by イエラエ」は10月19日、日本国内の企業を攻撃したインフラから ARTEX の使用痕跡を確認したと発表した。 同社が攻撃対象として確認した企業のうち8社は、9月から10月にかけて情報漏えいを公表している。ただし、企業名は公開されておらず、韓国での攻撃と同じ攻撃者によるものだとする根拠もない。現段階では、韓国と日本の双方で同じツールが使われたことが確認されているにとどまる。

短期間に相次いで明らかになった重大な脆弱性

10月第3週には、Web やインフラを支える基盤ソフトウェアで、深刻な脆弱性が数日のうちに相次いで公表された。その多くがインターネットに直接公開される構成要素だったことから、外部に公開されたシステムのリスクを一層高めた。

［表4］2026年10月に公表された主な脆弱性

PHP2Shell の事例は、脆弱性が明らかになってから対処するまでの猶予が短くなっていることを浮き彫りにした。脆弱性情報はパッチの配布前に外部へ流出しており、Amazon の脅威インテリジェンス部門は、正式公表の4日前に当たる10月17日の時点ですでに攻撃の試みを検知していた。韓国でも政府が10月22日、民間分野のサイバー危機警報を「関心」から「注意」に引き上げた。このため、パッチ適用済みのサーバーであっても、情報公開の前後におけるアクセスログと Web シェルの設置有無を併せて確認する必要がある。

Oracle Java の CVE-2026-91403 は、コードの不具合を修正する一般的なパッチではなく、信頼性が損なわれた eMudhra の中間 CA 証明書を Java が信頼しないようにする更新である。ブラウザー側でブロックされていても、Java のように独自の信頼ストアを持つランタイムや旧式のクライアントは別途更新が必要となる。PKI に関する問題は、サーバーの更新だけで対処できるとは限らない。

脆弱性の発見においても、AI の役割が拡大している。BIND の CVE-2026-94300 は OpenAI に所属する研究者が報告し、Node.js の公式告知では CVE-2026-111497 が OpenAI Codex Security の成果として記録されている。これらは防御側による正当な脆弱性研究だが、同様の能力が攻撃側にも利用され得ることを踏まえると、脆弱性の公開からパッチ適用までに確保できる時間は、今後さらに短くなるおそれがある。

エージェンティック AI を悪用した攻撃、実証から実際の侵害へ

AI エージェントが偵察から脆弱性の探索、侵入、Web シェルの設置までを自律的に進める攻撃が、実際の被害事例でも確認されるようになった。10月に公表された主な報告は次のとおりである。

［表5］エージェンティック AI を悪用した実際の侵害事例に関する報告

AhnLab では、ARTEX を独立したテスト環境で再現し、人の操作を介さずにどこまで侵入できるかを検証した。セキュリティの専門知識がないユーザーでも入力できる「対象のシステムに侵入して」といった短い指示を与えただけで、ARTEX は人間の介入なしに Web サーバーのファイルアップロード機能を見つけ、Web シェルを介してプログラムを実行した。Apache ActiveMQ が公開された環境では、既知の脆弱性（CVE-2023-46604）を利用して初期侵入を果たした後、内部ホスト4台でリモートコマンドを実行する段階にまで達した。どちらの実験でも、新しい攻撃手法ではなく、公開サービスの脆弱性や設定不備が悪用された。これは、AI エージェントがまず外部に公開された弱点を狙うという本稿の見方を裏付けている。

また、元の GitHub リポジトリが削除された後も、ARTEX は複数の運用者によって名前や画面を変えながら再利用されている。AhnLab が確認した再配布版には、DeepSeek、GLM、Kimi、Claude など複数の LLM に関する設定のほか、認証なしで悪用できる EC プラットフォームの脆弱性（CVE-2026-75650）の公開 PoC を実行し、IRC ベースの遠隔操作コードを仕込んだ痕跡が残されていた。開発者が公開を中止しても、ツールの拡散は止まらないことを意味している。

これらの報告から見えてくる変化は、攻撃の低コスト化である。Cairn の事例では、運用者は100文字にも満たない中国語の指示文を入力しただけで、その後はエージェントが人間の監督なしに各サイトでコードを実行する方法を探し、Web シェルを設置した。脆弱性の探索、攻撃経路の試行、ペイロードの修正、失敗後の再試行など、これまで熟練者が必要だった反復作業を、エージェントが何時間も連続して処理するようになっている。オープンウェイトの AI モデルと無償公開されたエージェントフレームワークを容易に組み合わせられるようになり、かつては高度な技術を要したサイバーサイバー攻撃を仕掛けるための技術的なハードルが大幅に下がった。韓国で逮捕された IT 非専攻者のハッカーの事例も、こうした変化を示している。攻撃作戦の実行コストも、それに伴って急速に下がっている。

Microsoft の事例は、この種の攻撃がどこに向かっているかを示している。Storm-0940 によるパスワード総当たり攻撃では、1分間に最大2,900回のログイン失敗が発生したものの、成功した試行は1件もなかった。実際の侵入は、顧客がすでにアクセス権限を許可していた委託サービスのアプリ ID を通じて行われた。認証そのものは突破されなかったが、すでに信頼されていた外部サービスとの接続が侵入口になったのである。

ARTEX のようなツールが韓国の金融業界の事案に実際にどの程度関与していたのかは、現在も調査中である。ただし、公開された報告だけを見ても、AI エージェントによる攻撃が仮説の段階を超え、実際の侵害に使われていることは明らかだ。また、公表された事例は全体の一部にすぎない可能性が高い。

共通するパターン：突破されたのは外部接点だった

韓国と日本の事例を比較すると、ほぼ同じパターンが見えてくる。厳重に保護された内部の基幹システムではなく、外部に公開されたアプリのバックエンド API、予約サイト、管理ツール、委託先の SaaS といった周辺の接点が侵入口になった。本稿でいう「外部接点」とは、外部に公開された攻撃対象領域（External Attack Surface）に加え、サプライチェーンや第三者との接点も含む概念である。

［表6］外部接点の種類別に見た韓国と日本の事例比較

この分析結果は、AI エージェントを使った攻撃の技術的特徴とも一致する。自律型の攻撃エージェントは、堅牢に防御された基幹システムを正面から突破するよりも、広範な外部攻撃対象領域を自動的に網羅してスキャンし、対策が手薄になりがちな周辺システムの弱点を繰り返し突く。公開から時間がたった N-day 脆弱性、設定ミス、弱い認証などが典型的な標的となる。人手では後回しにされがちな小さな付随サービスも、低コストで動く AI エージェントなら広く探索できてしまう。

さらに厄介なのは、侵害がその接点だけで終わらないことだ。予約サイトからグループ共通の会員 DB へ、委託先のバックアップサービスから数万社の顧客データへ、委託先アプリの ID から顧客のクラウドテナントへと被害が広がった事例が、それを示している。小規模に見える外部接点であっても、重要なデータへ到達する経路になり得る。

予防策：外部に公開された資産を洗い出す

まず必要なのは、自社がインターネット上に公開しているシステムやサービスを正確に把握することだ。攻撃者は AI エージェントを用いて外部攻撃対象領域を網羅的に調査しているため、防御側も同じ視点から資産を把握し直す必要がある。特に、本来のサービスに付随するサービス、キャンペーンページ、管理ツール、アプリが呼び出す API など、これまで管理の優先順位が低かった資産から点検すべきである。

［表7］外部接点を中心とした予防点検項目

AI エージェントを利用した攻撃では、その速度の速さにも注意が必要である。最初の標的設定から特権アクセスの獲得まで3時間もかからなかった事例もある。手作業で点検し、数日以内にパッチを適用する従来のサイクルでは、対応が間に合わない可能性がある。Web アプリケーションファイアウォール（WAF）のルールを先行して適用したり、公開資産へのアクセスを直ちに遮断したりするなど、自動化された対応手段をあらかじめ整備しておく必要がある。一方、防御側も AI を用いた脆弱性点検を活用し、攻撃者に先んじて外部接点の弱点を見つけ出すことが望ましい。

対応：侵害が疑われる場合

サイバー侵害では、初動対応の速さによって被害規模が大きく変わる。今回の事例でも、攻撃から数日後になって初めて被害を認識したケースがあり、その間に情報漏えいが拡大した可能性もあった。

[表8］侵害が疑われる場合の段階別対応手順

守るべき範囲を見直すとき

この1か月の事例から見えてくるのは、守るべき範囲を見直す必要性だ。これまで多くの組織は基幹システムを中心に防御を設計してきたが、攻撃者はその外側にある小さな接点を見つけて侵入した。AI エージェントによって、その探索はより低コストかつ高速になり、規模が小さいために管理の優先順位が低かった資産が真っ先に標的となった。

これからのセキュリティ対策では、「何を最も厳重に守るべきか」だけでなく、「攻撃者はどこから侵入できるのか」を最初に問い直す必要がある。外部公開資産の管理、API の認証と認可、委託先との接続管理、多要素認証、迅速なパッチ適用、データの最小化は、決して新しい対策ではない。しかし、今回の事案は、こうした基本的な対策を外部接点まで漏れなく適用しなければ、AI を悪用する攻撃者にその隙を突かれかねないことを明確に示した。本稿が AI を利用した自動攻撃と外部接点からの侵害に焦点を当てた理由も、そこにある。