➽Explainer Article

When Booking.com Becomes the Phisher, Why Everything You Learned About Phishing Might Be Wrong

Jun 4, 2025
|
by Cyber Analyst
When Booking.com Becomes the Phisher, Why Everything You Learned About Phishing Might Be Wrong

➤Summary

Introduction

Most phishing training programs drill three key lessons into users:

  1. Check the sender’s email address
  2. Don’t click unknown links
  3. Look for bad grammar or poor formatting

These rules work — until they don’t. In May 2025, a sophisticated phishing scam targeting an elderly guest turned these “lessons” into liabilities. The scam used real booking data, came from Booking.com’s own mail server, and appeared in a format indistinguishable from legitimate hotel messages. The victim? An 83-year-old woman. The mistake? Trusting Booking.com.

 

🧠 The Traditional Model of Phishing Defense Is Broken

Most security awareness programs are still stuck in the past. Users are taught to:

  • Hover over links
  • Inspect sender names
  • “Trust your gut” when something looks off

Some advanced users even check email headers for SPF/DKIM records.

But what if:

  • The email is sent from a valid Booking.com server (@property.booking.com)
  • The headers are 100% authentic, passing all checks
  • The message includes your real name, dates, and reservation info
  • The layout is identical to what Booking.com has sent you before

At that point, there are no red flags. And that’s exactly what happened.

 

📬 This Wasn’t Spoofed. It Wasn’t Faked. It Was Booking.com — Just Abused.

This phishing email didn’t spoof Booking.com. It was Booking.com — just weaponized. The message was delivered from Booking’s own infrastructure (mailout-108-r3.booking.com), authenticated via SPF and DKIM, and came from a trusted subdomain: @property.booking.com.

Phishing email header

That’s because it wasn’t sent by an outsider — it was sent by someone who had legitimate access to the Booking.com Partner Portal: the hotel’s interface to manage reservations, message guests, and handle payments. In other words, this wasn’t an email “pretending” to be from Booking.com. It was a Booking.com email — just sent by a malicious actor inside the platform.

 

🔑 What Is the Partner Portal — and How Is It Accessed?

The Booking.com Partner Portal is the platform that hotels and property managers use to:

  • View guest bookings and contact details
  • Modify reservations or mark no-shows
  • Message guests directly (via email or the Booking.com app)
  • Manage pricing, availability, and payment policies

Each hotel gets access credentials (username and password) for this system. It’s essentially the backend interface for suppliers — like a CRM for hospitality. But here’s the problem: Booking.com doesn’t require multi-factor authentication (2FA) for access. If a hotel employee’s password is phished or guessed — that’s it. The attacker has full access.

 

🎣 Where the Compromise Likely Happened

In this incident, the most probable root cause is that the hotel’s partner account was compromised. How?

  • Phishing attack against the hotel staff: e.g., a fake “reset your Booking.com password” email.
  • Malware infection on the hotel’s PC: logging keystrokes and browser sessions.
  • Password reuse: same password used on another breached platform.
  • No real IT security controls: most small hotels have limited cyber hygiene and no staff training.

Hotels — especially small, independent ones — are usually not equipped to handle this kind of threat. Their staff often reuse credentials, click on suspicious links, or log in from insecure networks. Booking.com gives them powerful access without enforcing proper controls. And in the end, it’s the guests who pay the price — not the hotel, not Booking.com.

 

🧱 Why Booking.com Is the Perfect Attack Vector

Booking.com is:

  • A trusted brand
  • Known for automated, partner-initiated messaging
  • A platform where last-minute payment requests are normal (e.g., “your card failed,” “please confirm before check-in”)

This trust model is ripe for abuse. Once a partner account is compromised:

  • The attacker can see guest details
  • Craft targeted messages in multiple languages
  • Use Booking.com’s own infrastructure to send them

This kind of phishing cannot be stopped by “user awareness training.” It must be stopped by platform responsibility.

 

🧨 Where Booking.com (and others) Fail

Booking.com:

  • Does not notify guests when a message is sent through the partner portal
  • Allows raw links in partner messages with no link sanitization
  • Has no visible “report abuse” function for recipients of suspicious emails
  • Allows emails to be sent with sensitive info without two-factor authentication for partners

The result? A multi-billion-euro travel platform becomes a delivery mechanism for fraud — and users are left defenseless.

CTA Darknetsearch.com

👵 Victim Blaming in a Broken System

When digital fraud happens, the default response from every involved party is to point elsewhere. “Sure, it’s unfortunate — but not our fault.” This is what happened here, step by step.

 

🏨 The Hotel: Clueless About Their Own Breach

The hotel — whose Booking.com account was almost certainly compromised — has no idea what really happened. When informed of the incident, their response was along the lines of:

“That’s strange, the guest must have clicked on a weird link.”

To them, it’s just another confused customer who “did something wrong.” But what they don’t realize — or deliberately ignore — is that their compromised partner login was used to:

  • Access and leak personal identifiable information (PII) like guest names, dates, emails
  • Send messages through Booking.com that resulted in actual monetary fraud

Under GDPR and Swiss/French/German privacy laws, this is not a minor issue. It’s a data breach — one that legally requires:

  • Immediate internal investigation
  • Notification to Booking.com as the data processor
  • Possibly informing the guest (Article 34 GDPR)
  • Regulatory reporting (if risk is high)

