The rise of phishing in the hotel sector: what our investigation found
An analysis of the phishing campaigns now affecting the hotel sector, in which attackers approach guests using the real details of their booking. We explain how they operate, why the hotel remains the data controller under the GDPR even when the leak comes from a provider, and how to confirm where the information actually came from.

What's happening
Over the past few weeks we have investigated several phishing campaigns aimed at the guests of hotels we work with, reverse-engineering the infrastructure the attackers rely on. What we found is not an isolated incident but an organised operation that repeats itself from one hotel to the next and has grown considerably more sophisticated over time.
Unlike the generic fraudulent email we had grown used to, in these campaigns the attacker approaches the guest directly over WhatsApp or SMS using the real details of their booking, such as their name, the dates of their stay, the confirmation number or the amount they have paid. With all of that information in front of them, the guest is asked to confirm or verify the payment through a link, and because everything they read matches their genuine booking, they trust the message and end up entering their card details on a fraudulent website.
The two images below show how the deception unfolds. First comes the message the guest receives and then the fake payment page that the link leads to.


Why it is so effective
This fraud is so effective because the message does not look like a scam. It arrives accompanied by information that, in principle, should be held only by the hotel, and that coincidence alone is enough to disarm the guest's natural caution. If the attacker holds those details, it is because the booking information has ended up leaking somewhere along its journey, and any leak of personal data amounts, by definition, to a security breach with all the legal obligations that entails.
The scale of the attack
It is worth understanding that none of this is the work of an amateur or a one-off episode. Behind it lies an industrial phishing-as-a-service operation, run by a specialised group that the security community tracks under the name GrayBravo, which makes its infrastructure available to third parties and renews it constantly. Our investigation, cross-checked against the publicly available information, makes it possible to gauge the true reach of the campaign, both globally and in Spain.
| Indicator | Figure |
|---|---|
| Fake domains documented since January 2025 | more than 4,300 |
| Kit domains active in July 2026 | 90 |
| Hotels targeted worldwide (estimated) | more than 10,000 |
| Targets catalogued in this investigation | 265 |
| Spanish hotels identified in the infrastructure | more than 15 |
| Confirmed targeted victims | 8 |
| Languages supported by the kit | 43 |
| Average lifespan of each fake website | 24 to 72 hours |
The figure that best explains why it is so hard to stamp out is the last one. Each fraudulent website lives only a few hours before it is blocked, and fresh domains appear in its place every day, so the campaign stays continuously active and slips past traditional blocklists. The fact that more than fifteen Spanish hotels have been identified within the infrastructure also confirms that this is not a distant problem but a threat already operating in our own market.
The temptation to point at the provider
When a case like this comes to light, the most immediate reaction is to turn to the booking engine or the channel manager and wait for them to confirm or rule out that the problem lies on their side. Asking is entirely reasonable, and we have done so ourselves, but it would be a mistake to treat the matter as settled on the strength of that answer alone, for two reasons.
The first is that there is no single, obvious culprit. Affected hotels work with different providers, and a booking's data passes through many hands before a stay is completed, from the hotel's own email to the channel manager, the PMS, the CRM, the check-in tool or the files exported along the way. The leak may have occurred at any of those links in the chain, and an infected computer at the front desk within the hotel itself cannot be ruled out.
The second is that a provider reviewing its logs and finding nothing is not the same as a guarantee that the information did not leave its systems. It is common, and perfectly legitimate, for a provider to examine its access records in good faith and report that it has detected no intrusion, but that check does not close the matter for the hotel, because before the data protection authority it is still the hotel that answers for its guests' data.
The hotel is the controller, even when the leak comes from a third party
There is one point that is often overlooked and worth keeping in mind. Under the General Data Protection Regulation, the controller of the guests' data is the hotel. A booking engine or a PMS act as processors that handle that information on the hotel's behalf, but the duty to respond to an incident rests with the hotel and cannot be delegated to third parties.
In practical terms, this means that as soon as there are signs that personal data has leaked, and a guest receiving a message that quotes their correct confirmation number is one such sign, the hotel must notify the breach to the supervisory authority within 72 hours of becoming aware of it. It is not necessary to have fully resolved the incident before taking that step, since the regulation itself provides for a preliminary notification setting out what is known so far together with the analysis that will be carried out afterwards, which can later be expanded as the investigation progresses. Where payment data is also involved, the risk to the guest is high, so the hotel will need to consider informing the affected guests directly and to document each of its decisions carefully.
Being a victim of the attack does not exempt the hotel from any of these obligations. What the authority values is not whether the hotel was attacked, but the diligence with which it detects, contains and communicates the incident.
Confirming the origin rather than merely suspecting it
There is a considerable difference between claiming that the origin most probably does not lie with the hotel and being able to demonstrate, with evidence, where the information actually came from. Only the latter position offers genuine peace of mind, and only it supports a solid defence before the data protection authority, and reaching it is more attainable than is usually assumed, without calling for any large technical deployment.
At the hotels we work with, we can put in place, with hardly any complexity, the tools needed to carry out that forensic analysis. With them it becomes possible to check whether the front-desk and reservations computers are infected with any credential-stealing software, to review the access records and forwarding rules configured on the email accounts and to reconstruct the path the data followed until it reached the attacker. It is worth stressing that running an antivirus is not enough, since this kind of software is designed precisely to operate without being detected by it, and what is required is a rigorous analysis that makes it possible to state, with proof in hand, whether the breach lies inside the hotel or with a third party.
What should be done
Regardless of where the origin ultimately turns out to be, there are a number of measures that should be taken as soon as possible:
- Change the passwords for every booking extranet (Booking, Expedia, Agoda and any others) from a device known to be clean, and enable two-step verification on each of them.
- Warn guests with upcoming stays and remind them that the hotel will never ask for their card details over WhatsApp or through a link, so that they can recognise the fraud if they receive it.
- Isolate and examine any device on which a suspicious file may have been opened before it is used again.
- Notify the breach to the supervisory authority, even if only on a preliminary basis, weigh the option of informing those affected, and keep a documentary record of the whole process.
- Launch an analysis that makes it possible to confirm the origin of the leak rather than settling for suspicion, which is the only way to close the incident with any certainty.
Next step
Need to confirm whether the breach is in your hotel?
At Dasenda we help you analyse the hotel's machines and systems, trace where the leak came from and prepare your response to the data protection authority with evidence rather than guesswork.
Talk to Dasenda