ホーム / Critical Brief / No. 032

正規の予約プラットフォーム内で、売上金の受領口座が書き換えられた

送金先変更が、資金移動の前に独立検証されなかった(Polaris Holdings / Booking.com)

Pillar 04 · 規制属性証明 属性証明バイパス データ来歴認証・認可
事案日
2026-05-23
公開日
2026-06-08
発行
Lemma Critical Team
関連 Pack
Pack AIncident Response

TL;DR

Polaris Holdings のグループ Booking.com アカウントが侵害され、正規の管理画面内で複数ホテルの売上金受領口座が第三者口座へ書き換えられた。異常検知は他ホテルの送金を阻止したが、検知は異常が現れて初めて発火するため最初の不正送金は完了していた。欠けていたのは、資金移動の前に「この受領口座変更は正規に認可され、送金先も真正か」を確かめる層であり、改ざんは認証済みセッションの操作として素通りした。検出と事前証明は代替でなく補完である。

事案概要

  • 対象: Polaris Holdings(ホテル運営)のグループ Booking.com アカウント配下の複数ホテル
  • 検知: 2026-05-23、グループアカウントの異常を検知し調査を開始
  • 被害: 複数ホテルで売上金受領口座が第三者口座へ不正に書き換え。1 ホテルで売掛金の一部が不正口座へ送金され、現時点で約 900 万円の損失。他ホテルは早期対応で送金阻止
  • 核心: 宿泊客のカード情報を狙う一般的な Booking.com フィッシングではなく、事業者の売上金受領口座(payout 先)を正規 extranet 内で改ざんした B2B の送金経路改ざん
  • 侵入経路: Polaris の開示時点でアクセス経路・ログを Booking.com・当局と調査中。初期侵入の具体手口は未確定(本 Brief では断定しない)
  • 対応: 全ホテルでパスワードをリセット。Booking.com・当局と連携してアクセス経路を追跡。顧客クレジットカードの漏洩は未確認。宿泊客向けのフィッシングメッセージも報告され、個人情報露出の有無を調査中
  • 業界文脈: Booking.com パートナーを狙うキャンペーンは継続的に観測されている(ベンダーリサーチが追跡)。多くは宿泊客へのカードフィッシングだが、本件は受領口座改ざんという資金直撃型の変種

タイムライン

  • 2026-05-23: Polaris Holdings がグループ Booking.com アカウントの異常を検知、調査開始
  • 調査により判明: 複数ホテルで売上金受領口座が第三者口座へ改ざん。1 ホテルで売掛金の一部が不正送金され約 900 万円の損失。他ホテルは送金前に阻止
  • 検知後: 全ホテルでパスワードリセット、Booking.com・当局と連携してアクセス経路・ログを追跡。カード漏洩は未確認、個人情報露出を調査中
  • 2026-05-28 前後: 同社の開示が英語媒体でも報じられる

注: 固有名・CVE は一次（研究機関・GitHub Advisory・NVD 等）に基づき、各実装の対応状況は時点により異なるため最新情報を参照。

攻撃ベクター

(初期侵入の具体手口は調査中・未確定。確認されている事象連鎖を記す)

  1. アカウント不正アクセス: 第三者が Polaris のグループ Booking.com アカウントへ不正アクセス(経路は調査中)
  2. 受領口座の改ざん: 正規の管理画面内で、複数ホテルの売上金受領口座情報を第三者口座へ書き換え
  3. 資金の流出: 変更後の受領口座へ、本来事業者が受け取るべき売掛金の一部が送金され、1 ホテルで約 900 万円が流出
  4. 早期検知による部分阻止: グループアカウントの異常検知を起点に、他ホテルでの送金は阻止
  5. 付随する宿泊客フィッシング: 侵害されたパートナーシステムや外部予約ツール由来の情報を用いたとみられる宿泊客向けフィッシングも報告

構造的論点

本事案は Pillar 04(規制属性証明)の attribute-proof-bypass を背骨とし、Pillar 01(来歴証明)とも交差する境界事案である。secondary に data-provenance(送金先指示の来歴)と identity-auth(アカウント侵害)を併記する。

二つの読みが同時に成立する。P4 の読みでは、売上金受領口座は「正規の事業者が指定した送金先である」という属性であり、その真正性は資金移動の前に検証されるべきだった。攻撃者はこの属性を、認証済みセッションの中で上書きするだけで偽装できた——属性の真正性証明が、変更操作の前提になっていなかった。P1 の読みでは、送金先という”指示”の正当性・来歴(誰が・正規の認可で変更したか)が検証されないまま受理された。両者は「資金移動に直結する高インパクトな変更が、変更時点の認証だけで受理され、変更そのものの正当性が独立検証されなかった」という一点に収束する。

中心の失敗 primitive は、プラットフォームが「認証済みセッションが行った操作」を信頼し、「その操作(送金先変更)が正規に認可され真正な属性に基づくか」を独立検証しなかった点にある。これは Brief 006(Google API キーの失効という属性が独立検証されず削除後も有効だった)と同系で、属性の状態が信頼の前提にされるのに独立検証されない構造である。Brief 002(デプロイヤー鍵による信頼設定の書き換え)とも、「正規の権限の中で trust 設定そのものを書き換えると資金が流出する」点で同根。一般的な Booking.com フィッシング(宿泊客のカードを狙う)とは異なり、本件は事業者の資金経路という設定値を突いており、SaaS プラットフォームの業務データ改ざんが直接の金銭損失に転化する射程を示す。

