PHP、ARTEX…AI が見つけた弱点に揺らいだ10月
2026年10月、韓国と日本で大規模な侵害事案が相次いで公表されました。その多くは組織内部の中核システムではなく、インターネットに公開された Web サービスやアプリのバックエンド API、委託先 SaaS など、外部との接点から始まりました。同じ時期に、PHP や Node.js などの Web バックエンドランタイム、GitLab など広く利用されるソフトウェアで、認証なしにリモートコード実行が可能となる脆弱性が相次いで公開されました。ARTEX などの AI エージェントが実際の侵害に使われたとの報告も続いています。
韓国では9月末の大手銀行を皮切りに、貯蓄銀行、キャピタル会社、相互金融機関、暗号資産事業者、保険会社へと金融業界で侵害が相次ぎ、企業向け会計ソフトウェア会社や大規模教会、大学、フランチャイズなど、金融以外の分野でも情報流出が確認されました。日本でも同じ時期に、数百万件から数千万件規模の個人情報流出が相次いで公表されました。日本の政府機関は、公開アプリを分析してバックエンドサーバーを攻撃する手法を、主な原因の一つとして挙げています。
こうした動きは韓国と日本に限りません。同じ時期に米国、欧州、南米でも、委託サービスや外部公開 Web サイトを経由した侵害や、AI エージェントを使った大規模な自動化攻撃が報告されました。
アンラボ セキュリティ インテリジェンス センター（AhnLab SEcurity intelligence Center、ASEC）は、自社の分析、公開報道、各機関の発表、他のセキュリティ企業の報告を総合し、これらの事案に共通するパターンを明らかにするとともに、予防・対応策を提示しました。
本稿は ASEC が発行したレポートの要約です。レポート全文は ASEC ブログでご覧いただけます。
注：個々の事案の原因は大半が調査中です。被害組織は公開報道に基づき、業種単位で表記しています。
韓国金融業界：連鎖侵害の始まり
韓国の金融業界での侵害は9月末に大手銀行で始まり、1か月の間に業界全体へ広がりました。金融当局によると、10月14日時点で侵害が確認された金融会社は、銀行、貯蓄銀行、キャピタル会社、相互金融機関、電子金融業者、オンライン投資連携金融業者、暗号資産事業者など16社・機関でした。確認された個人情報の流出は約10万件です。ただし、被害を受けた金融会社の数を考慮すると、流出規模は比較的限定的と評価されています。
注目すべき点は、攻撃対象が預金や振り込みを処理する銀行の中核システムではなかったことです。公表情報によると、ローン募集人専用の照会サービス、社内職員向けの営業支援システム、共済関連の外部 Web ページなど、本サービスに付随するシステムが侵入経路となりました。
| 区分 | 侵害箇所 | 公表された内容 |
|---|---|---|
| 金融機関 A | ローン募集人専用の照会サービス | 正規の認証を回避した後、照会値を繰り返し入力し、約2万5,000人分のローン関連情報が流出 |
| 金融機関 B | 職員向け営業支援システム（ODS） | インターネットバンキングやモバイルバンキングとは分離されたシステムに不正アクセスがあり、89人分の情報が流出 |
| 金融機関 C | 共済関連の外部 Web ページ | 攻撃から2日後に被害を認識 |
[表1] 韓国金融業界の主な侵害事例と侵害箇所
今回の金融業界への攻撃では、AI 自律型侵入テストツール ARTEX の痕跡が確認されました。韓国のセキュリティ業界が、攻撃に使われた Web サーバー上で ARTEX に関連する文字列を初めて発見しました。また、CrowdStrike は攻撃者のサーバー上に公開されていたフォルダーから、ARTEX の設定ファイルと AI コーディングツールの作業記録を入手しました。攻撃者は ARTEX に DeepSeek、GLM、Grok など複数の大規模言語モデル（LLM）を接続して使用したと分析されています。ただし、攻撃者の身元や国籍は確定していません。
金融業界以外にも広がった侵害
同じ時期に、金融業界以外でも被害が続きました。企業向け会計ソフトウェア会社、大規模教会、コーヒーフランチャイズ、大学、教育庁など業種は異なりますが、侵害箇所は職員の VPN アカウント、外部バックアップソリューション、クラウドに残された一時ファイル、ポータル、学習用クラウドアカウントなど、中核業務システムの外側にある接点でした。
| 区分 | 侵害箇所 | 公表された内容 |
|---|---|---|
| 企業向け会計・ ERP ソフトウェア会社 | 職員の VPN アカウント、外部バックアップソリューション | VPN アカウントを使って開発サーバーに不正アクセス。バックアップソリューションの脆弱性を通じて暗号化データの一部が持ち出された疑い。政府が重大事故と判断し、官民合同調査団を設置 |
| 大規模教会 | 教会情報システム | 信徒約85万人の氏名や生年月日などを含むデータが流出 |
| コーヒーフランチャイズ | クラウドに残されていた一時データファイル | 暗号資産マイニングを目的とする不正アクセスの過程で約276万件が流出。過去のサービス改編時に作成された一時ファイルが原因 |
| 大学 | ポータルサービス | 在学生・卒業生など1万人余りの学籍番号、連絡先、メールアドレスが流出 |
| 教育庁 | 学習用クラウドアカウント | 6つの教育庁で11万件を超えるアカウントがハッキング被害 |
[表2] 韓国の非金融分野における主な侵害事例と侵害箇所
日本でも繰り返された同じパターン
日本でも同じ時期に、大規模な情報流出の公表が集中しました。日本のセキュリティ企業マクニカの集計によると、日本の組織で 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 に不備があれば情報流出につながります。10月8日には JPCERT/CC も、既知の脆弱性の探索、アプリ分析を通じた管理用 API の悪用、BI ツール Metabase の SQL インジェクション脆弱性（CVE-2026-72898）の悪用、Web シェルの設置を主な攻撃類型として示しました。ただし、両機関とも個別の被害企業を特定していないため、特定の事案を A2B 攻撃と断定することはできません。
| 区分 | 侵害箇所 | 公表された内容 |
|---|---|---|
| ソフトウェア販売 | 会員情報照会 API | API が4日間不正利用され、パスワードを含む会員情報が最大約2,252万件流出した可能性 |
| 大規模ディスカウントストア | アプリ、オンラインストアのサーバー | サービスを構成するソフトウェア機能を不正利用されて侵入を許し、最大約173万人分の情報が流出 |
| SaaS 企業 | メール配信 SaaS の API サーバー | 2台の API サーバーでコマンドが実行され、全契約者情報と一部顧客の配信先リストが持ち出された |
| 食品ブランドの日本法人 | 委託先 EC プラットフォーム | 委託先サーバーのソフトウェア脆弱性が悪用され、約314万件が流出 |
| 百貨店グループ | 予約サイトから顧客管理システムへ | 予約サイトを経由して顧客管理システムにアクセスされ、グループ共通 ID の会員のほぼ全員に当たる約126万件が流出 |
| ニュースプラットフォーム | 業務用管理ツール | 管理ツールの脆弱性により、最大32万3,000件のメールアドレスなどが流出した可能性 |
| 電子書籍サービス | システムログファイル | 会員データベースの319件に加え、ログファイルに残っていた情報が最大約420万件流出 |
| 証券会社 | 委託先 FAQ システム | 問い合わせ管理用の外部サービスが侵害され、約11万人分の情報が流出した可能性 |
| クラウド事業者 | クラウドインフラ | ランサムウェア攻撃により、自治体や企業など顧客495社で障害が発生 |
[表3] 日本の主な情報流出事例と侵害箇所
日本の侵害事例の多くも、中核システムではなく周辺システムが起点でした。特に百貨店グループの事例は、予約サイト一つがグループ共通 ID を利用していたために被害につながりました。電子書籍サービスの事例は、会員データベースを保護していても、同じ情報がログに残っていれば流出する可能性があることを示しています。
ARTEX は日本でも確認されました。日本のセキュリティ企業 GMO サイバーセキュリティ by イエラエは10月19日、同国企業を攻撃したインフラで ARTEX の使用痕跡を確認したと発表しました。同社が標的として確認した企業のうち8社は、9月と10月に情報流出を公表しました。企業名は公開されておらず、韓国での攻撃と同じ攻撃者によるものだという根拠もありません。現時点で確認できるのは、同じツールが両国で使われたということまでです。
Agentic AI 攻撃：実験から実戦へ
注目すべきなのは、AI エージェントが偵察、脆弱性の探索、侵入、Web シェルの設置までを自律的に続けて実行する攻撃が、実際の侵害事例として確認され始めたことです。
ASEC は、最近話題となった ARTEX を別のテスト環境で再現し、自律的な侵入がどこまで可能かを検証しました。セキュリティの知識がない利用者でも入力できる「攻撃対象に侵入して」といった短い指示だけで、ARTEX は人の途中介入なしに Web サーバーのファイルアップロード機能を見つけ、Web シェルを使ってプログラムを実行しました。Apache ActiveMQ が公開された環境では、既知の脆弱性（CVE-2023-46604）を使って最初の侵入に成功し、その後、内部ホスト4台でリモートコマンドを実行する段階まで到達しました。
こうした事例で際立つ変化は、「攻撃の経済性」です。脆弱性の探索、攻撃経路のテスト、ペイロードの修正、失敗後の再試行など、熟練者が必要だった反復作業を、数時間にわたって休まず作業するエージェントに任せられるようになっています。オープンウェイト AI モデルと無料で公開されているエージェントフレームワークを簡単に組み合わせられるようになり、かつては高度な技術が必要だったサイバー攻撃を誰もが実行できる水準になりました。こうした攻撃作戦にかかるコストも急速に低下しています。
AI を使った攻撃の予防には、外部との接点を見直すことが必要です
AI を活用した攻撃を防ぐには、組織がインターネットに何を公開しているかを正確に把握することから始めます。攻撃者は AI エージェントを使って外部からの攻撃対象となる領域を網羅的に調査しています。そのため、防御側も同じ視点で資産を洗い出す必要があります。特に、メインサービスに付随するサービス、イベントページ、管理ツール、アプリが呼び出す API など、管理の優先順位が低くなりがちな資産を優先して点検します。
| 領域 | 点検項目 |
|---|---|
| 外部公開資産の管理 | インターネットに公開された Web サイト、API、管理ページ、リモートアクセス接点をすべて一覧化し、担当者を指定します。使用していないサービスやテストサーバーは外部からのアクセスを遮断します。 |
| アプリのバックエンド API | アプリはいつでも分析されるものと考えます。すべての API リクエストでサーバー側の認証とオブジェクト単位の認可を検証し、アプリ内に API キーや認証情報を埋め込みません。ユーザーごとの照会件数を制限し、異常な連続照会を検知します。 |
| 管理・業務ツール | 管理ページ、BI ツール、営業支援システムに外部から直接アクセスできないようにします。やむを得ず公開する場合は、接続元 IP の制限と多要素認証を適用します。また、こうしたツールが業務データベースを読み取る権限を最小限にします。 |
| 委託先 SaaS とサプライチェーン | 委託先が保有するデータと接続権限を一覧化します。委託アプリに付与したクラウド権限（OAuth の同意など）を定期的に見直し、委託先からの侵害通知手順を契約に明記します。 |
| アカウントと認証 | VPN、リモートアクセス、業務用クラウドアカウントにフィッシング耐性の高い多要素認証を適用します。外部で入手されたアカウント情報を使う攻撃に備え、ログイン失敗の急増や不審な場所からの接続を検知します。 |
| パッチとサポート終了 | インターネットに公開されたコンポーネント（PHP、GitLab、Node.js、DNS サーバーなど）は、脆弱性の公表当日の対応を目標とする専用手順を設けます。サポートが終了したシステムは置き換え計画を立て、それまで外部への公開を最小限にします。 |
| データの最小化 | 保存期間を過ぎた会員情報や退職者情報、開発用の一時ファイル、個人情報が残るログを整理します。保存されていないデータが流出することはありません。 |
| 検知と監視 | 外部との接点のログを中核システムと同じ水準で収集し、24時間の監視対象に含めます。Web サーバーによるシェルやダウンロードツールの実行など、侵害後の活動を検知するルールを運用します。 |
[表4] 外部との接点を中心とした予防点検項目
AI エージェントを使った攻撃は速度が速い点も考慮する必要があります。実際に、最初の標的化から権限取得まで3時間もかからなかった事例があります。手作業で点検し、数日以内にパッチを適用する従来のサイクルでは対応が遅れる可能性があります。Web ファイアウォールルールの先行適用や、公開資産の即時遮断など、自動化された対応手段をあらかじめ準備してください。また、防御側も AI を使った脆弱性点検により、攻撃者より先に外部との接点にある弱点を見つける必要があります。
攻撃事例の詳細な分析や予防・対応策は、ASEC ブログに掲載されたレポート全文でご確認いただけます。
参考資料：最新の脅威に関するアンラボの分析コンテンツ
PHP の脆弱性
- PHP で重大な脆弱性2件を発見…Web サーバー攻撃の危険、緊急アップデートが必要
- PHP 脆弱性の公開後、GitHub に攻撃コードが拡散…アンラボがリポジトリ100件を分析
- PHP2Shell 攻撃を再現…アンラボの EDR/XDR で検知する方法
ARTEX
- AI が攻撃の参入障壁を下げる：アンラボが追跡した ARTEX インフラ
- ARTEX の進化：アンラボが追跡した AI ベースのペネトレーションテストインフラ
- ARTEX インフラの追跡：実際の攻撃活動の痕跡を確認
- AI ベースの自律型侵入テストツール ARTEX の構造と動作分析レポート [AhnLab TIP 会員限定]
