A traveler named Robert Woodford checked his Booking.com account directly — not a phishing link, his actual account — and found a payment request sitting inside the same verified message thread he'd been using to communicate with his hotel. He paid. The money went to criminals. Booking.com's systems were never breached. That's the point.
There is a category of cyberattack that doesn't target the platform — it targets the trust people place in the platform. No servers get breached. No zero-days get exploited. The attackers find the seams between legitimate systems and human behavior, slip through them, and collect money at scale while the platform's security team has nothing to patch.
That is exactly what has been happening to the global hospitality industry since at least December 2024 — and as of late February 2026, it is still happening. The campaign targeting Booking.com partners and their guests is not a single incident. It is an evolving, multi-actor, industrialized fraud operation that has earned criminals tens of millions of dollars by exploiting the trust relationships that make online travel platforms work.
If you've read our breakdown of how ClickFix works as an attack technique, this article will show you what happens when a sophisticated criminal organization applies that technique as just one component of a much larger, more profitable scheme. The mechanics here go well beyond the clipboard.
The Trust Chain Attackers Exploited
Booking.com operates on a three-party trust model. Guests trust that messages from hotels in the Booking.com platform are genuine. Hotels trust that operational emails referencing their reservation management systems are legitimate. Booking.com trusts its partner hotels to manage their own accounts responsibly. Each link in that chain depends on the others.
The attackers understood this architecture better than many of the defenders inside it. They didn't try to break Booking.com. They identified that the weakest link was hotel staff — often not technical, frequently overwhelmed during peak travel periods, and accustomed to acting quickly on platform notifications. Compromise a hotel's account, and you inherit all the trust that Booking.com's brand has built with that hotel's guests. You don't need to send a phishing email from a suspicious domain. You can send it from inside the verified system the guest already trusts.
"Cybercriminals are no longer just targeting guests. They are infiltrating hospitality systems themselves, turning trusted platforms into vectors for fraud." — Malwarebytes, June 2025
In Robert Woodford's case, reported by Malwarebytes in June 2025, the fraudulent payment link appeared inside his authentic Booking.com message thread. The URL contained the word "bookingcom." Everything looked legitimate because it was routed through a channel the attackers had already compromised. He only discovered the fraud after the payment cleared, when he noticed the merchant name didn't match. By then, it was too late.
This is the core innovation of the campaign: the exploitation of inherited trust. Understanding it is the prerequisite for understanding everything else that follows.
Stage One: Getting Inside the Hotel
The first phase of the attack targets hotel staff directly. Microsoft Threat Intelligence, which began tracking the campaign in December 2024 under the designation Storm-1865, documented how hotel employees receive convincing emails appearing to come from Booking.com. The content varies deliberately — sometimes it's a notification about a negative guest review requiring a response, sometimes a request from a prospective guest, sometimes an account verification prompt, sometimes a promotional opportunity. The variety is intentional: it reduces the chance that any single email template triggers widespread recognition as a scam.
The email contains either a link or a PDF attachment that ostensibly leads to the Booking.com platform. When the recipient clicks, they are redirected through attacker-controlled infrastructure to a fake CAPTCHA verification page — one carefully designed to look like a Booking.com administrative interface, complete with branding and URL patterns that include words like "admin" and "extranet" to reinforce the illusion of legitimacy.
This is where ClickFix enters. The fake CAPTCHA page doesn't verify the user's identity — it delivers a command to their clipboard using JavaScript's navigator.clipboard.writeText() API. The page then instructs the user to open a Windows Run dialog using Win+R and paste what they believe is a verification code. What they're actually pasting is a malicious command that runs through mshta.exe — a legitimate Microsoft utility — and downloads malware.
Because the victim executes the malicious command manually, the browser sees a normal clipboard event and the endpoint detection system sees a user opening a system dialog. Neither fires an alert. The attack exploits the gap between what security tools monitor — automated processes — and what they can't monitor without generating thousands of false positives: normal-looking human behavior.
Microsoft's March 2025 report identified multiple malware families deployed in the Storm-1865 campaign, including XWorm, Lumma Stealer, VenomRAT, AsyncRAT, Danabot, and NetSupport RAT — all of which share one capability: stealing financial data and credentials. The specific payload varied by target, with some samples delivering PowerShell, others JavaScript, and others portable executable content. The payload diversity makes signature-based detection unreliable.
Sekoia's Threat Detection and Response team, analyzing a related campaign they named "I Paid Twice" that became active by at least April 2025, found that the primary payload had shifted to PureRAT — a more capable and persistent remote access trojan. The redirection infrastructure used URLs following the pattern hxxps://{randomname}[.]com/[a-z0-9]{4}, cycling through randomized domains to evade blocklists. The ZIP archive containing the malware was consistently named updserc.zip, providing one of the few reliable indicators of compromise across variants.
"The attacker's modus operandi involved using a compromised email account to send malicious messages to multiple hotel establishments." — Sekoia Threat Detection & Response, November 2025
A critical detail in Sekoia's analysis: in many cases, the phishing emails were sent not from spoofed addresses but from already-compromised legitimate corporate email accounts. Attackers had compromised earlier victims and were using their authentic accounts to target new ones. This creates a chain of infections where each compromised hotel becomes a launch platform for the next campaign cycle.
Stage Two: Turning Hotels Against Their Guests
Once hotel staff credentials are stolen and the attackers control the hotel's Booking.com extranet account, the operation shifts target. The hotel is no longer the victim — it becomes the weapon.
With access to the booking platform's administrative interface, attackers have everything they need: guest names, reservation details, check-in and check-out dates, email addresses, and in some cases phone numbers. This data is extraordinarily valuable because it enables highly targeted, contextually authentic fraud. A message arriving through the Booking.com platform, referencing your actual reservation ID and your upcoming stay, doesn't trigger the usual skepticism that generic phishing does.
Guests received messages — via email or WhatsApp — informing them of a supposed payment issue with their existing reservation. The framing varied: sometimes it was a card verification failure, sometimes a platform security update requiring payment confirmation, sometimes a warning that the reservation would be cancelled unless payment was re-confirmed. In each case, a link directed the guest to a fraudulent page mimicking Booking.com or Expedia's billing interface, where they were prompted to enter their card details.
Sekoia named their research "I Paid Twice" after the subject line of a defrauded customer's complaint email. Their assessment, stated with high confidence: the victim paid for their reservation once at the hotel through the legitimate platform, and once again to the criminals through the fraudulent page. Across Europe, Asia, and North America, the scheme repeated at scale.
Booking.com confirmed to Infosecurity Magazine in March 2025 that its own systems were not breached. The company stated that the attacks affected "a small fraction" of its partner properties and committed to educating partners and customers. The attacks succeeded not by defeating the platform's security but by exploiting the legitimate access of compromised partner accounts.
What makes the guest-targeting phase particularly insidious is its resistance to the standard advice of "check if you're on the real website." When the fraudulent payment link appears inside an authenticated Booking.com message thread — as it did in Robert Woodford's case — the normal verification heuristics fail. The URL can contain the platform's name. The context is real. The reservation data is accurate. The only tell is the merchant name on the payment confirmation, which many users don't scrutinize in the moment.
The Malware Behind the Curtain: PureRAT
The Sekoia "I Paid Twice" campaign introduced PureRAT — also known as PureHVNC and ResolverRAT — as the primary payload for compromising hotel systems. Understanding PureRAT's capabilities explains why the attackers invest heavily in deploying it rather than simpler credential stealers.
PureRAT is sold as Malware-as-a-Service by its developer, operating under the alias PureCoder, with distribution reportedly beginning in March 2021. It is available for purchase via Telegram bots, automating and anonymizing the acquisition process. The malware's design reflects professional software engineering — it is modular, meaning the core binary can fetch and load additional plugins to extend capabilities based on what the operator needs for a specific target.
Its base capabilities are extensive: remote desktop access (VNC-style), full mouse and keyboard control, webcam and microphone capture, keylogging, file upload and download, network traffic proxying, data exfiltration, and remote execution of arbitrary commands or binaries. The malware communicates with its command-and-control servers over TLS-encrypted connections primarily on ports 56001, 56002, and 56003, making traffic analysis harder. Upon establishing a connection, it sends system fingerprints to the C2 server: hostname, operating system, installed antivirus software, and a screenshot of the current screen state.
The deployment method Sekoia documented is particularly sophisticated. PureRAT uses reflective loading via AddInProcess32.exe — a legitimate .NET utility — to execute entirely in memory without writing files to disk. This fileless execution technique sidesteps traditional signature-based antivirus detection, which relies on scanning files on disk. The malware is further protected by .NET Reactor, a commercial code obfuscation and protection tool that prevents static analysis and reverse engineering.
# Anomalous indicators defenders can monitor:
# 1. AddInProcess32.exe spawned from unexpected parent (AppData directory)
# 2. Unsigned DLLs loading from AppData paths
# 3. TCP connections on ports 56001-56003 to unknown external IPs
# 4. PowerShell downloading ZIP archives from HTTP endpoints
# 5. Registry Run key creation following PowerShell executionSekoia's detection guidance specifically calls out AddInProcess32.exe behavior as a strong anomaly indicator: the process is normally launched by legitimate applications like Microsoft Office, not from the AppData directory following a PowerShell download sequence. For security teams with robust endpoint monitoring, this process chain is one of the more reliable signals that PureRAT is present on a system.
The Underground Economy Fueling It All
What transforms this from a notable attack campaign into a systemic threat is the industrialized criminal marketplace that has developed around it. Sekoia's investigation didn't just map the malware — it exposed a fully operational underground economy built specifically around exploiting the hospitality sector.
On Russian-speaking cybercrime forums including LolzTeam, Exploit.in, and WWHClub, Booking.com extranet credentials are openly traded as commodities. Prices are not flat — they are tiered based on account value. A compromised account managing a single small property might sell for as little as $30. An account with administrator access to multiple hotels in a developed country, with a high volume of active reservations and Genius partner tier status, can command several thousand dollars. The logic mirrors any other financial marketplace: the higher the potential yield from exploitation, the higher the purchase price.
"Booking.com extranet accounts play a crucial role in fraudulent schemes targeting the hospitality industry. Consequently, data harvested from these accounts has become a lucrative commodity, regularly offered for sale in illicit marketplaces." — Sekoia Threat Detection & Response
Credentials aren't sold as raw dumps. They go through a verification step first. Log checker tools — available on the same forums for as little as $40 — authenticate compromised accounts via proxies to confirm the credentials are still active before purchase. This quality-control layer reduces wasted spend for buyers and gives sellers a justification for their price points.
Beyond credential trading, the ecosystem includes a network of "traffers" — specialized distributors who drive infected traffic from social media and search results toward the malware delivery infrastructure. These are not the same actors writing the malware or running the fraud; they are a separate layer in the supply chain, paid per successful infection. Their specialization in the hospitality sector makes them a smaller, more closed community than traffers targeting broader audiences, according to Sekoia's assessment.
One threat actor operating under the alias moderator_booking advertised their services openly on these forums, claiming their team had collectively earned over $20 million from this fraud model. Their service purchased Booking.com logs — bundles of credentials, session cookies, and system data harvested by infostealers — at prices from $30 to $5,000. The service was sufficiently profitable that the same actor expanded operations to include Expedia, Airbnb, and Agoda accounts, extending the identical fraud model across the major online travel platforms.
BlueVoyant's analysis in December 2025 added another dimension to the infrastructure picture: the use of Steam Community profiles as command-and-control dead drops. By embedding C2 server addresses inside ordinary Steam profile pages, the attackers create a dynamically updatable infrastructure layer that doesn't require modifying the malware binary itself. When a C2 IP address gets blocked or burned, the attackers update the Steam profile page and all active malware installations automatically discover the new address. Steam's traffic is trusted by most firewalls, making this channel particularly difficult to block without also blocking the gaming platform entirely.
BlueVoyant tracked more than 1,500 malicious domains across the campaign's infrastructure from late August through December 2025. The domain strategy was deliberately disposable: over 1,300 were active for fewer than 30 days, and more than 1,000 for fewer than nine days. A smaller subset of around 140 domains remained active for more than 60 days — these longer-lived domains appear to function as core redirectors or payload servers, the stable backbone beneath the constantly churning disposable layer. Domain naming followed predictable brand-impersonation patterns: verifycard[number]-booking[.]com, confirmation-id[number][.]com, guestverify[number]-booking[.]com.
How the Campaign Kept Evolving
One of the clearest signs of a sophisticated, resourced threat actor is the ability to adapt when defenders respond. This campaign has done exactly that across more than a year of active operation.
The Storm-1865 activity Microsoft documented in its March 2025 report — covering campaigns active since December 2024 — used ClickFix as its primary social engineering mechanism. The "I Paid Twice" campaign Sekoia analyzed from April 2025 onward shared the ClickFix delivery method but shifted to PureRAT as the primary payload, added a commercial Traffic Distribution System as a protective layer between victims and the actual malware infrastructure, and refined the guest-targeting phase to use authentic reservation data for higher-fidelity fraud.
By December 2025, BlueVoyant documented the use of FileFix in this campaign — a variant of the social engineering prompt, first identified by researchers in mid-2025, that manipulates users into executing malicious commands through Windows File Explorer rather than the Run dialog. The behavioral change is designed to defeat defenses that had been deployed specifically against the ClickFix pattern, such as controls blocking mshta.exe execution or restricting the Windows Run command. The underlying trick is identical; only the interface the victim is shown has changed.
In December 2025, BlueVoyant also observed the deployment of CastleRAT as an alternative payload — a malware variant attributed to the Transient Marauder / GrayBravo Cluster 3 threat group, which BlueVoyant assesses with high confidence to be part of the same activity cluster as Microsoft's Storm-1865.
In early January 2026, Securonix published research on yet another variant detected in late December 2025, tracking activity they designated PHALT#BLYX targeting European hotels. This version added a fake Blue Screen of Death page as an intermediate step — after the phishing email, the victim sees a convincing BSOD with "recovery instructions" prompting them to open the Run dialog and paste a command. The payload in this variant was DCRat, a different remote access trojan linked to Russian-speaking developers, suggesting that multiple operators are now running similar campaigns with the same general architecture but different tooling.
In mid-February 2026, Bridewell's threat intelligence team published research on a further evolved variant active since early January 2026, tracking it as intrusion set BR-UNC-030. This iteration uses homograph attacks — swapping Cyrillic characters into URLs to create near-identical-looking domain names — and a newly developed partner-focused phishing kit distinct from the tools used in earlier waves. Code comments inside the phishing kit contained the Russian word for "Error," providing a language signal about the developer's origin. The infrastructure associated with the earlier "I Paid Twice" TDS appears to have been retired, replaced by this new dedicated kit.
"These attacks require a moderate level of sophistication on behalf of the user. If you are too tech non-savvy you may be confused by these messages and not be able to complete the task, whereas if you are very sophisticated you are likely to smell a rat." — Chet Wisniewski, Director and Global Field CTO, Sophos
Wisniewski's observation captures an important limitation of this attack class: it depends on a target who is knowledgeable enough to follow the technical steps involved in a ClickFix prompt, but not suspicious enough to question why a legitimate platform would ask them to open a Run dialog and paste a command. Hotel operations staff often fit that profile exactly — comfortable with computer systems, accustomed to following software prompts, and working under time pressure during busy booking periods.
What Actually Stops This
The attack's design specifically exploits the gaps between technical security controls and human behavior, which means an effective defense requires addressing both layers simultaneously. Technical controls alone are insufficient — every documented variant has found a way around them. Awareness training alone is also insufficient — the social engineering is refined enough to deceive even vigilant users who are looking for suspicious activity.
For hotel operators and hospitality businesses, the highest-leverage controls are:
Remove local administrator rights from front-line staff workstations. The ClickFix and FileFix techniques depend on the victim being able to run arbitrary commands that download and execute software. If the account running the command lacks the privileges to install software or write to sensitive directories, the payload download may fail or the malware may fail to establish persistence. James Maude, Field CTO at BeyondTrust, put it directly: "The fewer privileges the user holds, including the ability to launch unknown applications, the less risk there is."
Implement application control to restrict PowerShell and mshta.exe usage for non-administrative accounts. Both are legitimate system utilities that appear throughout these attack chains. Restricting their execution to administrative contexts removes the primary delivery mechanism without breaking legitimate workflows for non-technical staff.
Deploy endpoint detection rules specifically for the behavioral indicators PureRAT leaves behind: AddInProcess32.exe launching from AppData parent processes, unsigned DLLs loading from AppData paths, and TCP connections to external IPs on ports 56001–56003. These patterns don't appear in normal hotel operations workflows.
Enforce multi-factor authentication on all Booking.com partner accounts and any OTA administrative access. Credential theft through infostealers extracts session cookies and stored credentials from browsers — but if MFA is required for new sessions from unrecognized devices, a stolen credential alone isn't sufficient to access the account. MFA doesn't make the credential worthless, but it significantly increases the operational cost for attackers.
Monitor the Booking.com extranet for anomalous activity — unexpected logins from new locations, bulk message sends to guests, or changes to payment information outside of normal operational patterns. The platform's legitimate activity has predictable rhythms; deviations are detectable if someone is looking.
For guests, the critical insight is that the normal verification heuristics have been deliberately defeated. The correct URL, a verified message thread, and accurate reservation data are no longer reliable signals that a payment request is legitimate. The safest practice is to treat any payment request that arrives via messaging — even within an authenticated platform — as potentially fraudulent, and to verify it through a separate channel: call the hotel directly using a phone number from the official website, not one provided in the message.
No legitimate booking platform, hotel, or payment processor will ever ask you to verify a payment by running a command you copied from a web page. If a page asks you to open Run, Terminal, or File Explorer and paste something, close the tab. The same principle applies to unsolicited payment requests inside messaging platforms, regardless of how legitimate the surrounding context appears.
Sekoia's assessment is unambiguous: as long as infostealer malware and stolen credentials remain cheap and accessible, the economics of this fraud model remain favorable for attackers. A compromised hotel extranet account is worth between $30 and $5,000 on the criminal market. The fraud perpetrated against guests using that account can return multiples of that investment. The infrastructure is disposable and fast-cycling. The social engineering is continuously refined against defender responses.
This campaign is not a one-time incident. It is a persistent, profitable criminal enterprise operating against an industry that handles enormous volumes of payment data and whose operational staff are not primarily security-focused. It will continue until the economics change — which requires either making credential theft significantly harder, making extranet account access require higher-assurance authentication, or making the guest-targeting phase fail reliably. None of those outcomes happen automatically. They require deliberate action from platforms, operators, and the security community working together.
Robert Woodford did everything right by the conventional standard: he went directly to the platform instead of clicking a link. He still lost money. That's the measure of how well this operation is designed, and why it deserves more than routine awareness. It deserves a structural response.
Sources: Microsoft Security Blog, "Phishing campaign impersonates Booking.com, delivers a suite of credential-stealing malware" (March 13, 2025); Sekoia Threat Detection & Response, "Phishing Campaigns 'I Paid Twice' Targeting Booking.com Hotels and Customers" (November 6, 2025); BlueVoyant Threat Fusion Cell, "'Tis the Season for Attacks Spoofing Booking.com" (December 11, 2025); Recorded Future Insikt Group, "GrayBravo's CastleLoader Activity Clusters Target Multiple Industries" (December 9, 2025); Securonix, "Analyzing PHALT#BLYX" campaign research (January 6, 2026); Bridewell, "The Booking.com Phishing Campaign Targeting Hotels and Customers" (February 2026); Malwarebytes, "Booking.com abused by cybercriminals to steal from travelers" (June 6, 2025); Dark Reading, "Threat Actor Uses Booking.com in ClickFix Phishing Scheme" (March 14, 2025); Infosecurity Magazine, "'I Paid Twice' Phishing Campaign Targets Booking.com" (November 6, 2025); The Hacker News, "Large-Scale ClickFix Phishing Attacks Target Hotel Systems with PureRAT Malware" (November 10, 2025); Jamaica Cyber Incident Response Team national advisory on PureRAT hospitality campaign.