Webシステムへの不正アクセスが急増。攻撃者の手口6つと、受託・保守の立場で今すぐ点検すべきこと
2026年、個人情報を扱うWebシステムへの不正アクセスが、国内で続発しています。国内のWebシステム侵害の公表件数は、2024年が62件、2025年が84件だったのに対し、2026年は10月6日時点で119件。約7割が7月以降に集中しています（マクニカ セキュリティ研究センターの集計）。同じ時期に、海外13か国・地域でも99件の類似事例が確認されており、日本だけの現象ではありません。
お客様のシステムを受託・保守する立場として、この状況を放っておくわけにはいきません。攻撃者が実際に何をしているのかを公表資料から手口ごとに整理し、自分たちの点検項目に落とした内容を、社内の朝会で共有しました。その内容をまとめます。
突かれているのは、基礎的な不備
まず押さえておきたいのは、使われている弱点が目新しくないことです。突かれているのは、設定・権限・パッチの基礎的な不備です。高度なゼロデイは要りません。
変わったのは、攻撃の規模と速度です。攻撃は「偵察で入口を総当たりする」「見つけた不備を突く」の2段階で、AIがこれを大規模化しました。証明書の透明性ログで新しいサブドメインを把握し、インターネット上の機器を検索できるサービスで公開サーバーや管理画面を列挙し、公開アプリを解析して内部APIを抽出する。こうして「個人情報を扱っていて、入口に不備がありそうな公開システム」のリストを、人手を介さず機械的に作ります。
調査では、オープンソースの侵入テストツールを使い、44のAIエージェントに偵察・脆弱性の発見と検証・情報窃取・報告書作成までを分担させ、短期間に19組織（うち16組織以上が国内）を検証対象にした事例が確認されています。狙いは特定の企業に限りません。条件に合うものを片っ端から調べます。「うちは小さいから探されない」は、もう成り立ちません。
攻撃者の手口6つ
JPCERT/CCの注意喚起と各社の調査報告から、手口を6つに整理しました。どれも、自分たちの開発でも起こりうるものです。
| 手口 | 攻撃者がしていること | なぜ危険か |
|---|---|---|
| ① アプリを解析して内部APIを見つける | 公開中のAndroidアプリを逆コンパイルし、画面からは到達しない内部APIのアドレス、埋め込まれたAPIキー、内部ドメインを抜き出す | 難読化していても取り出される。「アプリでしか使っていないAPIは外から見えない」という思い込みが突かれる |
| ② リクエスト内のIDを書き換える | ログイン後、自分のデータを取るリクエストの id=1001 を 1002、1003 と機械的に変えて送る |
サーバーが「このトークンの持ち主が、このIDのデータを見てよいか」を検証していなければ、他人の情報がそのまま返る。ブラウザの開発者ツールだけで実行でき、国内事案で最も多く観測されている |
| ③ 画面に出ない項目まで返すAPIを読む | 画面には氏名とランクしか出ていなくても、APIが返すJSONに電話番号・住所・内部フラグまで入っているのを傍受する | フロントで非表示にしても、送っていれば読まれる。画面の見た目は安全そうなので、開発側も気づきにくい |
| ④ 認可の抜けた機能に匿名で直接アクセスする | 正面のログイン画面は弾いても、その先の管理用API（会員一括エクスポート、権限変更など）に認証チェックがない。①で見つけたパスへ、ログインせずに直接リクエストを送る | 画面の制御とAPI層の権限制御は別物。「社内向けだから」「公開していないから」という理由で認可を省いた機能が、インターネットから直接叩かれる |
| ⑤ 既知の穴をまとめてスキャンする | パッチ未適用の脆弱性、SSRF、SQL/NoSQLインジェクションを標的ごとに片っ端から試す | どれか一つでも通れば侵入が成立する。パッチ公開から悪用までの時間は、AIで数時間に縮んでいる |
| ⑥ 侵入後にWebシェルを仕込む | 公開Webサーバーから到達できるアプリケーションサーバーにWebシェルを設置し、正規の通信に紛れて任意のコマンドを実行する | 一度設置されると、脆弱性を塞いでも再侵入され続ける |
表にして気づくのは、①〜④が「認可とレスポンスの設計」の話だということです。どれも、APIを設計するときに決めることです。つまり、受託開発の現場で防げる領域です。
受託・保守の立場で、着手している点検は6つ
手口を裏返すと、点検項目になります。自分たちは次の6つを、担当を分けて進めています。
| やること | 具体的な確認内容 | 担当 | |
|---|---|---|---|
| 1 | 認可チェックの確認 | データ取得APIで、IDを差し替えたり他ユーザーとしてアクセスしたりしたときに、レスポンスが変わらないか（手口②④） | 開発 |
| 2 | レスポンスの点検 | APIが画面に出さない項目まで返していないか。秘密鍵やAPIキーがアプリ・フロントに埋め込まれていないか（手口①③） | 開発 |
| 3 | レート制限の設定 | ログイン、パスワードリセット、検索、SMS送信など悪用リスクの高い機能に、単位時間あたりの回数制限があるか | 開発 |
| 4 | パッチと管理画面 | 製品・SaaSの未適用パッチ、管理画面のMFA・IP制限、SSRF対策の有無（手口⑤） | インフラ |
| 5 | Webシェル痕跡の確認 | 公開サーバーと、そこから到達できるアプリサーバーに、身に覚えのないJSP/WARファイルや不審なプロセスがないか（手口⑥） | インフラ |
| 6 | ログの遡及確認 | 直近1か月で、同一IPからのAPI大量アクセス、403/404の急増、異常なデータ取得量がないか。curl や python-requests のUAを含む公開観測IPとも照合 |
運用 |
設計で決めている原則は、次の3つです。
- 秘密情報は、アプリやフロントのコードに一切埋め込まない。 内部APIも、必ず外部から到達される前提で、サーバー側の認証・認可を設計する
- すべてのデータ取得・更新APIで、リクエスト者とリソース所有者の一致をサーバー側で検証する。 IDを推測しにくくするのは補助であって、認可チェックの代わりにはならない
- レスポンスに含める項目は、サーバー側でホワイトリスト方式に絞る。 「全カラム返して画面で隠す」作りをやめ、APIごとに必要な項目だけ返す
まとめ
突かれているのは基礎的な不備です。裏返せば、基礎の点検を徹底すれば大半は防げます。攻撃が自動化・大規模化しても、入口は変わっていません。守る側も「自社の公開資産を把握し、手口①〜⑥の観点で点検する」という基礎の徹底が、いちばん効きます。
ヱビスは、情報セキュリティ基本方針に基づき、お預かりしているシステムの点検を続けています。開発中・保守中のシステムについて、認可やレスポンスの設計に不安がある場合は、お気軽にご相談ください。
参考：JPCERT/CC「Webシステムへの不正アクセスに関する注意喚起」（2026年10月8日、更新10月9日）、マクニカ セキュリティ研究センター（2026年10月7日）、TrendAI（2026年10月23日）、Verizon「2026 Data Breach Investigations Report」、総務省 注意喚起（2026年10月）