skyticketを運営する株式会社アドベンチャーが公表した3件の不正アクセスを、発生した順に並べ直す。8月のバス予約情報、9月の返金口座情報、10月の約1,464万件。最初は共通の鍵が盗まれたと考えたが、取得された情報の違いを見ると、それぞれの業務機能が持つ権限を不正に利用された可能性が浮かぶ。公表された事実と推測を分けながら、一つの攻撃シナリオを考える。
2026年10月9日、比較予約サイト「skyticket」を運営する株式会社アドベンチャーが、不正アクセスによる個人情報の流出を公表した。
会社は、異なる経路による3件の不正アクセスがあったと説明している。
8月にはバスの予約情報。
9月には返金先の銀行口座情報。
10月には約1,464万件もの個人情報。
発生した時期も、侵入されたシステムも、取得された情報も違う。
一見すると、別々の事件に見える。
しかし、日付順に並べ、取得された情報を比較すると、気になる繋がりが見えてくる。
私は最初、どこかで共通の鍵が盗まれたのではないかと考えた。
ところが、公表文を読み直し、実際にスマホアプリやWebサイトを確認するうちに、別の可能性が浮かんできた。
攻撃者は鍵を盗まなくても、それぞれの業務システムが持つ機能を利用して、情報を取得できたのではないか。
そして、一つの侵害が発覚した後、まだ使える機能から大量の情報を取りに来たのではないか。
本稿では、公表された事実と、外部から確認できる情報をもとに、一つの攻撃シナリオを推測する。
もちろん、3件が別々の攻撃者による無関係な事件だった可能性もある。社内のログを持たない以上、答えは出せない。
筆者自身、skyticketの会員であり、今回の流出対象に含まれているという連絡も受け取っている。
その立場からも、事実と推測を分けながら考えてみたい。
アドベンチャーは、今回の不正アクセスを「それぞれ異なる経路による次の3件」と説明している。
会社は10月の大規模流出から順番に記載しているが、ここでは発生した順に①②③と番号を振り直した。
| 番号 | 発生期間 | 発覚日 | 対象となった情報 |
|---|---|---|---|
| ① バス予約 | 8/3〜10/1 | 10/1 | 予約約12,000件 |
| ② 業務管理システム | 9/20 | 9/28 | 返金口座情報など17,780件 |
| ③ 管理機能から他のサーバー・クラウドへ | 10/2〜10/4 | 10/5 | 約1,464万件 |
③の約1,464万件には、会員のログインパスワードを含むものが約413万件ある。ただし、パスワードは平文ではなく、ハッシュ化された状態だった。
また、①の約12,000件は予約件数であり、同行者を含めた人数はそれより多い。
ここで注目したいのは、三つの事件で取得された情報が違うことだ。
予約情報、返金口座情報、そして大量の顧客情報。
なぜ、これほど異なる情報が取得されたのだろうか。
三つの不正アクセスを見て、私が最初に疑ったのは認証情報の流出だった。
別々の入口から侵入されたように見えても、内側では同じ鍵を使っているのではないか。
例えば、複数のクラウドや業務システムを繋ぐ自動化基盤だ。
今回の外形調査では、こうした自動化基盤が外部から応答を返していることも確認できた。
n8nのような自動化基盤には、APIキーやトークン、データベースの接続情報など、複数のシステムにアクセスするための認証情報を保持する機能がある。
もしそこから鍵が盗まれたなら、一つの侵害から複数のシステムにアクセスできる可能性がある。
最初は、その筋を疑った。
ただし、外部から応答を確認できることと、侵害されていることは別だ。
今回、自動化基盤から鍵が盗まれたという証拠はない。
そして、公表文を読み直しているうちに、別のことが気になり始めた。
取得された情報が、それぞれの業務ごとに分かれている。
バス予約では予約情報。
返金業務では銀行口座情報。
最後の管理機能では大量の個人情報。
もちろん、共通の鍵を盗んだ場合でも、アクセスできる権限や攻撃目的によって取得する情報は変わる。
しかし、もっと単純な説明ができるのではないか。
攻撃者は鍵を盗んで複数のシステムに入ったのではなく、それぞれの業務機能が持つ権限を不正に利用していたのではないか。
そう考えて、もう一度、発生した順に見直してみた。
最も早く始まったのが、バス予約情報の不正閲覧だ。
8月3日から10月1日まで、約2か月間続いていた。
会社によると、バスの予約完了ページがログインなしでも表示できる状態になっており、第三者が機械的に閲覧していた。
この説明から疑われるのが、オブジェクト単位の認可不備、いわゆるBOLAやIDORと呼ばれる問題だ。
例えば、予約番号などの識別子を指定したとき、その予約を見る権限があるか十分に確認せず、情報を返してしまうような問題である。
もし予約番号が連番だったなら、番号を変えることで別の予約情報を取得できた可能性もある。
ただし、実際に連番が使われたのか、どのような方法で機械的に閲覧されたのかまでは公表されていない。
ここで重要なのは、閲覧された情報の中身だ。
氏名、電話番号、メールアドレスだけではない。
会員ID、支払方法、金額、予約日時、乗車便の情報、同行者の氏名なども含まれていた。
つまり、予約の内容だけでなく、予約と会員、支払いを結びつける情報も含まれていた。
攻撃者は、単に予約情報を集めただけではなく、別の業務機能を調べるための手掛かりも得ていたのではないか。
そう考えると、次の出来事が気になる。
公表文には、もう一つ興味深い記述がある。
9月9日に、会員1名のアカウントへの不正ログインが確認されている。
私は最初、盗まれたパスワードが使えるか試したのではないかと考えた。
もちろん、それは十分にあり得る。
盗んだパスワードを使って通常のログイン処理に成功した場合でも、本人の許可がなければ不正ログインになる。
しかし、今回の三つの事件を並べてみると、別の可能性も考えたくなる。
skyticketは、誰でも会員登録できる。
会員向けの機能を調べたいだけなら、自分でアカウントを作ればよい。
二つのアカウントを作れば、会員ごとの表示内容やアクセス権限の違いも確認できる。
それなのに、他人の会員アカウントへの不正ログインが確認されている。
なぜだろうか。
ここからは推測だ。
もしかすると、攻撃者は単にパスワードを試していたのではなく、取得済みの会員IDなどを手掛かりに、別の会員としてアクセスできるか確認していたのではないか。
8月から閲覧されていたバス予約情報には、会員IDも含まれていた。
もし、その識別子を別の会員向け機能に渡すことで、他人の情報が取得できたり、他人として扱われたりする不備があったならどうだろうか。
9月9日は、そうした認証や認可の境界を試した日だったのかもしれない。
ただし、ここは明確に区別したい。
他人の会員情報をAPIで閲覧できたことと、他人のアカウントへのログインが成立したことは、技術的には別である。
公表文は「不正ログイン」と説明している。単なるAPIからの情報取得を確認したとは書いていない。
したがって、実際にAPIの認可不備が使われたと判断する材料はない。
それでも、もし同じ攻撃者だったなら、9月9日は単なるパスワードの試し打ちではなく、他人の識別子や権限を使えるか確かめる試行だった可能性もある。
どちらにしても、この時点で大量の顧客情報まで取得できていたという証拠はない。
しかし、次の9月20日の出来事を考えると、この一行が気になってくる。
9月20日、skyticketの業務管理システムが不正アクセスを受けた。
対象となったのは、返金先の銀行口座情報など17,780件だった。
金融機関名、支店名、口座種別、口座番号、口座名義。
8月に閲覧されたバス予約情報とは、明らかに種類が違う。
会社は、業務管理システムの脆弱性を悪用されたと説明している。
ただし、どのような脆弱性だったかは明らかにしていない。
ここで、skyticketの返金業務を考えてみる。
航空券や高速バスなどをキャンセルした場合、支払方法によって返金方法が異なる。
クレジットカード決済では、通常は利用したカードに返金される。
一方、コンビニ決済などでは、利用者が返金先の銀行口座を登録し、振込で返金を受ける仕組みがある。
実際、skyticketの公式案内によると、高速バスでもコンビニ決済の場合は、マイページや予約確認ページから返金先口座を登録・変更することになっている。
つまり、バス予約の利用者向け機能と、返金口座を扱う業務には、少なくとも業務上の繋がりがある。
ここが気になる。
8月のバス予約情報には、会員IDや予約に関する情報が含まれていた。
もし、それらの識別子を手掛かりに返金関連の業務機能を調べていたとしたら。
そして、その業務機能にアクセス権限の確認が不十分な箇所があったとしたら。
攻撃者は、返金口座情報を扱う機能を不正に利用できたのではないか。
もちろん、バス予約番号から返金口座情報が直接取得できたという証拠はない。
そもそも②の業務管理システムがバス予約専用だったとも説明されていない。
ここで考えているのは、予約情報を手掛かりに返金業務の仕組みを調べ、別の弱点を見つけた可能性である。
そして、もう一つ気になるのが9月20日という日付だ。
2026年は、9月19日から23日まで5連休のシルバーウィークだった。
9月20日は、その2日目の日曜日にあたる。
もし攻撃者が事前に脆弱性を把握していたなら、あえて大型連休を選んだのではないか。
通常の業務担当者が不在になりやすい時期を狙った可能性もある。
もちろん、skyticketの監視体制が休日に弱かったという証拠はない。
旅行予約サービスであれば、むしろ休日の監視を強化していた可能性もある。
それでも、業務管理システムへの不正アクセスが大型連休の最中に発生したことは事実だ。
そして、この不正アクセスが発覚したのは9月28日だった。
9月28日、業務管理システムへの不正アクセスが発覚した。
10月1日には、バス予約の予約完了ページにあった問題も修正された。
そして、その翌日。
10月2日から4日にかけて、今度は約1,464万件の個人情報が流出した、または流出したおそれがある。
私は、この日付の並びが最も気になっている。
会社が問題を発見し、対策を始めた直後に、最大規模の不正アクセスが発生している。
しかも、10月2日は金曜日。発生期間は週末をまたいでいた。
ここから、一つのシナリオを考えてみたい。
もし3件が同じ攻撃者によるものだったなら。
攻撃者は8月から、複数の業務機能を調べていた。
予約情報を取得し、会員認証や認可の仕組みを試し、9月20日には返金口座情報にアクセスした。
ところが、9月28日にその不正アクセスが発覚する。
10月1日には、バス予約の問題も修正された。
攻撃者が会社側の動きを察知していたなら、自分が使える入口が次々と閉じられ始めたと考えたかもしれない。
このままでは、ほかの入口も塞がれる。
そこで、まだ使える別のAPIや管理機能から、取得できる情報を一気に取りに来たのではないか。
それが、10月2日から4日にかけての大規模な不正アクセスだったという推測だ。
ここでいう「一気に」とは、短時間に大量の通信が発生したという意味ではない。
実際の取得速度は分からない。
使える機能が閉じられる前に、残された機会を利用して大量の情報を取得しようとした、という意味である。
もちろん、攻撃者が会社の対策を察知していた証拠はない。
10月2日に初めてその機能を利用できるようになった可能性もある。
3件が無関係で、日付が偶然重なっただけかもしれない。
しかし、もし一連の行動だったなら、この時系列は説明がつく。
発覚したから攻撃が終わったのではない。発覚したからこそ、まだ使える入口から大量取得に動いたのではないか。
私は、この可能性が気になる。
10月の不正アクセスについて、会社は重要な説明をしている。
一部の管理機能を不正に操作され、そこから他のサーバーやクラウド上のデータにアクセスされたというものだ。
ここで最初に思い浮かべたのは、管理者権限の奪取だった。
しかし、公表文には「管理者のパスワードが盗まれた」とは書かれていない。
もちろん、書かれていないから盗まれていないとも言えない。
ただ、別の可能性を考えてみたい。
業務システムには、本来の仕事をするために、さまざまな情報を検索したり取得したりする機能がある。
予約情報を扱う機能。
返金口座情報を参照する機能。
顧客情報を検索する機能。
これらの機能は、それぞれの仕事に必要なデータへアクセスする権限を持っている。
その機能を呼び出した相手が、本当に操作を許された利用者なのか、十分に確認していなかったらどうなるだろうか。
攻撃者は管理者のパスワードを盗まなくても、業務システム自身が持つ権限を利用できるかもしれない。
例えば、大量の顧客情報を検索したり、別のシステムから情報を取り寄せたりする正規の機能が、本来許されない相手からでも利用できてしまう場合だ。
その場合、攻撃者がデータベースへ直接侵入する必要もない。
システム自身に、情報を取り出させればよい。
しかも、約1,464万件のうち、ログインパスワードを含むものは約413万件だった。
すべてが同じ種類の会員アカウント情報だったとは限らない。
複数のデータ領域にアクセスできる機能が利用されたと考えれば、異なる種類の情報が大量に取得されたことも説明できる。
ただし、実際にどの管理機能が使われたのかは不明だ。
APIの認可不備だったのか、別の脆弱性だったのか、認証情報が悪用されたのかも分からない。
ここで言えるのは、会社が管理機能の不正操作と、他のサーバーやクラウド上のデータへのアクセスを公表していることまでである。
その先は仮説だ。
では、攻撃者は、どの業務システムにどんな情報があると知ったのだろうか。
実は、スマホアプリやWebサイトを見るだけでも、かなりのことが分かる。
私は今回、自分のiPhoneに入れているskyticketアプリを開いてみた。
高速バスの予約確認は、会員ログインなしで利用できる。
画面には、予約番号と電話番号、またはメールアドレスを入力する欄があった。
予約の照会、変更、取消といった機能も用意されている。
これは普通の利用者なら誰でも確認できる情報だ。
しかも、skyticketは誰でも会員登録できる。
私自身も会員だが、特別な権限があるわけではない。
会員になれば、自分の予約履歴や、利用条件に応じたキャンセル・返金の手続きなども確認できる。
公式Webサイトには、支払方法ごとの返金手続きも説明されている。
どのような場合に銀行口座を登録するのか。
キャンセル後、どのような流れで返金するのか。
利用者向けの画面や説明を読むだけでも、予約、会員、返金という業務の関係がある程度見えてくる。
さらに、ここからは一般論になる。
スマホアプリやWebサイトには、裏側のサーバーと通信するための仕組みが組み込まれている。
アプリの通信やWebページのJavaScriptを調べれば、APIの通信先や、どのような情報を扱っているか、手掛かりを得られる場合がある。
スマホアプリやWebサイトは、利用者の操作画面であると同時に、攻撃者にとってシステムの地図にもなる。
ここは誤解のないようにしたい。
私は今回、skyticketアプリの内部コードやAPI通信を解析したわけではない。
攻撃者がアプリを解析したという証拠もない。
実際に確認したのは、通常のアプリ操作で見える画面と、公式サイトに掲載されている業務の説明までだ。
しかし、公表された三つの被害を知った上で、利用者向けの機能を見直すだけでも、かなりのことが推測できる。
予約情報を扱う仕組みがある。
返金口座を扱う仕組みがある。
会員情報を扱う仕組みがある。
それぞれの業務を、どのようなAPIやシステムが支えているのか。
そこに適切な権限の境界があったのか。
地図が外から見えること自体は問題ではない。
Webサイトやスマホアプリの構造は、ある程度調べられて当然だ。
問題は、その地図に載っている機能を知っただけで、本来見られない情報まで取得できてしまうことだ。
ここまでを整理すると、一つの仮説が浮かぶ。
今回の3件は、攻撃者が一つのシステムの奥へ順番に侵入していった結果ではなかったのかもしれない。
最初から、異なる業務機能をそれぞれ調べていた可能性がある。
バス予約の機能からは予約情報。
返金業務の機能からは銀行口座情報。
管理機能からは大量の顧客情報。
それぞれの業務システムが扱うデータが違うからこそ、取得された情報も違っていた。
もし共通する問題があったとすれば、それは必ずしも一つの鍵の流出ではない。
それぞれの機能で、本来許されない相手からの要求を受け付けてしまうという、アクセス制御の問題だったのではないか。
予約番号や会員IDなどの識別子が、別の業務機能を調べる手掛かりになっていた可能性もある。
もちろん、予約番号だけで返金口座を取得できたとか、会員IDを指定すれば大量の個人情報を取得できたという証拠はない。
①では認可不備を疑わせる事実が公表されているが、②と③も同じ原因だったとは確認されていない。
それでも、三つの被害で取得された情報が異なるという事実は、業務機能ごとに異なる弱点が利用されたという仮説と整合する。
そして、この仮説なら、攻撃者が三つの入口を使い分けた理由も説明できる。
それぞれの入口から、違う種類の情報が得られたからだ。
今回、もう一つ気になるのは、発覚までの時間だ。
①のバス予約情報は、8月3日から10月1日まで、約2か月間にわたって不正に閲覧されていた。
②の業務管理システムは、9月20日の不正アクセスが9月28日に発覚した。
③の大規模な不正アクセスは、10月2日から4日に発生し、10月5日に発覚した。
発覚までの時間が、それぞれ違う。
会社は、何をきっかけに不正アクセスを発見したのか、詳しい検知方法を公表していない。
ここでも、一つ推測してみたい。
もし今回の攻撃が、業務システムの正規の機能を不正に利用するものだったとしたら。
サーバーから見ると、攻撃者の要求も、普通の利用者や業務処理による要求と似た形になっていた可能性がある。
システムは止まらない。
データベースも正常に応答する。
画面にもエラーが出ない。
しかし、その裏では、本来見られない情報が読み出されている。
こうした攻撃は、ランサムウェアのようにシステムが停止する事件とは違い、発見が難しい場合がある。
特に①の予約情報は、通常のページ閲覧に近い形で処理されていた可能性がある。
③の約1,464万件についても、数字が大きいからといって、必ずしも短時間に大量の通信が発生したとは限らない。
実際の抽出速度は分からないが、技術的には時間をかけて取得することも可能だ。
重要なのは、通信量だけではない。
そのデータを読んだ相手に、読む権限が本当にあったのか。
そこを監視できていたかどうかだと思う。
会社は、不正アクセス経路の遮断と脆弱性への対策を実施したと説明している。
また、10月7日18時ごろには、保存済みクレジットカードによる支払いと、カード情報の保存機能を停止した。
これは、会員アカウントが不正利用された場合に、保存済みカードを使った不正購入を防ぐための措置だ。
二次被害を減らす判断として評価できる。
ただし、再発防止という点では、まだ知りたいことがある。
一つは、今回悪用された機能と似た仕組みが、ほかにも存在しないかということだ。
バス予約の認可不備を修正したとして、同じ設計の問題が、ほかの予約確認やキャンセル機能に残っていないだろうか。
業務管理システムの脆弱性を修正したとして、返金口座以外の情報を扱う機能にも同じ問題はなかっただろうか。
そして、管理機能が持っている他のサーバーやクラウドへのアクセス権限は、本当に必要な範囲に限定されていたのだろうか。
もう一つ、会員として気になった点もある。
パスワード再設定の案内では、設定できる文字数が「6〜32文字」となっていた。
今回、パスワードはハッシュ化された状態で流出している。
ハッシュ化されていても、攻撃者が持ち帰ったデータから元のパスワードを解析しようとする可能性はある。
解析の難しさは、ハッシュ方式やソルト、パスワードの複雑さなどによって変わるが、短いパスワードは一般に不利だ。
再設定をお願いするのであれば、最低6文字という条件も見直してほしい。
もちろん、これは今回の侵入原因だという話ではない。
今後の被害を減らすための話である。
ただ、会社の調査はまだ続いている。
現時点で公表されていない対策が、すでに実施されている可能性もある。
したがって、対策が不十分だと断定するつもりはない。
また、もう一つ重要な点がある。
一つの不正アクセスを発見したとき、攻撃者が使っている入口は、本当にその一つだけなのだろうか。
今回の仮説のように、攻撃者が複数の業務機能を把握していたとしたら。
一つの入口を塞いだことが、別の入口から大量取得に動くきっかけになる可能性もある。
だからこそ、発見された問題だけを修正するのではなく、関連する業務機能やAPI全体の権限を確認する必要がある。
ここまで考えてきて、最初の疑問に戻る。
私は最初、盗まれた鍵を探していた。
複数のシステムが攻撃されたのだから、その裏には共通する認証情報があったのではないかと考えた。
しかし、公表された被害を並べ直してみると、別の可能性が見えてきた。
攻撃者は鍵を盗まなくても、業務システム自身が持つ権限で情報を取り出せたのではないか。
予約情報。
返金口座。
大量の顧客情報。
三つの業務機能が、それぞれ異なる情報を扱っていた。
そして、それぞれに不正利用できる入口があったとしたら。
攻撃者は、一つの鍵で三つの扉を開けたのではない。
三つの業務機能に、それぞれの扉を開けさせたのかもしれない。
8月から予約情報が閲覧され、9月9日には会員アカウントへの不正ログインが確認された。
9月20日には、大型連休中に返金口座情報を扱う業務管理システムが攻撃された。
9月28日にその侵害が発覚し、10月1日にはバス予約の問題が修正された。
そして、その翌10月2日から、最も大きな情報流出が発生した。
もしこれらが同じ攻撃者によるものだったなら。
攻撃者は最初から複数の業務機能を調べ、利用できる入口を見つけていたのではないか。
9月9日の不正ログインも、単なるパスワードの試し打ちではなく、会員の識別子や権限を使って別の情報に届くかを確かめる動きだったのかもしれない。
そして、会社が対策を始めたところで、まだ使えるAPIや管理機能から、大量の情報を取得しようとしたのではないか。
もちろん、これは公表された事実から組み立てた一つの推測だ。
実際には、盗まれた認証情報やAPIキーが使われた可能性も残る。
しかし、今回の三つの被害を説明するために、必ずしも鍵の流出を前提にする必要はない。
鍵を盗まなくても、鍵を持っている業務システムに、情報を取り出させることはできる。
もし今回それが起きていたのなら、問題は鍵の管理だけではない。
業務機能が、誰の要求に応じて、どの情報を返すのか。
その権限を正しく確認できていたのか。
そこが本当の問題になる。
スマホアプリやWebサイトは、誰でも使える。
会員にも、誰でもなれる。
そして普通の利用者でも、そこから業務システムの構造をある程度推測できる。
攻撃者も、同じことができる。
だから守る側は、APIや業務機能の存在を隠すだけでは守れない。
どの機能が、どの情報にアクセスできるのか。
その機能を、誰が利用してよいのか。
そして、一つの業務機能が不正利用されたとき、ほかのデータにまで届いてしまわないか。
そこまで把握する必要がある。
今回、本当に守るべきだったのは、鍵だけではなかったのではないか。
攻撃者が見ていた地図を、守る側も持っていたのだろうか。
Aikido Community Japan
公開日: 2026/10/9
最終更新: 2026/10/10
セキュリティの最新情報をお届けします。