Yet, in practice, most small hotels have no DPO (data protection officer), no awareness of these duties, and no interest in finding out.

 

🏦 The Bank: “Well, She Entered the Code”

Then there’s the bank. Their reaction is blunt:

“She entered her card number. She confirmed the SMS code. The transaction is her responsibility.”

In other words: You gave the thief the keys — not our problem. But that analysis only makes sense if the victim had clicked on something obviously suspicious. This wasn’t “Click here to win a billion dollars.” This was:

  • A trusted platform
  • A legitimate sender
  • A reservation she had actually made
  • A perfectly plausible payment request

If this isn’t covered by fraud insurance, what is? Expecting an 83-year-old to perform forensic email analysis or doubt the legitimacy of Booking.com is absurd.

 

🏢 Booking.com: A Fortress with No Doors

Then there’s Booking.com — the actual enabler of this entire attack. Try reporting the incident?

  • No abuse email
  • No security contact
  • No escalation path
  • Just generic customer service

They treat every report as a support ticket, not a security incident. They don’t even provide for guests a channel to report platform abuse or compromised partner accounts. The result? No accountability.

 

💸 The Payment Processors: Turning Phishing into Real Damage

Finally, the ones who actually make the fraud irreversible: Services like WorldRemit, where the stolen money gets sent. These companies handle legitimate remittances — but they’re also frequent destinations for phishing money. And when you try to report fraud? Nowhere – just call deal with our call center agent! Meanwhile, the money is picked up in cash or transferred abroad — gone forever. No preventive logic, no transaction anomaly detection, no human in the loop. They are the final enabler — the bridge between a phishing page and a stolen pension.

 

🔚 Conclusion: The New Phishing Is Platform-Borne

This is not just a Booking.com problem. It’s happening on Airbnb, Meta, Amazon, and many others. As long as platforms allow third parties to message users — and don’t vet that access properly — they will continue to be weaponized. Phishing is no longer about typos, shady URLs, and Nigerian princes. It’s about perfectly crafted, perfectly legitimate messages, sent from trusted systems, using data users have no reason to doubt. And that’s the real danger: when trust becomes the weapon. Traditional phishing attacks often rely on poorly crafted emails with obvious red flags, such as misspellings or suspicious sender addresses. However, recent incidents demonstrate a more insidious approach: attackers compromising legitimate platforms to send fraudulent messages. For instance, cybercriminals have been targeting Booking.com’s partner hotels through phishing campaigns. By sending fake emails that mimic Booking.com communications, attackers trick hotel staff into revealing their login credentials or installing malware. Once they gain access to the hotel’s Booking.com account, they can send messages to guests through the platform’s official channels, making the fraudulent communications appear authentic (Dark Reading).

🛡️ Challenges in Detection and Prevention

Detecting these sophisticated phishing attacks is challenging for both users and security systems. Since the fraudulent messages originate from legitimate platforms and contain accurate information, traditional indicators of phishing are absent. Moreover, the use of official communication channels makes it difficult for users to discern the legitimacy of the messages. Booking.com has acknowledged these incidents and stated that their core systems have not been breached. However, they emphasize that some accommodation partners have been targeted by phishing emails, leading to unauthorized access to their accounts.

 

📉 The Broader Impact

The consequences of these platform-based phishing attacks are significant. Victims may suffer financial losses, and the reputation of the platforms involved can be damaged. Furthermore, these incidents highlight the need for improved security measures, such as mandatory two-factor authentication for partner accounts and better user education on recognizing and reporting suspicious activities.

✅ 1. Lack of Regulatory Pressure

Current laws like GDPR protect privacy — but offer no clear protection against financial harm when that data is abused through platform negligence.

We need:

  • Mandatory breach reporting not just for data theft, but for account compromise that leads to fraud.
  • Strict platform liability when abuse originates from their infrastructure.
  • Automatic refunds or platform insurance in verified phishing cases (just like stolen credit cards).

 

🏢 2. Untrained and Unprotected Partners

Hotels and other platform partners are often:

  • Under-trained
  • Under-staffed
  • Digitally insecure (no 2FA, shared passwords, no antivirus)

And yet, they are handed direct access to thousands of guest records and messaging systems that can reach those guests directly. If their Booking.com credentials are stolen, the attacker has everything.

These partners need to be:

  • Verified and monitored
  • Required to use 2FA
  • Covered by insurance in case their breach causes guest harm

Booking.com and similar platforms should fund or enforce this — not the guests.

 

🚫 3. No Serious Incident Reporting Infrastructure

Booking.com has:

  • No abuse contact
  • No phishing report form
  • No way for a non-customer to report fraud unless they already have a booking code

This is security theater. It protects their workload, not the user. In a real security incident:

  • The attacker can use the platform infrastructure.
  • The user has no one to warn.
  • The bank denies the claim.
  • The fraud runs unchecked.

This isn’t just a technical gap — it’s a liability shell game.

 

🔁 The Narrative Must Change

We don’t need:

  • More phishing simulations
  • More red-flag awareness
  • More blame when someone is tricked

We need:

  • Structural protections
  • Platform-level accountability
  • Legal mechanisms to recover damages

Because if a platform lets someone impersonate your hotel, use their email domain, and steal your money — then the user didn’t “fail.”
The system did.

💡 Do you think you're off the radar?

Most companies only discover leaks once it's too late. Be one step ahead.

Ask for a demo NOW →