TL;DR
- 01What happened
An outsider got into the Booking.com account used by hotel operator Polaris Holdings and, at several hotels, switched the bank account that receives sales to their own. At one hotel part of its receivables (money it was owed) was paid into that account, a loss of about ¥9 million. At the other hotels, fraudulent payouts were prevented through what the company calls an early response.
- 02Why it looked normal
The change was made in the legitimate admin screen, as a logged-in action. To the system it was indistinguishable from a routine settings update.
- 03The missing layer
Detection worked: detection and an early response kept the loss to one hotel. What failed was the layer in which someone other than the person making a payout-account change confirms it before money moves.
What happened
- Who
- Polaris Holdings, a hotel operator. Its hotels were managed on the booking site Booking.com through a group-level account.
- What was changed
- The bank account Booking.com pays hotel sales into. Hotels register it in the admin screen; it was switched to a third party’s account.
- Loss
- At one hotel, part of its receivables (money it was owed) was paid into the fraudulent account: a loss of about ¥9 million (as of disclosure). Accounts were also changed at several other hotels, but an early response prevented fraudulent payouts there.
- Impact on guests
- Some guests received phishing messages. The company is examining two possibilities: booking data taken from the admin screen, or a leak from an external booking-management system.
- How they got in
- Under investigation and not disclosed. This Brief does not speculate.
- Industry context
- Booking.com’s hotel admin site (the extranet) has long been a target. In November 2025 the security firm Sekoia documented emails posing as Booking.com that trick hotel staff into running malware and steal their admin logins. Guests were then contacted by email from the hijacked account or over WhatsApp, with real booking details attached, and led to a page posing as a re-check of their payment details.
Glossary
Extranet — The admin site Booking.com provides to hotels.
Authenticated session — The state after a successful login. Anything done in it looks like a legitimate action to the system.
The point to stop it was ②, when the change took effect. The payment at ③ itself followed the registered details. The disclosure does not say whether ④ came before or after ③.
Route under investigation.
Several hotels' accounts, switched to a third party's.
One hotel's payout lands in the fraudulent account.
Through what the company calls an early response.
The payment at step 3 was a normal payment to the registered account. The problem is that the change at step 2 was accepted as a legitimate one.
Timeline — disclosure and response
- Polaris spots an anomaly in its group Booking.com account and starts investigating.
- Payout accounts at several hotels had been rewritten. At one hotel part of the receivables was paid into the fraudulent account, a loss of about ¥9 million; at the others an early response prevented fraudulent payouts.
- Polaris discloses the unauthorised access. The travel-industry outlet TRAICY reports it the same day.
- through 06-03, security outlets ScanNetSecurity and Security NEXT report it.
The facts here rest on Polaris Holdings’ disclosure of 28 May and the reporting on it. How the attacker got in, and whether guests’ personal data leaked, were still under investigation at disclosure. The disclosure document has since been taken down from the company’s site, so this Brief cites the press coverage.
After disclosure
- Polaris: changed the passwords of every hotel’s Booking.com-related accounts, requested the access logs, and acted to contain the damage. No credit-card data leak has been confirmed. It expects a minor impact on earnings.
- Industry: attacks on Booking.com’s hotel admin site keep being disclosed in Japan as well. Most target guests with phishing; this case went a step further and rewrote the hotel’s own money flow, turning the attack into a direct loss.
Why it wasn’t stopped
The failure here is not just that someone got into the account. It is that no layer had another person confirm a payout change before it took effect.
A change to where the money goes went all the way through on a logged-in session alone.
Login checks “is the person coming in the registered user?” It does not check what they do once inside. In security terms, the logged-in state is an “authenticated session”, and anything done in it looks legitimate to the system. Changing a payout account is handled exactly like changing a contact address.
Detection worked. Polaris detected the anomaly, and fraudulent payouts at the other hotels were prevented. But detection works only once an anomaly surfaces. Even so, one hotel’s payout went through; the disclosure does not say whether before or after detection. The point to stop it was earlier: when the payout-account change took effect.
Proof acts before a change takes effect; detection acts after an anomaly surfaces. In between, the rewritten account is treated as a valid setting.
No one has noticed yet
The distance between noticing an anomaly and confirming a change is right is what this Brief calls the detection–proof gap, and it is a structural one.
The same shape appears in Revolut, which answered disclosure requests arriving through a national certified-mail network, and in SpeeCAN RAIDEN, whose genuine sending domain delivered fake mail. In each, “it came through the legitimate channel” stood in for “it is a legitimate request”.
How to counter this
With the right mechanism, this attack could have been partly prevented. If a payout-account change does not take effect until another person confirms it through another channel, the rewrite stops there. But the change happened inside Booking.com’s admin screen, so that mechanism has to be built into the booking platform. What users can add on their own side is a way to stop payment after a change and before the first payout: have someone other than the changer receive change notifications, and if a change is not recognised, ask the platform to stop payment.
Industries and operations to watch
- IndustryServices & retail
- Lodging, restaurant and retail businesses that receive sales through booking sites, e-commerce platforms or payment processors. The payout account lives in an external service’s admin screen.
- IndustryFinance & FinTech
- Banks and payment providers that accept payee registrations and changes. A payee rewritten on the customer’s side still arrives as a valid instruction.
- OperationPayee & bank-account changes
- Registering or changing a supplier’s or your own receiving account. The result does not show until the next payment.
- OperationAccounts & permissions
- Managing external-service accounts and who can change what. This rewrite came from a hijacked account.
The same hole exists in many organisations, not just hotels: finance changing a supplier’s bank details, adding a payee in online banking, setting the receiving account on an e-commerce or payment service. In each, anyone who can log in can change it on the spot, and the result does not show until the next payment. And often no one has been made its owner.
- Finance
- Handles accounts and payments. Tends to see the change as “a systems issue”.
- IT
- Manages accounts. Tends to see the change as “a business issue”.
- Business units
- Sign up for and use booking sites and payment services day to day.
Between the three, no one has the job of asking “is this payout change really right?” Here, one hotel alone lost about ¥9 million.
Do today’s controls close it?
| Control | Here | Why |
|---|---|---|
| Multi-factor authentication (MFA) | Partial | Works at the door. The route in has not been disclosed, so whether it would have helped here is unknown. It is bypassed when the device or the logged-in session itself is hijacked, and it does not look at what is done after login. |
| Endpoint monitoring (EDR) | Partial | May detect an endpoint infection like the one Sekoia describes, but cannot see settings changed inside a booking site or other external service. |
| Call-back verification | Ineffective | Works when a supplier asks to change its account. When your own settings are rewritten, as here, nobody gets a call. |
| Email authentication (DMARC etc.) | Not relevant | Reduces email spoofing, but has nothing to do with this rewrite. |
- Someone other than the changer confirms it. A payout change does not take effect from a logged-in action alone. Before it does, confirm that a designated second approver has approved it through a channel separate from the login. If approval can come through the same channel as the hijacked account, it is worthless.
- Confirm the new account really is yours. Back up the account holder’s name with the bank’s own check. This works even if the approver is fooled.
- Hold what cannot be confirmed, and record what was. Changes that cannot be confirmed stay on hold, and payments to that account stop. Keep when, on whose approval, and to which account a change was let through, in a form you can later show a third party — that is, as proof.
Three things to confirm in your organisation about payout changes
- Which accounts can change the receiving or payee account? When one is changed, who other than the person who changed it is notified?
- Can you hold the first payment in or out until someone other than the changer confirms the change by a different means than the one used to register it?
- Who reconciles the first receipt or payment after a change, and within how many days? If it does not match, can you stop the next transfer?
Note: this still fails if the approver is tricked into approving, or if the approval channel is also hijacked. Holding changes until confirmed also delays legitimate ones.
Sources
- Primary, company disclosurePolaris Holdings “Notice of unauthorised access (Booking.com account)” (Japanese)
4 more (reporting, analysis)
- PressSecurity NEXT “Payout account details at lodging booking service tampered, fraudulent transfer — Polaris HD” (Japanese)
- PressTRAICY “Polaris HD suffers fraudulent transfer after unauthorised access to Booking.com; phishing messages to guests also confirmed” (Japanese)
- PressScanNetSecurity “Unauthorised access to Booking.com, sales payout account tampered; about ¥9 million lost” (Japanese)
- Industry researchSekoia “Phishing campaigns ‘I Paid Twice’ targeting Booking.com hotels and customers”
References: Why after-the-fact detection is not proof — “The last layer left for cyber defense in the age of AI”.