相次ぐ不正アクセス、攻撃はどこから始まる？ 脆弱性スキャンとWAF・IP Reputationで考える入口対策

不正アクセスは、いきなりサーバーへ侵入して始まるのでしょうか。最近の国内事例を見ると、その前段で脆弱性やAPI、管理画面など「使えそうな入口」を探す探索が行われています。WAFやIP Reputationは、侵入後ではなく、この入口を探している段階でどこまで役に立つのか。実際の事例を見ながら考えてみます。

2026年9月にはタイムズカーで大規模な情報漏えいが発生し、10月にはIDCフロンティアの「IDCFクラウド」でも第三者からの不正アクセスによる障害が発生しました。JPCERT/CCとIPAも相次いで注意喚起を出しており、一般向けWebサイトだけでなく、BIツールや従業員向けシステム、クラウドサービス、VPNなども確認対象になっています。

いきなり侵入されるわけではない

もちろん、すべての攻撃が脆弱性スキャンから始まるわけではありません。フィッシングでIDやパスワードを盗み、その認証情報でログインするケースもあれば、VPN装置や外部公開アプリケーションの脆弱性を直接悪用するケースもあります。

ただ、インターネットへ公開しているシステムでは、攻撃できそうな入口を探す探索が日常的に行われています。JPCERT/CCが公表した国内組織への攻撃事例でも、一つの製品だけを狙うのではなく、複数のソフトウェアについて既知の脆弱性を探し、環境設定ファイルやバックアップファイル、管理用APIなども調べていた可能性が示されています。

攻撃者が最初から「この会社にはこの脆弱性がある」と知っているとは限りません。広く探して、使えそうな入口を見つけてから攻撃へ進むケースがあります。Webサーバーのログで存在しないパスや管理画面を探すアクセスを見かけることがありますが、こうした動きも攻撃前の探索として見る必要があります。

最近の事例から見る不正アクセスの入口

最近公表された事例を見ると、探索対象はWebサイトの画面だけではありません。古い技術基盤、外部公開API、BIツール、管理機能など、インターネットから到達できるものは攻撃者にとって確認対象になります。「一般ユーザーが使わないから目立たないだろう」という考え方も、外部からHTTPリクエストを直接送られる環境では通用しません。

タイムズカーでは約660万件が漏えい

タイムズモビリティは2026年9月25日に不正アクセスを検知し、その後の調査で約660万件のアカウント情報が漏えいしたことを公表しました。さらに約160万件の本人確認書類も漏えいしており、運転免許証画像や現住所確認書類、学生証などが含まれています。

現時点でタイムズ側は侵入経路や原因を公表していないため、「この脆弱性が原因だった」と断定することはできません。外部から確認できるWebページにはSeasar2 / Teeda系のコードが残っており、Seasar2は2016年にサポートを終了していますが、それが今回の侵入原因だったという証拠はありません。この2つは分けて考える必要があります。

長期間運用しているWebシステムでは、「動いているから変更しない」という判断が積み重なり、古いライブラリやフレームワークが残ることがあります。厄介なのは、脆弱性が見つかったときに自社がそのライブラリを使っていること自体を把握できていないケースです。

攻撃者はAPIも直接調べる

JPCERT/CCが公開した事例では、一般公開されているスマートフォンアプリなどを解析し、APIのエンドポイントやキーを調べる動きも確認されています。本来画面から実行できない内部APIへアクセスしたり、認証ヘッダーの有無を変えてレスポンスの違いを見たり、NoSQLインジェクションでアカウントを探索するといった操作です。

「画面にリンクがないから安全」「一般ユーザーには見えないAPIだから大丈夫」と思いたくなりますよね？ しかしHTTPリクエストを直接送れば画面を経由する必要はありません。同じエンドポイントへパラメータを変えながら何度もアクセスするような動きがあれば、画面とは別に通信そのものを見ておく必要があります。

SQLインジェクションや既知脆弱性も今なお使われる

JPCERT/CCは、MetabaseのSQLインジェクション脆弱性 CVE-2026-72898 を利用した攻撃についても取り上げています。BIツールのように一般利用者向けではないシステムでも、インターネットからアクセスできれば攻撃対象になります。公開された攻撃元では python-requests のような自動化スクリプトでよく使われるUser-Agentも確認されています。

新しい脆弱性が公開されると、その製品を探す探索がすぐに始まることがあります。過去にはCitrix製品の脆弱性でPoCが公開された直後から探索活動が観測された例もあり、「週末に時間があるときアップデートしよう」では間に合わない場合があります。

最優先なのは脆弱性そのものを修正することです。WAFがあるからアップデートしなくてよい、とはなりません。ただ、パッチ適用までの間や、まだ把握していない攻撃に対して、Webサイトより前で防御できる場所があるかどうかは運用上かなり大きな違いになります。

WAFとIP Reputationはどこで効くのか

