Contents
TL;DR — A guest books a real hotel on a real platform, and two days before check-in gets a message through the platform's own chat: the card needs re-verifying, click here to keep the reservation. The message is genuine in every technical sense. It comes from the hotel's real account, quotes the real booking, and lands exactly when a real payment-confirmation message would. The only fake thing is the link. Attackers compromise the hotel's account (usually with a ClickFix fake-CAPTCHA lure that installs an infostealer), watch the incoming reservation queue, and message each new guest a "complete your booking" payment page that harvests card details. Security researchers call it the Reservation Hijack scam; Sekoia tracks the guest-fraud wave as "I Paid Twice." We pulled apart a live example,
form.hand-made-easy[.]com, and this is how the whole chain works.
About this analysis. This is a technique breakdown built from three primary sources — Microsoft Threat Intelligence, Sekoia.io, and Gen Digital's Norton team — plus our own first-hand look at a live payment-phishing page still serving at the time of writing (16 July 2026) and passive infrastructure analysis of the surrounding domain cluster. Every third-party figure is attributed to its publisher. All live URLs are defanged throughout, and we submitted nothing to any of them.
The lure that is indistinguishable from the real thing
Most phishing works by imitation. It builds a fake that looks close enough to the real sender, the real brand, the real login page, and hopes you do not look too closely. The Reservation Hijack scam does not imitate the workflow. It hijacks the real one.
When your message arrives through Booking.com's in-app chat, it is not spoofed. It is sent from the actual hotel account, which the attacker controls. The reservation it quotes is your reservation, with the correct dates, room type, price, and the name on the booking. It arrives a few days before check-in, which is exactly when a front desk often does send a genuine "please re-confirm your card" note. As Gen Digital's researchers put it, the fake message is indistinguishable from the real workflow because it is the real workflow, only with a different payment link.
That is what makes this technique so effective, and so worth understanding in detail. Every instinct that normally protects a traveler — "is this really my hotel?", "does the booking match?", "is this the right channel?" — returns a green light, because all of those things are real. The single malicious element is the destination of one link.
The kill chain, stage by stage
The attack has two halves. First the operator takes over a hotel's booking-platform account. Then they monetize every reservation that flows through it. The property is the entry point; the guests are the payout.
Phase 1: taking over the hotel
The entry point is the hotel, not the guest. According to Microsoft, which tracks the most prolific operator as Storm-1865, the campaign starts with emails to hotel reservation and support inboxes. The lures are mundane hospitality business: a negative guest review that needs a response, a prospective-guest inquiry, an online-promotion opportunity, or an account-verification demand. Each links to a page that runs a ClickFix sequence: a fake CAPTCHA overlaid on a mock Booking.com background tells the staff member to press a keyboard shortcut, which opens the Windows Run dialog, and paste a command the page has quietly copied to their clipboard. The command runs mshta.exe and pulls down malware.
That malware is a credential stealer. Microsoft observed Storm-1865 delivering a suite of them — XWorm, Lumma Stealer, VenomRAT, AsyncRAT, DanaBot, and NetSupport RAT. Sekoia's analysis of the related "I Paid Twice" campaign found the ClickFix chain dropping PureRAT, a modular remote-access trojan that runs filelessly in memory, persists through registry Run keys, and talks to its command server over TLS on ports 56001 to 56003. Whichever family is used, the goal is the same: harvest the saved credentials and session cookies for the hotel's account on Booking.com, Expedia, or its property-management system.
Those credentials feed a market. Sekoia documented hotel extranet logins selling for $5 to $5,000 for high-value entries (with bulk lots as low as $0.20 to $2), and a broker it names moderator_booking buying logs at $30 to $5,000. A hotel does not need to be individually targeted to be hit; it just needs one staff member to run one clipboard command.
Phase 2: farming the reservations
Once inside the account, the attacker has what no ordinary phisher has: a live, authoritative feed of real bookings. They can read the messages between hotel and guest, see every upcoming arrival, and, crucially, message guests through the platform's own trusted channel.
Every new reservation is a fresh target with fresh, accurate data, and the scam runs continuously until the hotel detects the intrusion and revokes access. The guest gets a message — through Booking.com's in-app chat, WhatsApp, SMS, or email, whichever the property normally uses — that references the real booking and manufactures a small, plausible urgency: the card failed pre-authorization, the reservation needs re-verification, pay a deposit now or lose the room. The message carries a link. Sekoia calls the resulting fraud "I Paid Twice" because the classic outcome is a guest paying for a reservation a second time on a fake page, believing the first payment did not go through.
Inside a live example: tracing the chain
To show the payment stage concretely, we followed a live cluster while we wrote this (16 July 2026). It runs the reservation-hijack pattern end to end — a redirector, a cloaking gate, and a card-harvest page — and the way it defends itself is instructive.
The link a guest receives is a redirector, not the payment page. In this cluster it looks like send.sdbrjf[.]com/en-gb/{token}/{booking-id} — a locale path (/en-gb/), a random token, and a numeric booking-style id. It forwards to a cloaking gate, form.hand-made-easy[.]com/captcha, which only then hands the visitor off to the payment page, form.{domain}/merchant/order/{order-id}. When we requested the payment URL directly from a server it returned HTTP 403, because the gate stands in front of it.
The gate is a custom fake CAPTCHA: "Verify You're Human — enter the 5 digits shown below," with an "I'm Not a Robot" button. It is not a real Cloudflare Turnstile or Google reCAPTCHA; it is a hand-built human check whose only job is to keep automated crawlers, sandboxes, and security scanners away from the payment page. The operator went further still, watermarking the challenge image with "AI RECOGNITION PROHIBITED" and adding a footer forbidding AI and LLM systems from reading the page — a bespoke attempt to blunt the AI-assisted analysis defenders increasingly rely on.
form.hand-made-easy[.]com/captcha, captured live on 16 July 2026. Note the AI RECOGNITION PROHIBITED watermark baked into the challenge image and the anti-AI-scraping footer. URL defanged; nothing was submitted.Past the gate sits the payment page. We reached the payment stage on a sibling domain in the same cluster, form.5678106[.]com — which shares hand-made-easy's aaden/irma Cloudflare nameservers — and it is a polished fake Booking.com checkout that even tabs its browser title as "Booking.com | Official website." It was pre-populated for a real apartment listing in Montenegro (we are not naming the impersonated property) with the guest's check-in and check-out dates and a total of roughly 850 USD already filled in, exactly the auto-population Sekoia described. The psychology is the giveaway: the page is dressed as a refund, not a charge. It reads "Refunds will be made to the specified card," shows the same amount as money "to be refunded," and promises "Refunds will be processed within 3-5 business days" — while asking for the cardholder name, full card number, expiry, and CVC. This is the "I Paid Twice" trick made literal: the victim believes they are receiving money back and hands over everything needed to charge them instead.
The infrastructure is a tight cluster. Two payment domains and the redirector all share the same fingerprint, and two of them are assigned the identical Cloudflare nameserver pair, consistent with a single Cloudflare account:
| Host | Role | Registered | NS moved to Cloudflare | Cloudflare NS pair |
|---|---|---|---|---|
send.sdbrjf[.]com |
Redirector (/en-gb/…) |
18 Sep 2018 | 16 Jul 2026 | audrey · jakub |
form.hand-made-easy[.]com |
Gate + payment (/merchant/order/…) |
19 Sep 2023 | 15 Jul 2026 | aaden · irma |
form.5678106[.]com |
Payment (/merchant/order/…) |
24 Jul 2021 | 16 Jul 2026 | aaden · irma |
Every one was registered through Gname.com, every one is an aged domain (2018 to 2023) that predates the campaign by years, and every one was repointed to Cloudflare within 48 hours of use. The aged registrations sail past "newly registered domain" filters; the Cloudflare front hides the origin and slows takedown; the shared aaden/irma nameserver pair on hand-made-easy[.]com and 5678106[.]com is consistent with a single Cloudflare account behind both. It is exactly the recipe Sekoia documented — Cloudflare-fronted pages, booking details auto-filled by Ajax, infrastructure built to resist inspection. We reported these domains for takedown, then pivoted on their fingerprint to map the wider cluster below.
The wider cluster: pivoting to more domains
The three hosts above are not the whole operation. We pivoted on every hard signal they share — the /merchant/order/{id} payment path, the /captcha gate, the send.{domain}/en-gb/ redirector, the form./booking./send. subdomain triad, the Cloudflare fronting, and the fake "Booking.com | Official website | Best hotels and accommodation" page title — across urlscan.io, Certificate Transparency, passive DNS, and abuse.ch feeds, then verified each candidate independently by registrar, nameservers, domain age, and captured page. This wider mapping used passive sources and public scans only — we submitted nothing to any page and did not enumerate booking IDs.
Two layers came back. The first is a tight core that carries the exact fingerprint of the traced example: aged domains registered through Gname.com, repointed to Cloudflare just before use, serving the form./booking./send. triad.
| Core cluster (defanged) | Role | Registrar | Registered | Cloudflare NS |
|---|---|---|---|---|
hand-made-easy[.]com |
Gate + payment | Gname.com | 2023-09-19 | aaden · irma |
5678106[.]com |
Payment (Booking checkout, confirmed) | Gname.com | 2021-07-24 | aaden · irma |
sdbrjf[.]com |
Redirector (send./en-gb/) |
Gname.com | 2018-09-18 | audrey · jakub |
pjoxy[.]com |
Payment (/merchant/order/) |
Gname.com | 2022-07-28 | irena · ram |
wl211[.]com |
Payment (/merchant/order/) |
Gname.com | 2020-06-29 | (suspended) |
The second layer is the same phishing kit run at scale on fresh 2026 domains, mostly registered through Dynadot, Trustname, and Metaregistrar, with a few more on Gname and CNOBIN. Several of these rendered the fake Booking.com checkout title in public scans, confirming the theme directly:
| Same-kit campaign (defanged) | Theme (captured) | Registrar | Registered |
|---|---|---|---|
com-conflrm-us[.]com |
Booking.com checkout ✓ | Dynadot | 2026-04-07 |
q49t15h[.]com |
Booking.com checkout ✓ | Trustname | 2026-05-06 |
approved-reserved[.]com |
Booking.com checkout ✓ | Dynadot | 2026-05-02 |
n32f73w[.]info |
Booking.com checkout ✓ | Dynadot | 2026-05-21 |
r58a94z[.]com |
Booking.com checkout ✓ | Trustname | 2026-05-05 |
agodaverify[.]com |
Agoda (inferred) | Metaregistrar | 2026-06-22 |
com-conflrmaton-us[.]com, com-517b6c137f[.]com, z49x62y[.]com, p32g76n[.]com, b71r25z[.]com, pre-arrivall-pending[.]com, pre-arrival-revlew[.]com |
same /merchant/order/ kit, page gated behind Cloudflare |
Dynadot / Trustname / Gname / CNOBIN | 2026 |
Two findings are worth calling out. The delivery layer uses an email-tracking host, njftrack[.]com (track.send.njftrack[.]com), which we saw hand off to the sdbrjf → hand-made-easy chain — a legitimate-looking click-tracker fronting the redirect. And the operation is only one node in something much larger. A urlscan search for that exact fake page title returns thousands of scans, and a continuous stream of them are non-booking.com Cloudflare domains running this kit; separately, the /merchant/order/ checkout template turns up under many other brands (Vinted, Etsy, Agoda, DHL and more), which marks it as a shared phishing-as-a-service payment kit of which hotel booking is one theme.
Encouragingly, many of these domains were already on registrar clientHold or takedown nameservers by the time we checked, evidence that abuse reporting on this cluster is landing. We deliberately did not collect any guest or hotel identities. The individual bookings live behind per-victim IDs on the attackers' panels; the right holders of that victim list are the platform and law enforcement, who can act on it lawfully. The infrastructure indicators above are what shrink the payout, and we have filed them with the hosting provider and registrars.
Who is behind it, and what it is called
Because several teams have tracked overlapping activity under different names, the labels are worth untangling.
| Name | Tracked by | What it refers to |
|---|---|---|
| Storm-1865 | Microsoft | The actor cluster running the ClickFix email campaign that compromises hospitality accounts and leads to payment-data theft |
| "I Paid Twice" | Sekoia.io | The guest-facing fraud wave: fake payment pages that trick travelers into paying a reservation twice |
| Reservation Hijack scam | Gen Digital / Norton | The end-to-end scam viewed from the guest's side, using a hijacked but genuine booking |
These are not three separate problems. They are three views of one supply chain: infostealer infections and ClickFix lures at the top, a resale market for hotel credentials in the middle, and guest payment-fraud at the bottom. Sekoia traced its campaign back to earlier infostealer infections inside hotel networks, and Microsoft's Storm-1865 activity has been running since December 2024, spanning hospitality organizations across North America, Oceania, South and Southeast Asia, and Europe.
The scale
This is not a handful of incidents. In research published 28 May 2026, Gen Digital's Norton team identified 350 hotels across 50 countries silently compromised through ClickFix attacks on staff. With a combined capacity of roughly 82,000 simultaneous guests, Gen Digital estimates about 6 million guest stays a year are exposed to follow-up scams from these properties alone. The compromises cluster in Europe.
The platform itself has acknowledged the downstream effect. On 13 April 2026, Booking.com began notifying customers that "unauthorised third parties" had accessed reservation data — names, email addresses, physical addresses, phone numbers, and booking details — through compromised hotel-partner accounts rather than a breach of Booking.com's own systems. The company reiterated that it will "never ask for sensitive information or bank transfers." In the UK alone, Action Fraud logged 532 Booking.com-related scam reports between June 2023 and September 2024, with losses near £370,000, and that predates the current surge.
Why it defeats the usual defenses
Standard anti-phishing advice assumes the attacker is an outsider pretending to be someone you trust. Here the attacker is operating from inside a trusted account, which quietly disables most of the checks:
- Sender authentication passes. Messages through Booking.com's chat or from the hotel's real mailbox are genuinely from where they claim to be. DMARC, SPF, and DKIM all pass, because nothing is spoofed.
- The context is perfect. The booking reference, dates, price, and guest name are correct, so the classic "does this match my records?" test confirms the scam instead of catching it.
- The timing is perfect. The message arrives in the pre-check-in window when a real payment-confirmation note is expected.
- The page is cloaked. As the
hand-made-easy[.]comexample shows, a CAPTCHA gate and per-victim URLs keep the payment form away from scanners, and a Cloudflare front hides the origin from takedown teams. - The channel is trusted. A link inside Booking.com's own app carries the platform's credibility, which is precisely why the platform is abused.
The one thing that does not change is the destination. However genuine everything else looks, a legitimate hotel does not move you off-platform to a stranger's domain to key in your full card number and CVC.
What travelers should watch for
The defense that survives all of the above is a simple rule about where payment happens, not who appears to be asking.
- Never enter card details on a link from a message. Pay only inside the official app or on the platform's own domain, reached by typing it yourself. A real hotel will not need you to key your card into a third-party page.
- Treat urgency as the tell. "Re-confirm within 12 hours or lose your room" is pressure engineering, not hotel policy.
- Check the domain, not the design. The page can copy the hotel's real logo and photos. The address bar is harder to fake —
form.hand-made-easy[.]comis notbooking.com. - "I already paid" is the trap. If you are asked to pay again because a payment supposedly failed, stop and contact the hotel through a number you look up independently.
- A CAPTCHA before a payment form is a red flag. Legitimate checkout does not gate your card entry behind a "prove you're human" step designed to keep scanners out.
What hotels and platforms must do
The guest-facing advice only limits the damage. The leverage is upstream, at the property and the platform.
Hotels should treat the booking-platform account as critical infrastructure: enforce phishing-resistant multi-factor authentication (passkeys or FIDO2 security keys) so a stolen password and cookie are not enough, train front-desk and reservations staff to recognize ClickFix "paste this into the Run box" lures as always malicious, and run endpoint detection that catches infostealers like PureRAT and Lumma before credentials leave the building. Microsoft's guidance for this campaign centers on exactly these controls, plus time-of-click link protection and rapid credential resets on any suspected compromise.
Platforms carry the structural fix. When a partner account can be taken over and used to message thousands of guests with off-platform payment links, the abuse is systemic. Anomaly detection on partner logins, hard friction on messages that push guests to external payment domains, and fast, well-staffed takedown of the phishing infrastructure are the levers that actually shrink the payout. The hosting side matters too: this infrastructure is fronted through Cloudflare, which hides the origin server, and provider abuse-response times are a systemic lever — faster action on abuse reports across hosts and registrars is part of the answer, a theme we return to in our Cloudflare Workers phishing and Cloudflare Drop research.
This is where continuous external monitoring earns its place. The payment domains in this scam are registered and fronted days before use and rotate constantly, so detecting lookalike and payment-themed domains as they appear, and pushing takedowns quickly, is exactly the brand-protection work platforms and large hospitality brands need running around the clock. It is the core of what PhishEye does.
Sources
- Microsoft Threat Intelligence, Phishing campaign impersonates Booking.com, delivers a suite of credential-stealing malware (Storm-1865), 13 March 2025.
- Sekoia.io, The Booking.com phishing campaign "I Paid Twice" targeting hotels and customers.
- Gen Digital (Norton), Luis Corrons and Martin Chlumecký, Reservation Hijack scams target travelers, 28 May 2026.
- Malwarebytes, Booking.com breach gives scammers what they need to target guests, April 2026.
- First-hand analysis:
form.hand-made-easy[.]com, captured 16 July 2026 (PhishEye Threat Research).
FAQ
What is the hotel reservation hijack scam? It is a phishing technique where attackers take control of a hotel's account on a booking platform such as Booking.com, watch the incoming reservation queue, and message each guest a link to "complete" or "re-verify" their booking payment. The link leads to a fake payment page that steals card details. Because the message comes from the real hotel account and quotes the real booking, it is extremely convincing.
How do the attackers get into the hotel's account? Usually with a ClickFix lure. Hotel staff receive an email posing as a guest review or booking inquiry, are sent to a fake CAPTCHA page, and are tricked into pasting a command into the Windows Run box. That installs an infostealer (Microsoft has seen Lumma, XWorm, VenomRAT and others; Sekoia documented PureRAT) which steals the saved booking-platform credentials.
Is Booking.com itself hacked? No. In its April 2026 notice, Booking.com said the data was accessed through compromised hotel-partner accounts, not a breach of its own systems. The reservation data attackers use comes from the individual hotel accounts they take over.
Why does the scam message pass every authenticity check? Because almost nothing about it is fake. It is sent from the hotel's genuine account through the platform's real messaging or the hotel's real mailbox, so it passes DMARC, SPF and DKIM, and it quotes your correct booking details and arrives when a real payment note would. The only fake element is the payment link's destination.
How can I tell a real hotel payment request from a fake one? Judge it by where you are asked to pay, not by who appears to be asking. Pay only inside the official app or on the platform's own domain that you type yourself. Be suspicious of urgency, of any request to pay again for a booking you already paid, and of a "prove you're human" CAPTCHA appearing before a card form. When in doubt, call the hotel using a number you look up independently.
What should hotels do to stop it? Protect the booking-platform account with phishing-resistant MFA (passkeys or FIDO2), train staff that "paste this into the Run box" instructions are always malicious, deploy endpoint detection that catches infostealers, and reset credentials immediately on any suspected compromise.
About the authors
PhishEye Threat Research is the anti-phishing and digital-risk-protection team behind PhishEye. We hunt phishing infrastructure daily across passive DNS, Certificate Transparency, and newly-registered-domain feeds, and we file the takedowns that follow. The live example in this article, hand-made-easy[.]com, was pulled from that pipeline and reported for takedown. Our related first-hand investigations include IronToll, a live SMS-OTP-intercepting PhaaS campaign, and ClickFix on-chain C2, the same fake-CAPTCHA delivery technique that seeds the hotel compromises described here.
This analysis summarizes independent third-party research alongside our own findings. Every external figure is attributed to its original publisher, and we have not altered any published number. The defanged live indicators are provided for defensive and educational purposes only.
Spotted a reservation-hijack domain or want a lookalike monitored? Contact the team at [email protected].