国内では、不正アクセスや情報漏洩の公表が相次いでいます。原因は事案によって異なりますが、システムの脆弱性やアクセス権限の不備など、以前から知られている問題が攻撃の糸口になるケースも見られます。
一方、攻撃する側では、対象となるシステムを探し、弱点を調べ、攻撃を試みるまでの作業を自動化する動きが見られます。AIの活用によって、こうした動きがさらに加速する可能性もあります。
NRIセキュアの監視環境でも、複数の組織のAPIを狙う攻撃を観測しています。また、別の攻撃元インフラを調査したところ、AIを使って攻撃を自動化していた可能性を示す情報も見つかりました。こうした状況で企業に求められるのは、基本的なセキュリティ対策を着実に実行するとともに、問題を見つけてから対処するまでの時間を短くすることです。
本記事では、NRIセキュアが観測・分析した情報をもとに、最近の攻撃の特徴と、経営層が担当部門とともに確認したい4つの対策を解説します。
- ＜この記事の要点＞
- ■NRIセキュアの監視環境では、2026年10月2日〜8日の1週間に、複数組織のAPIを狙う攻撃関連イベントを約3万件検知しました。その8割以上は、SQLインジェクション（データベースへの不正な命令）に関連するものでした。
- ■NRIセキュアが別途調査した攻撃元インフラでは、攻撃の工程をAIエージェントに分担させていた可能性を示すファイル名が見つかりました。ただし、実際にAIが使われたことや、攻撃が成功したことは確認されていません。
- ■手口の多くは、以前から知られているものです。攻撃を自動化する動きが見られる中、企業には、弱点を見つけてから対処するまでの時間を短くすることが求められます。
国内で相次ぐ不正アクセスの公表
まずは、国内の状況を確認します。
NRIセキュアの独自集計によると、2026年9月28日の週に確認された国内のインシデント報告は、8月から9月の週次中央値と比較すると、4倍以上に増加しました。
公表情報などから把握できる攻撃の手口やリスク要因もさまざまです。古いミドルウェアやCMS（Content Management System）の脆弱性、管理画面の公開や設定の不備、アプリケーションの脆弱性、認証情報の悪用などが挙げられます。
ミドルウェアはアプリケーションの動作を支えるソフトウェア、CMSはWebサイトのコンテンツを管理する仕組みです。いずれも多くの企業のシステムで利用されています。個々の事案の原因を一括りにすることはできませんが、企業規模や業種を問わず被害が公表されている現状は、自社の備えを見直す一つのきっかけになるでしょう。
APIを狙う攻撃関連イベントを1週間で約3万件検知
次に、当社が実際に観測した攻撃を見ていきます。2026年10月2日から8日までの1週間、NRIセキュアの監視環境では、同一の送信元IPアドレスから複数の組織に向けられた APIを対象にした攻撃関連イベントを約3万件検知しました。なお、約3万件は検知イベント数であり、個別の攻撃リクエスト数や、攻撃の成功件数、情報漏洩の件数ではありません。
APIは、異なるシステムやアプリケーションがデータや機能をやり取りするための仕組みです。例えば、スマートフォンのアプリで商品を検索したり、会員情報や取引内容を確認したりする際にも使われています。今回の観測では、一覧表示、検索、認証、取引、通知など、さまざまな機能のAPIが対象になっていました。
検知した攻撃関連イベントの80%以上は、データベースに不正な命令を実行させようとする「SQLインジェクション」に関連するものでした。そのほか、サーバに意図しない通信を行わせる「SSRF（Server-Side Request Forgery）」や、本来アクセスできないファイルを参照しようとする「パストラバーサル」なども観測しています。また、一部のケースでは、単に脆弱性を探すだけでなく、次のような操作も確認されました。
- 攻撃に使うアカウントを作成する
- 作成したアカウントでログインする
- ログイン後に利用できるAPIを探索する
- 大量の操作によってサービスに負荷をかける
ここで注意したいのは、正規の手順でログインした利用者であっても、不正な操作を行う可能性があるという点です。
例えば、誰でもアカウントを作成できるサービスでは、攻撃者も一般の利用者と同じようにログインできます。そのため、ログイン時の本人確認だけでなく、ログイン後に「誰が、どのデータに、どのような操作を行えるのか」を適切に制御する必要があります。
攻撃の自動化とAI活用の可能性
今回観測した攻撃では、ある組織への攻撃が終わると次の組織に移るという形で、短時間のうちに複数の組織を順番に攻撃していく動きが見られました。また、各組織に対する攻撃では、事前の偵察的なアクセスがほとんど見られず、対象となるAPIの構造を把握した状態で攻撃が開始されていたように見受けられるものもありました。
ただ、こうした動きは従来の攻撃ツールでも実現できるため、これだけでAIが使われていたと判断することはできません。
NRIセキュアが別途調査した、9月22日から29日に攻撃元として観測された別の送信元に関する情報からは、AIの活用をうかがわせる痕跡が見つかっています。この攻撃元インフラについて、インターネット上に残されていた過去の公開状態を調べたところ、次のようなファイル名が確認されました。
- 00_OBJECTIVE.md
- 01_FUNNEL.md
- 02_STATE.md
- 03_LEDGER.md
- 04_SURFACE.md
- 05_EXCLUDED.md
- 06_SEED.md
- 07_HANDOFF.md
- 08_SUBAGENT.md
- 09_SCREEN.md
- 10_STATE_MACHINE.md
- 11_CRAWL_V4.md
- 12_CVE_INTEL.md
- 13_BACKDOOR.md
- 14_FRAG.md
これらは、作業の引き継ぎや役割分担、処理の進行管理、既知の脆弱性情報との照合などを想起させる名前です。特に「SUBAGENT」という名称からは、AIエージェントに作業を分担させる仕組みが想定されます。
また、侵入後のアクセス手段の維持や、検出を回避する処理を連想させるファイル名も確認されています。
一連のファイル名を見る限り、攻撃対象を選び、情報を収集し、脆弱性を探して攻撃を試みるまでの工程を、複数の処理に分けて管理しようとしていた可能性があります。ただし、これらはファイル名から推定したものであり、実際にAIが使用されたことや、攻撃が成功したことまでは確認できていません。
このほか、10月2日から8日にかけて観測された攻撃者の作業用とみられるサーバ3台について、インターネット上で公開状態になっていた情報も分析しました。主な特徴は次のとおりです。
- AIエージェントに試行錯誤させる：うち1台には、AIエージェントを動かす基盤が導入されていました。あわせて、エージェントに役割や行動規則を与える定義ファイルと、数十世代にわたって書き直されたスクリプトも見つかりました。Webサービスのアカウント作成や画像認証の突破を、AIに試行錯誤させながら自動化しようとしていたとみられます。
- 1日で標的の公開資産を洗い出す：海外の金融関連事業者を狙ったサーバでは、攻撃者が1日のうちに約60のサブドメインを洗い出していました。そのうえで、既知の脆弱性の確認やログインを試みていました。
- 同じ仕組みのサイトを横断的に調べる：同じCMSを使う約40のサイトについて、管理画面の情報を集めていました。一部のサイトでは、管理者アカウントへの総当たりや、開発用リポジトリの探索も行っていました。
サーバ3台とも、残された記録を見る限り、攻撃の多くはWAFや地域制限、ボット対策によって遮断されていました。標的組織への侵入に成功した記録は確認されていません。ただし、登録手続きの途中まで進んだ例や、公開状態のリポジトリから情報の一部を取得した例はありました。
なお、サーバ3台はいずれも国内の組織を狙ったものではありません。また、9月下旬の攻撃元も含め、先ほど紹介した10月2日から8日までの攻撃との関連は確認できていません。
重要なのは、AIによってまったく新しい攻撃手法が生まれたということではありません。従来から知られている攻撃手法であっても、対象の探索から攻撃の実行までを効率化・自動化できるようになれば、企業側にも、弱点を見つけて対処するまでの時間を短くすることが求められます。
※当社の調査で得られた攻撃基盤に関する情報はJPCERT/CCにも連携しております。
攻撃の自動化が進む中で、企業の備えはどう変わるべきか
今回の観測で、多く見られたSQLインジェクションなどは、以前から知られている攻撃手法です。しかし、攻撃者が多くのシステムを短時間で調べられるようになれば、管理が行き届いていないシステムや、修正が後回しになっている脆弱性が攻撃者に発見され、悪用を試みられる機会が増える可能性があります。
そのため、既知の脆弱性への対応、アクセス権限の適切な管理、不要なシステムの公開停止といった基本対策が、これまで以上に重要になります。
とはいえ、必要な対策が分かっていても、すぐに実行できるとは限りません。システムを止められない、委託先との調整に時間がかかる、対応できる人員が限られているなど、企業ごとにさまざまな事情があるためです。こうした制約の中で実効性のある対策を進めるには、技術的な対策だけでなく、何を優先し、どこに人員や予算を配分するのかを、経営層と担当部門が一緒に判断していく必要があります。
企業が優先して進めたい4つの対応
では、具体的にどこから着手すればよいのでしょうか。経営層が担当部門と確認したいポイントを、4つに整理します。
1．インターネットに公開しているシステムとAPIを把握する
最初に確認したいのは、自社がインターネットに公開しているシステムやAPIを、どこまで把握できているかということです。
企業のWebサイトや顧客向けサービスだけでなく、データ分析に使うBIツール、管理画面、従業員向けのシステム、委託先が運用する環境なども対象に含めます。特に、スマートフォンアプリなどから利用されるAPIには注意が必要です。利用者から直接見えない機能であっても、アプリの解析によってAPIの接続先や仕様が把握される可能性があります。
システムの一覧を作る際には、次の情報も確認しておきましょう。
- 何の業務に使っているのか
- 誰が管理しているのか
- どのようなデータを扱っているのか
- インターネットへの公開が本当に必要なのか
すでに一覧がある場合も、いつ更新されたものなのか、委託先の環境やAPIまで含まれているのかを確認することが大切です。
2．脆弱性やアクセス制御の問題に優先順位を付ける
守るべき対象が把握できたら、次は問題の確認と対応です。
ソフトウェアの更新状況、不要な公開設定、使われていないアカウント、アクセス権限などを点検します。
APIについては、特に「認証」と「認可」を分けて考える必要があります。
認証は、アクセスしている人が誰なのかを確認することです。一方、認可は、その人にどのような操作を許可するかを判断することです。例えば、利用者Aが正しくログインできたとしても、利用者Bの契約情報まで参照できてよいわけではありません。
そのため、ログインできるかどうかだけでなく、対象となるデータや操作ごとに、適切な権限確認が行われているかを確かめる必要があります。あわせて、短時間に大量の操作を受け付けないための制限や、認証情報が漏洩した場合に、速やかに無効化できる仕組みなども確認します。
すべての問題を一度に解決することが難しい場合は、外部からのアクセスのしやすさ、実際に悪用されているかどうか、扱うデータの重要性、事業への影響などを踏まえて優先順位を付けます。そのうえで、対応責任者と期限を明確にします。すぐに修正できない問題については、公開範囲や利用機能を一時的に制限することも検討します。
こうした対応は業務への影響や追加の費用を伴うこともあるため、担当部門だけに任せず、経営層が必要な判断を支えることが重要です。
3．不審なアクセスと、調査できていない範囲を確認する
対策の点検と並行して、すでに不審なアクセスが発生していないかも確認する必要があります。
当社のSOC（セキュリティ監視・分析組織）でも、JPCERT/CCが注意喚起で示した不審な送信元IPアドレスの一部について、関連するアクセスを検知しています。
ただし、特定のIPアドレスからのアクセスがあっただけで、システムが侵害されたと判断できるわけではありません。通信の日時や対象となった機能、ログインの状況、その前後の操作などを合わせて調べる必要があります。
経営層が担当部門から報告を受ける際には、「異常はありませんでした」という結論だけでなく、次の点も確認してみてください。
- どのシステムの、いつからいつまでのログを確認したのか
- どのような観点で調査したのか
- ログが残っていない、あるいは調査できていない範囲はどこか
調査できた範囲とできていない範囲を明らかにすることで、追加調査や監視の強化が必要かどうかを判断しやすくなります。
4．異常が見つかったときの判断と対応を速くする
不審な動きが見つかった場合には、被害の拡大を防ぐため、システムの隔離やアカウントの無効化、一部の機能やサービスの停止が必要になることがあります。
しかし、こうした対応は業務や顧客への影響も大きく、現場だけでは判断が難しい場合があります。
必要なときに速やかに動けるよう、平時から次の点を決めておくことが重要です。
- どのような状況で、隔離や停止を検討するのか
- 誰が判断し、誰が実行するのか
- 判断者が不在の場合は、誰が代わるのか
- 事業部門、法務、広報などと、どのように連携するのか
あわせて、ネットワークの分割やアクセス権限の最小化、端末・ネットワークの監視など、侵入された場合の影響を抑える対策も確認しておきます。
不審な動きを検知できても、対応の判断に時間がかかれば、その間に被害が拡大する可能性があります。
異常を見つけられることと、組織として速やかに動けること。その両方が必要です。
今後を見据え、備えておきたいこと
今回の観測では、認証前の機能を狙う攻撃が中心でしたが、アカウントを作成してログインし、認証後のAPIを探索する動きも確認されています。
今後、こうした攻撃がさらに広範囲に、効率的に行われる可能性も考慮する必要があります。
また、脆弱性の公表後、数時間単位で悪用が試みられる、いわゆる「N-hour」型の攻撃への備えも重要です。AIによって脆弱性情報の収集や攻撃準備が効率化されれば、攻撃者が悪用を試みるまでの時間がさらに短くなる可能性があります。
もちろん、これらは今回の観測だけで将来の攻撃動向を断定するものではありません。しかし、攻撃側の効率化が進む可能性を考えると、防御する側も対応の速さを見直していく必要があります。例えば、脆弱性情報の収集、自社システムへの影響調査、対応の優先順位付け、ログの分析といった作業には、自動化やAIを活用できる余地があります。一方、業務への影響が大きいサービス停止などについては、人が確認し、判断する手順と権限を明確にしておくことが大切です。
NRIセキュアは、技術的な対策と経営判断を結び付け、組織全体で迅速に対応できる体制を整えていくことが、これからのサイバーセキュリティにおいて、ますます重要になると考えています。
※当社独自の攻撃観測・分析は、2026年10月13日時点で整理した情報に基づきます。当社の監視・情報収集範囲で確認されたものであり、国内全体の攻撃動向を網羅するものではありません。
