旅行の予定を押さえた直後に、Booking.comのチャットで「事前決済が完了していません。24時間以内にカード情報を再入力してください」と届いたら——あなたはそのURLをクリックしますか？
帝国ホテルやホテルニューオータニ大阪に続き、2026年6月1〜2日にかけて全国の地方温泉旅館・ビジネスホテルチェーンでも管理画面の侵害が多発していることが確認されました。今回の手口、情シス担当者として「やっぱりここが穴か……」と思わず唸ってしまった部分がありまして。少し掘り下げてみます。
- Booking.com管理画面の侵害——確認されているフィッシング攻撃の全容
- なぜ「正規チャネル悪用型」は防ぎにくいのか
- 自分もBooking.comヘビーユーザーなので確認してみました
- 情シス担当者として見えてくる構造的問題
- 個人・法人それぞれの対策設計
- 実装チェックリスト（今すぐ確認できる）
- よくある質問
- まとめ——「気をつける」ではなく「仕組みで防ぐ」
Booking.com管理画面の侵害——確認されているフィッシング攻撃の全容
まず事実を整理しておきます。
Booking.comはホテル・旅館側に「B2B管理ポータル（エクストラネット）」を提供しており、施設スタッフはここから予約管理・料金設定・ゲストへのメッセージ送信などを行っています。今回の攻撃者はこのB2B管理ポータルへの不正アクセスを成功させ、以下の流れで攻撃を展開していることが複数の施設の告知から確認されています。
- 施設スタッフのアカウント（B2Bポータルの認証情報）を何らかの手段で奪取
- 乗っ取ったポータルから「直近に宿泊予定がある顧客」をピンポイントで抽出
- Booking.com正規のチャット機能を経由して「事前決済が完了していません。24時間以内に以下のリンクからカード情報を再入力してください」というメッセージを自動配信
- リンク先の偽ページでカード番号・有効期限・セキュリティコードをだまし取る
複数施設がすでに公式HPで緊急告知を出しており、「不審なチャットのURLは踏まないでください」という対応を余儀なくされています。被害は大手ホテルチェーンにとどまらず、地方の温泉旅館にも急拡散中というのが現状です。
なぜ「正規チャネル悪用型」は防ぎにくいのか
ここが今回の件で一番厄介なところです。
通常のフィッシングメールは「送信元アドレスが怪しい」「URLが偽ドメイン」「添付ファイルがある」といった特徴で見分けることができます。ところが今回の攻撃はBooking.comの正規チャット機能から届いています。
つまり——
- 送信元: Booking.com公式（本物）
- URLのドメイン: booking.com（本物、少なくとも初期の誘導は）
- メッセージの到達経路: 正規の通知システム（本物）
- 文面: 実際の予約情報を含む自然な文面
偽装しなくても「本物のインフラを踏み台にする」——これは典型的なサプライチェーン型攻撃のBtoBサービス版です。URLフィルタリングもメールセキュリティゲートウェイも、正規ドメインからの通知には有効に機能しません。
| 比較項目 | 従来のフィッシング | 今回の正規チャネル悪用型 |
|---|---|---|
| 送信元アドレス | 偽装・類似ドメイン | Booking.com正規 |
| URLドメイン | 偽ドメイン | booking.comドメイン |
| 文面の自然さ | 不自然なことが多い | 予約情報を含む自然な文面 |
| URLフィルタリングへの耐性 | 検出・ブロック可 | すり抜ける |
| 受信者の気づきやすさ | 比較的気づきやすい | 気づきにくい |
攻撃者の視点から見ると、施設スタッフのID/パスワード1組を入手するだけで、大量の予約客に正規チャネル経由でフィッシングを展開できる——コスパが非常に高い攻撃です。情シス担当者の胃に優しくない仕様、と言わざるを得ません。
自分もBooking.comヘビーユーザーなので確認してみました
今回のニュースを受けて、私もさっそく Have I Been Pwned（HaveIBeenPwned: メールアドレスが過去のデータ漏洩に含まれていないかを無料で確認できるサービス）でチェックしました。
現時点で直接の漏洩は確認されませんでしたが——ひとつ重要な注意点があります。今回の攻撃の起点は「ゲストのBooking.comアカウント漏洩」ではなく「ホテル側のB2B管理ポータルへの侵害」です。つまり Have I Been Pwned で「クリーン」が出ていても、今回のフィッシングの標的になる可能性はあります。
認証情報の管理という観点から、私自身が実践していることを共有すると：
- パスワード管理: 1Passwordですべてのサービスのパスワードを一元管理。固有かつ強力なパスワードを自動生成。
- MFA（多要素認証）: TOTPによるワンタイムパスワードを全主要サービスに設定。OTPも1Password内で生成・管理。
- パスキー（FIDO2）: iPhoneのパスキー・Windows Helloを利用可能なサービスには積極的に設定済み。
- ハードウェアキー: YubiKeyをバックアップのハードウェアトークンとして活用。
「セキュリティにかけすぎでは？」と言われることもあります。でも、今回のように「正規チャネル経由で届くフィッシング」が増えている現状では、多層防御は最低限の備えだと考えています。特にパスキーはフィッシングサイトへの認証情報入力を仕組みとして防ぐことができる点で、MFAの中でも一段上の耐フィッシング性を持ちます。
【関連記事】パスキー導入の実践的な判断基準を金融サービスで比較しています。
情シス担当者として見えてくる構造的問題
今回の件、「フィッシングメールに気をつけましょう」で終わらせると本質を見失います。
最小権限の設計が機能していなかった可能性
攻撃者がB2B管理ポータルに侵入できた経路として、現時点で考えられるのは：
- クレデンシャルスタッフィング: 過去のデータ漏洩で入手した認証情報の使い回し
- フィッシング: 施設スタッフへの標的型攻撃で認証情報を奪取
- インフォスティーラー型マルウェア: セッション情報・認証情報の自動窃取
どの経路であれ、問題の本質は「スタッフのID1つが奪われると、ゲストへの大量メッセージ配信という強力な機能まで使えてしまう」という権限設計の粗さにあります。予約管理だけをするスタッフに、一括メッセージ配信の権限が必要かどうか——最小権限の観点から再検討する余地があったはずです。
「失敗を前提とした設計」が欠けていた
施設スタッフのIDが奪われることを100%防ぐことはできません。人間の「ついうっかり」は必ず起きます（パスワードを付箋でモニターに貼る文化と戦ってきた私が言うのですから間違いない）。
だからこそ、侵害された後の被害を局限する仕組みが必要なのです。理想的には：
- 異常なメッセージ送信パターン（通常とかけ離れた大量送信・不審URL）の自動検知・ブロック
- 送信URLの動的スキャンによるフィッシングリンクのフィルタリング
- 管理ポータルの操作ログ監視と異常アクセスの即時アラート
「失敗する可能性のあるものはいつか必ず失敗する」——この前提で設計されていれば、今回のような大規模拡散は防げた可能性があります。侵害を止められなかったこと自体より、侵害後の被害が広がり続けたことが問題の核心です。
個人・法人それぞれの対策設計
ユーザー（個人）としての対策
予防層——フィッシングに引っかからないための設計
- パスキー（FIDO2）を設定する: 対応サービスでは積極的に設定。フィッシングサイトへの認証情報入力をアーキテクチャとして防ぐ。
- MFAを必ず設定する: SMSよりもTOTPアプリ（Google Authenticator・Authy等）またはYubiKey等のハードウェアキーを推奨。
- パスワードマネージャーで管理する: 1Password・Bitwarden等で固有・強力なパスワードを生成・管理する。
- Have I Been Pwnedで定期チェック: https://haveibeenpwned.com/ でメールアドレスの漏洩履歴を定期的に確認する。
被害局限層——引っかかった後のダメージ最小化
- Booking.comチャット内のURLは公式アプリで確認する: URLをクリックする前に、公式アプリを直接開いて同じ内容が届いているか確認する。
- カード情報の再入力前に電話確認する: 宿泊予約の決済情報の再入力を求められたら、施設に直接電話確認してから判断する。
- クレジットカードのリアルタイム通知を設定する: 不正利用に即座に気づけるよう通知を有効にしておく。
施設・法人担当者としての対策
B2B管理ポータルのアカウント管理（今週中に確認）
- 全スタッフのアカウントにMFAを設定する（設定していない場合は最優先で実施）
- 退職者・異動者のアカウントを速やかに無効化する（「退職者アカウント放置あるある」ですが、今回のような被害の入口になりかねません）
- ログイン履歴を確認し、不審なアクセス（海外IP・深夜帯等）がないかチェックする
- 万一フィッシングを配信してしまった場合の顧客通知プロセスを整備しておく
【関連記事】連休明け・インシデント後の情シス対応手順を整理しています。
実装チェックリスト（今すぐ確認できる）
個人向け（5分） - [ ] Booking.comアカウントにMFAを設定しているか - [ ] パスキーが使えるデバイスでパスキーを登録しているか - [ ] パスワードは固有で強力か（他サービスと使い回していないか） - [ ] Have I Been Pwned（https://haveibeenpwned.com/）でメールアドレスをチェックしたか
施設・法人担当者向け（今週中） - [ ] B2B管理ポータルの全スタッフアカウントにMFAを設定しているか - [ ] 退職者・異動者のアカウントは無効化されているか - [ ] ログイン履歴に不審なアクセスがないか確認したか - [ ] 顧客への緊急通知プロセスが整備されているか
よくある質問
Q: Booking.comのチャットで「カード情報の再入力」を求められたらどうすればいいですか？
A: まずURLはクリックせず、公式アプリを直接開いてください。同じメッセージが届いている場合でも、宿泊施設に直接電話で確認することを強くお勧めします。Booking.comは公式に「決済情報の再入力をチャット内URLで求めることはない」と案内しています。
Q: Have I Been Pwnedで「漏洩なし」が出れば今回の攻撃は関係ありませんか？
A: 今回の攻撃はゲストのアカウント漏洩ではなく、ホテル側のB2B管理ポータルへの侵害が起点です。Have I Been Pwnedで「クリーン」が出ていても、フィッシングメッセージの標的になる可能性はあります。URLクリックとカード情報入力には慎重に。
Q: パスキーを設定すれば今回のようなフィッシングは防げますか？
A: パスキー（FIDO2）は「フィッシングサイトへの認証情報の入力」をアーキテクチャとして防ぎます。ただし今回の攻撃はBooking.comアカウントへの不正ログインではなく、カード情報の直接詐取が目的です。パスキーはBooking.comへの不正ログインを防ぐ効果はありますが、「怪しいURLのリンク先にカード情報を入力しない」という判断と組み合わせることが重要です。
Q: ホテル・旅館側として最初にすべきことは何ですか？
A: まず全スタッフのB2B管理ポータルのパスワードを直ちに変更し、MFAを設定することが最優先です。次にログイン履歴を確認して侵害の痕跡がないかチェックし、疑いがある場合はBooking.comサポートへ即時報告・顧客への通知を行ってください。「スタッフが気をつければ大丈夫」という属人的な管理から、仕組みで守る設計に移行するタイミングです。
まとめ——「気をつける」ではなく「仕組みで防ぐ」
今回のBooking.comをめぐる一連の事案は、「正規チャネルを悪用すればほとんどのセキュリティツールをすり抜けられる」という事実を改めて示しました。
個人としてできる最善は、パスキーとMFAの多層設定・パスワードマネージャーの活用を全主要サービスで実施すること。今すぐできます。
施設・法人としてできる最善は、B2B管理ポータルへのMFA必須化と定期的なアカウント棚卸——「スタッフの注意力に頼る」属人的管理をやめて、仕組みで守る設計に移行することです。
「失敗する可能性のあるものは、いつか必ず失敗する」——この前提に立てば、今やるべきことは明確なはずです。
