―― 状況証拠から侵害経路を推定してみた
2026年9月26日未明、京王グループがランサムウェアによるサイバー攻撃を受けたことを公表しました。
被害拡大を防ぐためネットワークが遮断され、その影響はホテル事業、小売事業、グループ共通ポイント、交通関連サービス、レジャー事業など、複数のサービスに広く及びました。一方、鉄道の運行システムには影響がないとされています。
一見するとバラバラに見えるこれらのサービスには、一つの共通点があります。
いずれも、京王グループの共通ポイント／決済の仕組みと関係していることです。
ここが、今回の調査の出発点になりました。
この記事では、公開情報と公的な登録情報だけを使い、外部から確認できる範囲で今回の事案を追った結果に基づいています。
また、被害者側については個別の施設や企業を特定する名称を用いず、「京王グループ」と表記します。一方、攻撃手法を検討するために参照する欧米の事例については、一次情報を明確にするため、企業名、製品名、攻撃グループ名を実名で記載します。
1．なぜ、これほど広い範囲に影響したのか
最初に気になったのは、影響した事業の広さです。
ホテル、小売、ポイント、交通、レジャー。
業種だけを見れば、それぞれ独立したシステムが動いていても不思議ではありません。
ところが、公表された影響範囲を見ていくと、それらは京王グループの共通ポイント／決済の仕組みでつながっているように見えました。
そこで、「それぞれの事業が個別に攻撃されたのではなく、複数の事業が利用する共通の土台に何らかの影響が生じたのではないか」と考え、その「共通の土台」はどこにあるのか？を、対象システムへ接続することなく、公開情報だけでどこまで確認できるのかを調べてみることにしました。
2．外から確認できたこと
今回利用したのは、相手のサーバーへ探りを入れるような方法ではありません。
証明書の公開台帳、パッシブDNS、公的なIPアドレス登録情報など、第三者が公開している記録をたどる方法です。
いわば「表札と住所録を見る」ような調査です。
そして、こうした「受動的な調査」から、一つの重要な事実が見えてきました。
京王グループの共通ポイント／決済に関係する公開基盤が、Oracle Cloud（オラクル・クラウド）のインフラ上に存在していたのです。
ここが、今回の推定の一丁目一番地になります。
3．推定の原点――Oracle Cloudはどのように確認したのか
ここは今回の考察と推定全体の土台になるため、少し詳しく説明します。
まず重要なのは、調査の順序です。
Oracleを狙ったサイバー攻撃の情報を先に見つけて、「京王グループもOracleではないか」と考えたわけではありません。
京王グループで複数の事業に影響が出た。
それらをつなぐ共通部分は何なのか。
そこから調べ始めた結果として、Oracle Cloudが現れただけです。
証明書の公開記録を確認する
最初に確認したのが、TLS証明書の公開台帳です。
Certificate Transparency（サーティフィケート・トランスペアレンシー）の検索サービスである「crt.sh」を利用し、共通ポイント／決済に関係するドメインについて公開されている証明書記録を調べました。
すると、そこから複数のホスト名が確認できました。
この段階では、対象となるサーバーには接続していません。公開されている証明書台帳を参照しただけです。
複数のホスト名が同じIPアドレスへ集約されていた
次に、確認したホスト名についてパッシブDNSの記録を調べました。
すると、確認した複数のホスト名が、すべて同じIPアドレスへ解決されていました。
IPアドレスは悪用防止のため、158.101.xxx.xxxと一部を伏せます。
少なくとも外部から観測できる範囲では、複数の名前が同じIPアドレスへ集約されていました。
そこで、そのIPアドレスを誰が管理しているのかを調べることにしました。
IPアドレスの「登記簿」を調べる
利用したのがRDAPです。
RDAPは、IPアドレスがどの組織へ割り当てられているのかを確認できる公的な登録情報です。
いわば、IPアドレスの「登記簿」です。
確認したところ…
所有組織：Oracle
ネットワーク名：ORACLEROUTING
管理：Oracle Bare Metal Operations
…という登録情報が得られました。
Oracle Bare Metalは、Oracle Cloud Infrastructure（OCI）のベアメタル基盤です。
つまり、観測したIPアドレスはOracle Cloudのインフラに属していました。
さらに、この結果は一回の照会だけに依存していません。
北米のインターネットレジストリであるARINへ直接照会した結果では、OracleおよびOracle Bare Metal Operations。
その後に行ったRDAPの自動処理でも、同じIPについてOracle Public Cloud。
二つの経路で同じ結論になりました。
したがって、今回の考察と推定では、京王グループの共通ポイント／決済に関係する公開基盤がOracle Cloudというインフラ上に存在するという確認を出発点にしています。
4．ただし、Oracle Cloudの上で実際に何が動いているのかは分からない
ここには、非常に重要な境界があります。
確認できたのはOracle Cloudというインフラまでです。
京王グループでは、Oracleの何のソフトウェアが動いているのかを確認できていません。
Oracle E-Business Suite（EBS）なのか。
Oracle PeopleSoftなのか。
別のOracle製品なのか。
それとも独自に構築されたアプリケーションなのか。
IPアドレスの登録情報から、そこまでは分かりません。
RDAPで分かるのが「土地の登記簿」だとすれば、今回確認できたのは、その土地の持ち主までです。
その土地にどんな建物が建ち、その中に何が置かれているのかまでは見えません。
したがって、Oracle Cloudを利用していることと、Oracle EBSやPeopleSoftを利用していることは別の話です。
ここから先は、この境界を保ったまま、欧米で実際に発生したOracle業務基盤への攻撃と比較していきました。
5．Cl0p――Oracle EBSへの一点突破から大量のデータ窃取へ
まず注目したのが、Cl0p（クロップ）の名前で知られる恐喝活動です。
2025年、Oracle E-Business Suite（EBS）を利用する組織を狙った大規模な攻撃が発生しました。
Google Threat Intelligence Group（GTIG）とMandiantによると、攻撃者はOracle EBSの脆弱性CVE-2025-61882を、修正プログラムが利用可能になる前から悪用していたとみられています。
さらに重要なのは、その目的です。
攻撃者は単にシステムを停止させたのではありません。
侵害したOracle EBS環境から機密データを持ち出し、その後、被害組織の経営幹部へ大量の恐喝メールを送り始めました。Mandiantは、実際に大量のデータが窃取された事例を確認しています。
Oracle EBSは、財務、人事、顧客情報など、企業活動の中核となる情報を扱う業務基盤です。
攻撃者から見れば、一台一台の端末を順番に攻略しなくても、重要な情報が集約されている業務基盤そのものへ侵入できれば、その先にある大量の情報資産へ到達できる可能性があります。
GTIG／Mandiantも、この種の公開業務アプリケーションを狙う攻撃について、ゼロデイ脆弱性を利用してネットワーク内部での大規模な横展開を抑えながら、多数の組織からデータを窃取できる点を指摘しています。
ここで見えてくるのは、「共通の業務基盤を一点突破し、そこに集約された情報資産を狙う」という攻撃の姿です。
ただし、京王グループがOracle EBSを利用していることは確認できていません。
Cl0pの事例は、今回の侵入経路を示す証拠ではなく、Oracleの業務基盤が実際にどのような攻撃を受け、大量の情報窃取へつながったのかを見るための実例です。
6．ShinyHunters――Oracle PeopleSoftを狙った攻撃
もう一つ、より最近の事例があります。
ShinyHunters（シャイニーハンターズ）です。
Google Threat Intelligence Group／Mandiantは、UNC6240として追跡するShinyHuntersによるOracle PeopleSoftへの攻撃を2026年6月に公表しました。
悪用されたのは、Environment Management（環境管理）コンポーネントに存在するCVE-2026-35273。
CVSS 9.8の深刻なリモートコード実行の脆弱性です。
攻撃は2026年5月27日から6月9日にかけて確認され、Oracleが6月10日にセキュリティ情報を公開する前から悪用されていました。つまり、当初はゼロデイとして使われていました。
そして、この攻撃にはもう一つ重要な特徴があります。
ShinyHuntersは、その後も攻撃方法を変化させていたのです。
7．ShinyHuntersが持つ二つの侵害方法
最初に確認されたのは、PeopleSoftの脆弱性そのものを直接突く方法です。
外部から到達可能なPeopleSoft環境に対し、CVE-2026-35273を悪用して侵入する。
これが第一の方法でした。
これに対し、Oracleは緊急のセキュリティ情報を公開し、Mandiantも修正や外部アクセスの遮断を呼びかけました。
ところが、2026年9月25日。
Google Threat Intelligence Group／Mandiantは、ShinyHuntersによる大規模攻撃の再開を報告しました。
今度は、単純に同じ方法を繰り返していたのではありません。
防御側が導入したWAF（Web Application Firewall／ウェブ・アプリケーション・ファイアウォール）による遮断を回避するよう、攻撃方法が変更されていました。
WAFは、ウェブアプリケーションへ届く通信を監視し、攻撃と判断した通信を入口で遮断する防御壁です。
ところがShinyHuntersは、WAFが通信をどう判定するのかと、その先にあるPeopleSoftが同じ通信をどう解釈するのかという違いを利用しました。
その結果、防御側では「WAFで遮断した」と考えていた経路を通り抜け、脆弱なPeopleSoft側へ通信を到達させることが可能にしていました。
Google／Mandiantは、この新たな攻撃によって世界各地の数十のシステムにウェブシェルが設置されたと報告しています。標的分野も高等教育だけではなく、テクノロジー、ITサービス、医療、農業、運輸、政府へ広がりました。
つまりShinyHuntersについては…
① PeopleSoftの脆弱性を直接悪用する
そして、
② 防御側がWAFで塞いだ後、そのWAFの判定を回避して再び脆弱な部分へ到達する
という二つの侵害方法が実際に確認されています。
これはかなり深刻です。
脆弱性が公表された後、「WAFで入口を塞いだから大丈夫」と考えていた組織に対しても、攻撃者側が防御策を研究し、別の方法で侵入を試みているからです。
8．京王グループで観測したWAFとの符合
今回の受動的調査では、京王グループについて観測した別の公開Web資産が、Imperva（インパーヴァ）のWAF／CDNの背後に存在することも確認しています。
ここで、ShinyHuntersの攻撃との一つの符合が生まれます。
ShinyHuntersがPeopleSoftに対して使用している第二の方法は、まさにWAFによる遮断を回避するものだからです。
ただし、京王グループで確認したImpervaが、Oracle Cloud上で観測した共通ポイント／決済基盤を直接保護していたことまでは確認できていません。
したがって、「京王グループのImpervaがShinyHuntersによって突破された」という話ではありません。
ここで重要なのは、WAFが存在すること自体を、外部からの侵入可能性を否定する材料にはできないという点です。
実際にShinyHuntersは、WAFによる防御を前提として、その防御を回避する方法へ攻撃を変化させています。
9．状況証拠を並べてみる
ここまで確認してきたものを整理してみました。
- 京王グループでは、性格の異なる複数の事業に影響が発生しました。
- それらは共通ポイント／決済という仕組みでつながっています。
- その公開基盤を受動的に調べると、複数のホスト名が同一IPへ集約され、そのIPがOracle Cloudのインフラに属していることを確認できました。
- 一方、欧米ではOracleの業務基盤を狙った二つの大規模攻撃が現実に発生しています。
- Cl0pブランドに関連する攻撃では、Oracle EBSの脆弱性を利用して組織へ侵入し、大量の情報資産を窃取したうえで恐喝する攻撃が確認されました。
- ShinyHuntersはOracle PeopleSoftを狙い、ゼロデイとして脆弱性を直接悪用しました。そして修正・防御策が公開された後には、WAFによる遮断を回避するよう攻撃方法を変更し、再び大規模な攻撃を始めています。
- そして、標的となった分野には運輸も含まれています。
ここまで並べると、今回確認したOracle Cloudという事実を無視することはできません。
10．では、京王グループで何が起きた可能性があるのか
ここからが今回の推定です。
京王グループで観測したOracle Cloud上に、もしEBSやPeopleSoft、あるいはそれらと同じように複数事業の重要な情報を扱う共通業務システムが存在していたとします。
そして、その共通業務システムに何らかの方法で侵入されたと仮定します。
その場合…
共通基盤への侵入
↓
大量の情報資産への到達
↓
接続された業務システムへの影響拡大
↓
複数事業への波及
…という筋書きが成り立ちます。
Cl0pによるOracle EBSへの攻撃も、ShinyHuntersによるPeopleSoftへの攻撃も、「重要な情報が集約された業務基盤を狙う」という点では共通しています。
今回の京王グループ事案でも、複数の事業が同時に影響を受け、その共通部分を外から追うとOracle Cloudへ行き着きました。
だからこそ、この可能性を検討してみました。
しかし、ここには決定的に欠けているものがあります。
Oracle Cloud上で実際に動いていた具体的な業務ソフトが分からない。
京王グループがEBSを利用していたことも、PeopleSoftを利用していたことも確認できていません。
したがって、Cl0pやShinyHuntersによる攻撃だったとも、CVE-2025-61882やCVE-2026-35273が使われたとも判断できません。
今回確認できたのは、「Oracle Cloudという共通の土台が存在する」ところまでです。
その土台の上に何が載っていたのか。
そして、そこが実際に侵入経路だったのか。
最後の一本の線は、まだつながっていません。
11．広範な障害そのものについても考えておきたい
もう一つ考えておかなければならないことがあります。
今回影響が出たすべてのシステムが、攻撃者によって直接侵害されたとは限りません。
京王グループはランサムウェアを確認した後、被害拡大を防ぐためネットワークを遮断しています。
したがって、外から見えている広範な障害には、攻撃によって直接発生した障害だけでなく、被害拡大を防ぐため京王グループ自身がネットワークを切り離したことによって生じた停止が含まれている可能性があります。
外部からの受動的な観測だけでは、この二つを切り分けることはできません。
12．なぜ、断定できないのか――受動的調査の限界
今回の調査ではっきりしていることは、外から見える情報でたどれるのは、「どんな土台の上に、何が置かれているように見えるのか」という構造までです。
そこから実際に侵入されたのかという事実には、原理的に届きません。
侵入経路、認証記録、攻撃者の内部での動き、アクセスされたデータ、ランサムウェアが実行された場所と時刻。
それらの証拠が残るのはシステム内部のログです。
それを見ることができるのは京王グループと、調査を依頼された専門機関だけです。
よって、受動的調査の限界として「構造上、一点を突かれれば広域に波及しうる形が見えている」というところまでです。
それが実際に起きたのかどうかは断定できません。
そして、これは現在進行中の事案です。
外部の人間が稼働中のシステムへ探りを入れるような能動的行為は、たとえ善意でも復旧や調査の妨げになりかねません。
今回行ったのは、公開台帳、公的レジストリ、パッシブな観測情報を読むところまでです。
対象システムへの能動的な接続や脆弱性検証は行っていません。
この線引きは、技術的にできるかどうか以前の、調査する側の節度の問題だと考えています。
13．おわりに――犯人捜しより、構造を理解すること
サイバー攻撃の話は、つい「どこの誰がミスをしたのか」という犯人捜しになりがちです。
しかし、長く続く企業のシステムが、時代とともに機能を継ぎ足しながら複雑になり、共通の土台へ集約されていくことは、どこの組織でも起こり得ます。
それ自体は過失ではないと考えます。
むしろ今回の一件から考えたいのは、「便利さのために共通化した土台は、同時に『共通の弱点』にもなりうる」という、現代のシステムが抱える構造的なジレンマです。
Cl0pのOracle EBS攻撃では、共通業務基盤への侵入から大量のデータ窃取へつながりました。
ShinyHuntersのPeopleSoft攻撃では、脆弱性を直接突くだけでなく、防御側がWAFで入口を塞ぐと、そのWAFを回避する方法へ攻撃を変化させました。
攻撃者側も、企業システムの「共通の土台」がどこにあるのかを見ています。
今回の京王グループ事案について、外から確認できた事実を積み上げていくと、その先にOracle Cloudという共通基盤が見えてきました。
しかし、その上で何の業務ソフトが動いていたのか、そこが実際に侵入経路となったのかまでは分かりません。
大切なのは特定の企業の粗探しではなく、こうした構造を理解し、自分たちが利用しているシステムの“共通の土台」”がどこにあり、そこが侵害された場合に何が起きるのかを考えることではないかと考えます。
今回の京王グループ事案は、その重要性を改めて考えさせる事例だと思いました。
コメント