探索から実際の攻撃へ進む通信をすべて同じ方法で見る必要はありません。送信されてきたHTTPリクエストの中身を見るのがWAFなら、既知の攻撃元や繰り返される不審な動きをアクセス元単位で見るのがIP Reputationです。それぞれ得意な場所が違うため、どちらか一方で全部を止めようとするより役割を分けた方が分かりやすくなります。

WAFは「何を送ってきたか」を見る

WAF（Web Application Firewall）は、Webサイトへ送信されるHTTPリクエストを検査し、Webアプリケーションに対する攻撃を検知・遮断します。SQLインジェクション、XSS、LFI、RFI、RCE、CMSを狙った攻撃など、リクエストの内容から判断できる攻撃が対象です。

今回の事例に出てきたSQLインジェクションやAPIへの不正なリクエストもHTTPレイヤーで発生します。送信元IPに悪い評価が付いていなくても、実際に送ってきた内容が攻撃であればWAF側で検査できます。

IP Reputationは「誰が、どう動いているか」を見る

レッドボックスでは最近、IP Reputation機能を提供開始しました。既知の不正IPデータベースだけでなく、レッドボックス側で不正と判断したIPアドレスも防御対象として利用します。

さらに、不正IPを一律にブロックするだけではなく、Webサイトごとに不正な振る舞いを定義し、その条件に該当したIPアドレスを個別に遮断できます。存在しないURLへ短時間に大量のリクエストを送るIPを一定時間ブロックし、その後も同じ挙動が続けば遮断時間を長くする、といった使い方です。

WAFが「何を送ってきたか」を見るのに対し、IP Reputationでは「誰がアクセスしているか」「そのアクセス元がどのような振る舞いをしているか」を判断材料にできます。探索の段階で同じIPから不審なリクエストが繰り返されているなら、毎回オリジンサーバーまで通す必要はありません。

IP ReputationだけでもWAFだけでも足りない

IP Reputationにも限界があります。攻撃者が新しく用意したクラウドサーバーなど、まだ悪い評価が付いていないIPから最初の攻撃が来れば、既知の不正IP情報だけでは止められません。その通信についてはWAFがリクエスト内容を見る必要があります。

逆に、すでに不正だと分かっている送信元から大量のスキャンが来ているのに、すべてをWAFの検査まで通すのも効率的ではありません。既知の攻撃元やサイト上で不審な振る舞いを始めたIPは早めに止め、未知の送信元はWAFで中身を見る。2つを組み合わせる理由はここにあります。

レッドボックスでは通信の入口で防御する

レッドボックスではCDNとWAFを組み合わせ、Webサーバーへ通信が到達する前のエッジ側で攻撃を検知・遮断します。ここにIP Reputationと振る舞いベースのIP制御を加えることで、既知の不正IP、サイト固有の不審なアクセス、実際の攻撃リクエストを別々のレイヤーで処理できます。

実運用では、存在しないパスへの大量アクセス、管理画面の探索、短時間に繰り返されるスキャンなどを検知したとき、そのIPを一定時間遮断し、同じ挙動が続けば防御時間を変更するといった制御ができます。WAF側では、IPだけでは判断できないSQLインジェクションやRCEなどの攻撃内容を引き続き確認します。

この構成にも弱いところはあります。正しいIDとパスワードを使ったアクセスや、Webを通らない侵害までCDNやWAFだけで判断することはできません。入口で減らせる攻撃を減らすための仕組みであって、すべてのセキュリティ対策を置き換えるものではありません。

WAFを入れれば情報漏えいしない、ではない

WAFを提供している側が言うのも少し変ですが、WAFやIP Reputationを導入したからといって、すべての不正アクセスを防げるわけではありません。正規のIDとパスワードがフィッシングで盗まれた場合、内部ネットワークから侵害された場合、設定ミスが原因の場合などは、WAFだけでは判断できないことがあります。

脆弱性管理、パッチ適用、多要素認証、アクセス制御、ログ監視といった基本的な対策は引き続き必要です。WAFやIP Reputationはそれらの代わりではなく、インターネットからWebアプリケーションへ入ってくる攻撃を、できるだけ手前で減らすためのレイヤーです。

攻撃されてからではなく、探索されている段階から見る

公開したWebサーバーが誰にも見つからず静かに動き続ける、という前提で運用するのは難しくなっています。既知の脆弱性を探す、APIを解析する、認証方式を変えて反応を見る、設定ファイルやバックアップを探す、といった動きは、攻撃が成功するより前の段階で行われます。

侵入されたかどうかだけを見るのではなく、その前にどのような探索や不審な通信が来ているかも見る。既知の攻撃元はIP Reputationで早めに遮断し、未知の通信はWAFで内容を確認し、本体側では脆弱性対応や認証強化を続ける。最近の国内事例を見ると、攻撃が成立してから対処するだけではなく、入口を探されている段階から防御を始める意味は以前より大きくなっていると考えています。