B2B2C Supply Chain Attack: Hotel’s Booking Accounts Compromised to Target Customers
Since May 2025, an attacker targeting Booking[.]com customers has generated nearly 1,000 spoofed booking and hotel reservation domains. The attackers appear to be compromising hotel booking management accounts to target Booking[.]com customers directly through the platform’s official messaging channels. By sending urgent “verify or cancel” notifications, they direct victims to external phishing sites that dynamically load the traveler’s actual reservation details to steal payment information.
Details
Attack Breakdown
The attack began by compromising hotel booking accounts. Though the specifics are as of yet unknown, it is likely this activity is a tied to attacks reported in November 2025 by Sekoia.io, dubbed the “I Paid Twice” phishing campaign. Sekoia labs suspected the attacker targeted hotel staff to steal credentials for booking platforms. A question remains if the attacker targeting hotels is the same one operating the phishing kits to target the hotel’s customers. Sekoia noted that such stolen hotel booking credentials are sold on Russian-language forums for under $5,000 each. Furthermore, while we found no direct links, a Microsoft STORM-1865 report shares many of the same characteristics with exception of an identified malware delivery component.
Once the attacker obtained these credentials, they then used that access to send lures to the hotel’s customers through Booking[.]com’s services. The victim receives a Booking app message and email from Booking[.]com with a message that they need to update their booking information within 8 hours or risk having their booking cancelled. If the user responds to the message, the attacker sends a URL to an attacker-owned domain with a customer-specific tracker ID.


On the attacker’s website it first presents a fake CloudFlare “Confirm that you are human” checkbox.

In fact, the main page loads an iframe containing the fake button and starts a timer to ask the server if the user has clicked yet.

Upon clicking the fake verification button, the site reloads, taking the customer’s booking ID from the URL and matching it against the data they stole from the hotel. The phishing page is dynamically generated to look like Booking[.]com hotel booking forms. The page is populated with the reservation hotel details and check in date. The victim is lured into re-entering their personal contact details including name, email and phone number.

Subsequently they are asked to re-enter their payment information for the hotel booking.

This appears to be the end goal of the attack, to retrieve contact info and payment information. Normally, we might expect this level of effort and ability to leverage trusted business relationships to attempt to distribute malware such as NetSupport RAT, but as of writing this investigation, the goal of the attack appeared limited to payment information harvesting.
Phishing Web Kit
The filepaths and scripts suggested the attack may involve Scraper/Interceptor kits, which are used almost exclusively for Booking[.]com and Airbnb scams. Such kits are often associated with the Telekopye toolkit or the “U-Admin” ecosystem (Russian-origin phishing-as-a-service).
Common filepaths for the webkit:
- /dist/sites/ALL/booking/favicon.ico
- /dist/booking/booking/styles-new4.css
- /dist/booking/booking/submit-new8.js
It also uses a polling Ajax endpoint with a specific set of PHP files to synchronize the victim’s browser with the attacker’s control panel:
- /ajax/captcha.php (The “Check” stage)
- /ajax/payment_card_status.php (The “Redirect” controller)
- /ajax/user_send_status.php (The “Progress” tracker)
- /ajax/change_language.php
This specific naming convention(payment_card_status.php) is a known signature of the “Drainer” or “InfoStealer” variants of the Booking[.]com phishing kit.
However, the sites investigated appeared to use a database of stolen booking information from Booking[.]com and used it to dynamically populate pages for each victim. These factors suggest the attacker is using frankenstein code partially from a common Booking web kit to dynamically load victim specific information.
Domain Infrastructure
One of the domains resolved to “80.64.19[.]92”, which has several overlaps with “77.83.207[.]34” including the following:
- host TLS fingerprint host.services.tls.fingerprint_sha256
- Ac410155847201fd764f6c56a40c7e2de7c632e22dc97a5a3dffdd7894d69c69
- host.services.ssh.server_host_key.fingerprint_sha256
- b27da9759a8f931abb34cf1a4b04aeb7979d89504f791afc28e7116288b38728
Both of the IP addresses above are based in Moscow, Russia and are seen hosting the same services from Debian Linux operating systems: Proftpd Project Proftpd, Exim, Isc Bind, F5 Nginx, Dovecot
The strong link between both IP addresses is notable as the “77.83.207[.]34” has resolved over 370 domains since May 2025 that spoof hotel and confirmation related themes, and those domains have unique emails and registrant names exposed in the registration details.
The registrant email addresses link additional IP addresses resolving large numbers of similar domain name patterns in the same timeframe including “91.92.46[.]181” with another 358 domains and “172.86.75[.]75” with 41 domains.
In a few cases domains were previously seen spoofing as Booking[.]com in December 2024 including the following two now reused in 2025 for similar purposes:
- fastchek-by-booking[.]com
- check-via-booking[.]com