検出と証明の落差

異常検知・パスワードリセット・当局/プラットフォームとの連携は、被害の把握・拡大阻止・経路追跡に不可欠であり、本 Brief がその役割を否定するものではない。本事案でも検知を起点に他ホテルの送金が阻止され、被害が限定された。

一方で、検出は「送金先変更という操作を、資金移動の前に受理してよいか」自体を変えない。改ざんは正規の認証済みセッションを通じて行われ、extranet 上の操作としては正常に見える。検知は異常が現れて初めて発火するため、最初の不正送金(約 900 万円)はすでに完了していた。欠けていたのは「この受領口座変更は、正規の認可と真正な属性に基づくか」という変更時点の独立検証であり、これはアカウント監視や事後のログ追跡とは別系統である。監査の観点でも、流出後に「いつ・誰の認可で・どの口座へ変更されたか」を立証する独立した証跡は、プラットフォームのアクセスログ突合以上には残りにくい。

事前証明(pre-execution attestation)は、資金移動に直結する受領口座変更を、実行前に「変更者の正規の認可」と「新しい送金先属性の真正性」を独立検証可能な証明として要求する設計を採る。認証済みセッションであっても、proof が「この変更は正規の認可を欠く」「この送金先は真正な属性として確立されていない」と告げれば、変更と後続の送金は事前に block される。アカウント侵害の検出(detection 的な「不審なアクセスか」)と変更の事前証明(「この送金先変更は認可・真正か」)は代替ではなく補完の関係にある。

事後の検知が証明にならない論点は 「AI 時代のサイバー防衛に残された、最後の層」（Lemma、2026-05）、行動前に独立検証する設計は 「Proof-as-Auth: 鍵を一度も送らずにサインインする」（Lemma、2026-05）を参照。

対応経緯と業界動向

  • Polaris Holdings: 異常検知後に全ホテルでパスワードをリセットし、Booking.com・当局と連携してアクセス経路とログを追跡。被害範囲を継続調査。カード漏洩は未確認
  • 業界横断の論点: Booking.com パートナーを狙うキャンペーンはベンダーリサーチで継続追跡されており、多くは宿泊客のカード情報を狙うフィッシングである。本件はその延長線上にありつつ、事業者の受領口座という資金経路設定を突いた点で、被害が事業者の直接損失に転化する。SaaS/プラットフォーム上の業務データ(送金先・連絡先・権限設定)の変更を、変更時点でどう独立検証するかという論点が浮上している

「資金移動に直結する設定変更を、認証済みセッションの操作としてではなく、認可と属性の真正性の証明として扱う」必要性が、本事案を契機に宿泊・EC・プラットフォーム事業者の間で再認識される見込み。

Lemma による分析

本事案で露呈した構造(資金移動に直結する受領口座変更が、変更時点の認証だけで受理され、認可と属性の真正性が独立検証されない)に対して、Lemma は、高インパクトな属性変更を実行前に独立検証可能な証明として扱う設計を提示している。

  • 変更前の事前証明: 受領口座のような資金経路設定の変更を、認証済みセッションの操作としてではなく、実行前に独立検証可能な proof として要求する。
  • 属性の真正性検証(P4): 新しい送金先が「正規に確立された真正な口座属性か」を、変更の前提として proof で確かめる。
  • 変更指示の来歴検証(P1): 「誰が・どの正規の認可で変更したか」という指示の正当な来歴を、資金移動の前に独立検証する。
  • 欠落時の事前 block: proof が認可または真正性の欠落を告げれば、認証済みセッションであっても変更と後続の送金を事前に reject する。

これにより、認証済みセッションであっても正規の認可と真正性を欠く変更は事前に reject され、検出は事後でなく事前の証明によって補完される。

設計と適用範囲は、Pillar 04 — 規制属性証明 および Trust402 を参照のこと。

Sources

Brief 配布について

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。

(c) 2026 FRAME00, INC. — Built for decisions that matter.

関連 Brief
属性証明バイパスの全 32 件を見る
No. 065 · 2026-06-17

北海道の国立病院：「破砕した」という前提のまま、患者 18 万人分の HDD が中古市場に流れた

機微媒体の廃棄が独立検証可能な破壊証跡として固定されない構造（NHO 北海道医療センター・北海道がんセンター）

属性証明バイパス データ来歴
Brief →
No. 052 · 2026-06-12

年齢を証明するために渡した政府 ID 7 万枚が、第三者から流出した

規制属性（年齢）の証明と生 ID の保管が分離されていない構造（Discord / 5CA）

属性証明バイパス データ来歴認証・認可
Brief →
No. 050 · 2026-06-12

非同意の画像が、生成の時点で誰の同意も年齢も確かめられずに作られた

被写体の同意・年齢と生成物の来歴が、生成時点で独立検証されない構造（Grok）

属性証明バイパス データ来歴AI 判断の完全性
Brief →
Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"正規の予約プラットフォーム内で、売上金の受領口座が書き換えられた — 送金先変更が、資金移動の前に独立検証されなかった(Polaris Holdings / Booking.com)".
Lemma Critical Brief No.032. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/032-booking-payout-account-tampering/