Dominant Themes by Frequency (Themes May Overlap)
| Theme | Domain Count | Percentage |
| Numeric ID patterns | 302 | 30.40% |
| Confirmation ID | 264 | 26.60% |
| Check/Verify operations | 253 | 25.50% |
| Card verification | 138 | 13.90% |
| Guest references | 109 | 11.00% |
| Reservation terms | 73 | 7.30% |
| Guest verification | 64 | 6.40% |
| Hotel references | 37 | 3.70% |
| Stay/Room terms | 25 | 2.50% |
| December (temporal) | 10 | 1.00% |
| Extranet references | 9 | 0.90% |
Primary Spoofed Entity: Booking[.]com
| Entity Spoof | Domains | Note |
| Booking[.]com | 303 | Possible brand reference |
| BWH Hotel Group (Best Western) | 13 | Explicit branding |
| Expedia | 3 | |
| Agoda | 2 | |
| Hotel PMS systems (Octorate, WuBook) | 2 |
Specific Properties Being Impersonated
| Hotel/Location | Domain(s) |
| Myrtle Beach Resort | themyrtlebeachresort[.]icuthemyrtlebeachresorts[.]info |
| Clipper Hotel | clipperhotel[.]icu |
| Hotel Pinomar | hotel-pinomar[.]world |
| Hotel Casa Valdese Roma | hotelcasavaldeseroma[.]icu |
| Hotel Ambasador | hotel-ambasadorssi[.]com |
| Nest Hotel Incheon | nesthotelincheon[.]com |
| Le Grand Bellevue | legrandbellevue[.]com |
| Hillpark Hotel | verif-hillpark-hotel[.]com |
| Louvre (Paris attraction) | payforlouvre[.]xyz |
Conclusion
This campaign abuses trust relationships within the hospitality supply chain. By leveraging compromised hotel credentials to send messages through authenticated Booking[.]com channels, threat actors bypass standard email security gateways and user vigilance.
For defenders, the primary detection opportunities may lie in the distinct infrastructure patterns rather than the delivery mechanism. While the current objective appears limited to financial fraud, the actors’ established foothold within hotel administrative portals presents a significant latent risk for lateral movement or the deployment of persistent malware (e.g., NetSupport RAT) in future campaigns. The apparent theft of customer booking information also presents a latent risk to customers for follow on phishing attacks.
A question remains, why have Booking[.]com and affected Hotel chains been silent? The answer may be that Booking[.]com legally positions itself as an intermediary and may argue that the hotel is responsible for their own poor security.
What Victims Should Do
If you have received a suspicious message or believe you may have been compromised:
- Contact the Hotel Directly: Call the hotel using a number from Google Maps (not the one in the suspicious message) to verify if the request is legitimate.
- Check the URL: Genuine Booking[.]com payments occur only on Booking[.]com. Any other URL (e.g., booking-secure-verify.com or hotel-reservation-check.com) is a scam.
- Initiate a Chargeback: If you paid, immediately call your bank. Report the transaction as “fraud due to a compromised merchant account,” not just a billing dispute.
- Secure Your Accounts: Change your Booking[.]com password and enable Two-Factor Authentication (2FA). If you reused that password elsewhere, change it there too.
- Ignore “Recovery” Scams: Be wary of third-party services or random social media accounts claiming they can “recover” your lost funds; these are often secondary scams targeting already vulnerable victims.
Third-Party Platform Risks & Mitigation
This campaign highlights an architectural weakness in the hospitality sector: the operational dependency on third-party platforms (like Booking[.]com) that may not provide enterprise-grade security controls. Hotels are effectively granting “trusted insider” status to external vendors without the ability to enforce internal security policies on those platforms such as the following:
- Session Kill Switches: The inability for admins to monitor and force-terminate sessions.
- Granular Outbound Filtering: The lack of controls to block sessions from sending unapproved URLs to guests.
- Strict Access Control: The absence of IP-allowlisting to restrict login access solely to the hotel’s physical network.
Since hotels cannot force third parties like Booking[.]com to change its architecture or take on specific security liabilities or guarantees for the hotel’s use of their services, the best strategy may be to treat them as an untrusted environment. The most practical defense may be to abstract the user interface away from the staff through your Property Management System (PMS) where more granular controls may be implemented.
IOCs
A full list of IOCs can be found on our GitHub.
Domain Name Regexp Patterns
| confirmation-id\d+\.(com|world|click)verif(y)?gu[ea]st\d+-booking\.comcard(verif(y)?|id)\d*-booking\.(cconfirmation-id\d+\.(com|world|click) verif(y)?gu[ea]st\d+-booking\.com card(verif(y)?|id)\d*-booking\.(com|world) [a-z]+-[a-z]+-[a-z]+\.(icu|click) .*-booking\.com$ |
| confirmation-id081277[.]com confirmation-id081273[.]com confirmation-id081299[.]com confirmation-id155632[.]com confirmation-id755632[.]com confirmation-id897923[.]com confirmation-id196632[.]com confirmation-id78443[.]com confirm-reserve[.]com confirmation-one[.]click verifyguets3438-booking[.]com verify-details574[.]world bookedehotelle2025[.]com verifyguets25148-booking[.]com verifyguets24111-booking[.]com verifyguets84511-booking[.]com verifyguets71561-booking[.]com confirmation-id871234[.]com verifyguets74341-booking[.]com confirmation-id72694[.]com verifyguets67841-booking[.]com verifyguets12410-booking[.]com confirmation-id784417[.]com …. |
