Uninvited Guests
In March I booked a Parisian hotel through the Booking.com app.
Everything seemed normal until I received two pieces of media — a message from the hotel I booked with and an email, from the same hotel, sent to my personal email address.
My curiosity was sparked.
What I thought would be a simple phishing attempt turned out to be something much bigger and far worse.
I "lost" €85 personally to this scam, and a detail I still find amusing is that my money never went to the scammers — it went to Booking.com's holding account. I also never got my money back. Not because it would have been too difficult but simply because I didn’t care enough.
In this blogpost I take you, the reader, on my journey. On y va!
Let's start with the information I had when my investigation began:
An alarming message in my Booking.com app.
A suspicious gmx.de address.
One hyperlink pointing to an online location.
To get all three datapoints, I simply followed the trail that got laid out for me.
The message told me to send an email to the domain included in that same message, containing the [Guest name] + [Reservation ID] + [Number of guests].
After doing this, my mail inbox very quickly received a follow-up message which tried to lure me to an internet address.
Going to that address, I saw this webpage asked for banking information: card numbers, CVVs, credentials — the site asked for everything.
This was the first red flag. Everything before this had a plausible explanation; this did not. And yet the page looked completely legitimate. It carried two SSL certificates — one a free Let's Encrypt cert (valid for the standard 90 days) and one from Sectigo — both active on the domain, so the browser naively showed it as secure. On top of that the domain was only a few days old when I first landed on it — it wasn't until about two days after my initial visit that most browsers started flagging it as unsafe.
The infrastructure itself was airtight. Everything sat behind a Cloudflare proxy, so the origin server stayed hidden, WHOIS was anonymised, Shodan returned nothing, and DNS gave me nothing useful. Every standard angle came up empty, and some non-standard ones did too, like favicon hash enumeration — both in my browser and with specialised tools.
Purely out of curiosity I started guessing subdomains by hand, and simply putting "admin" in front of the domain actually landed me somewhere real: a live admin subdomain, which sadly did not show any useful information either. To be clear here — the subdomain did exist, but I could not extract anything from it that would help.
While the domain was still live, I had a friend cold-contact the scam email address from his own Proton account. A little while later he got a reply identical to mine, and was funnelled to a brand-new domain set up the exact same way as the one I'd been served. This looked like automation.
At this stage I had a webpage that had revealed some of its setup but none of its operators, an email address that was being used by the scammers themselves, and a case that had gone from curious to genuinely strange. Usually phishing domains reveal more — This one didn’t.
But let’s consider this: had the domain leaked important information, then a reasonable assumption to make is that the operators were amateurs or at least not doing a good job. The inverse of that assumption holds true, too. So where do we go from here? Remember, we have more than just the phishing site.
I pivoted to the email I still had and pulled its raw headers to take a close look. Again, nothing to find. The sender IP was a VPN IP belonging to a company in Cyprus with an exit node in Paris [a server in Paris — could this be deliberate?] and the email was routed through GMX servers. Another dead end, I thought.
However, there had to be an account that managed this address. Why not take a look at that and see how far we can get?
I headed to gmx.com and tried to access the account tied to the email address. Entering wrong credentials and then clicking the reset-password option showed the account's recovery details — and among them was a phone number: +491*******928. We were still missing some important information and the phone number was never shown completely to me, but this was something real.
So now we had an email header that revealed nothing identifying, just like the webpage. I did, however, find something personal tied to the bad actors. This phone number would not be important for the rest of the case, but to me it was huge — proof that persistence and a bit of creative thinking can still turn something up. After this, I kept going back and forth between the webpage and email header for a few days, desperately trying to find anything I might have missed, but to no avail. So where should I look, I thought. The answer came when I considered all the involved parties. There was me, other victims (most likely), the bad actors and… the hotel!
Now I started searching online for anything I could find about the hotel.
The first results were about its finances — the hotel took a heavy hit during the coronavirus lockdowns and, by the look of it, never fully recovered. To many this might seem like an irrelevant datapoint, but remember — we are still trying to work out the why behind this whole case, and a struggling hotel scamming its own customers with the help of third parties isn't entirely unthinkable.
After exhausting the easy-to-find information, my searches grew more targeted, and eventually I came across a site called IntelX. It hosts a vast archive of files scraped from both the clearnet and the dark web.
I typed the hotel's public email address — the one listed on their website — into IntelX's search bar and got back dozens of files, each referencing that address in some way. This turned out to be a critical part of my investigation and, dare I say, probably the most valuable find overall. There was one catch, though: IntelX won't show you the contents of these files without a paid account.
So my next step was to write to IntelX directly, explaining what had happened to me, what I was doing, what I already had, and how I believed they could help. I kept everything sanitised, as good etiquette demands.
One day later, an email from them landed in my inbox informing me that I'd been given a full professional account, free, for two whole weeks. I could now read the contents of every single stealer log.
When I started reading through them, my jaw dropped.
Usernames, passwords and other data, all exposed. And the worst part: this stretched back to at least 2019 — the upload date of the oldest log listing the hotel's own address, and its password!
(Passwords aren’t always shown in full and are often hashed. This means you won’t find the true password on IntelX but you can bet good money on it that the real credentials have been passed around on the more shady parts of the internet)
So now the picture was getting a lot clearer. Credentials directly tied to the hotel had been circulating in stealer logs for years. The hotel's own email credentials showed up directly, alongside those of more or less random people who had online contact with the hotel in some way at some point.
This made me question my earlier narrative. Was the hotel in on it, or were they simply unlucky enough to be compromised? I landed on the latter. It made no sense for a struggling hotel to pull a Hail Mary and nuke its reputation and its ties with Booking.com for a quick payday. Far more likely, they were an easy target with weak security who had been showing up on threat actors' radar for years.
I also got an idea. So far, my entire investigation had been happening online with me sitting behind a screen. To really find out more, I thought, I should go to the hotel. They would know what really happened to them and more importantly: any valuable evidence would be sitting on one of their systems.
Some French laws and European regulations made acquiring any evidence seriously hard and handling the evidence would be very tricky, if I’d even get that far.
Reading up on infostealer malware, one thing became clear — this is a business more than it is a technical domain. A good infostealer is a crafty little program and it's not something you "just" make, but the marketplace for this software and the content they extract outshines the technical aspects.
Since in the files hosted on IntelX there were constant mentions of Telegram groups, I decided to see if I could gain any information from those places. Quite quickly I realised this wasn't the case and went back to the infostealer family lead. See, there are tons of stealers going around but the attack/scam that occurred was set up and executed very well. The bad actors weren't amateurs so it would make no sense for them to use subpar software. That is, though, if they even infected the hotel themselves. There were two possibilities: either the scammers infected the hotel or they bought access to the hotel's systems. Considering the OPSEC my adversaries maintained so far coupled with my heavy suspicion that they abused legitimate hotel software (the Booking.com portal, client side) I reasoned that they infected the hotel themselves, or at least one — or a few — of their apps. This heavily suggested the use of a RAT since it grants persistence and, for a multi-step attack process, you'd want monitoring capabilities rather than a one-and-done info steal.
Lastly, all leaked data I found was for mail accounts.
(Because the attack heavily relied on access to the hotel’s booking.com portal, I reasoned that the adversaries must have used software that granted them full control. Though an infostealer can technically grant such access by simply extending the login information to the person wanting to get in, a password reset would have been devastating to the scam campaign. Now, if you have something running on a remote system that lets you act on it as the owner, a password reset is no longer catastrophic but just annoying at worst)
The end of my investigation was coming in sight by now. I had looked at every datapoint available to me and graphed them all in Maltego to visualise the connections between them.
The scammers operated a phishing domain and an email address, and had access — somehow — to the hotel's Booking.com portal. I knew the way the scam worked: let customers pay Booking.com first for their reservation, and then get them to hand over their financial information on the scam page.
They not only set up a well planned process but also abused human psychology to get "paid".
One thing I could never pin down was where, or who, these bad actors actually were. The signs leaned German — the GMX account was set to German (Though this could have been a coincidence or a fluke), GMX itself is a German provider, and the phone number was German too — but I could never make anything certain. The infrastructure was scattered across several countries: my own — since I was a victim, France, Germany, Cyprus, and even the US, since Cloudflare was such a big part of the setup. Attribution is a bitch, and sometimes having more data means it becomes harder.
While I knew a lot already, I wanted to get my hands dirty and do the technical work. This meant imaging a system from the hotel.
I hit up some connections in the cybersecurity industry who explained how to do it, and then learned more through some online sources.
Then the moment came.
I loaded my bag with a 2TB SSD, a USB containing software to write data to the SSD, my laptops and any other hardware I might need and set off for Paris.
Once there, I rehearsed the technical methods to make sure I was well prepared and practised what I'd say to hotel staff so that, even if things didn't go as planned, I wouldn’t be screwed. The goal here was to conclude my investigation, not scare off the people I wanted to help.
Walking up to the hotel, I saw an employee smoking at the entrance, said hello and asked if I could use the toilet (not as a clever way of scoping out the hotel — I actually had to use the toilet). He asked if I had a reservation and I told him I did. Once I came back, I immediately told the employee, who was now sitting behind the desk, that I technically did have a reservation but that it was weeks ago.
Then I followed up by quickly stating that I was a student, focused on cybersecurity, and had investigated this case solo. Just as important, I made clear that I did not want my money back, nor any payment for the help I would be offering the hotel.
Luck was on my side and the clerk engaged with me in what would turn out to be a 1.5-hour back-and-forth.
I was cautious not to share any hard details, but I noticed that giving bits and pieces meant the clerk would eagerly share information I needed.
By the end I knew:
The hotel PC that employees work on runs Windows 10 (which has been EOL for a good while now. It still receives security updates but the exact way the system was setup and used was not known to me; thus I filed it as a security issue).
The guests and staff both use the same network (No explanation needed here)
The hotel had been receiving emails — automatically filed into spam — from a gmx address for a while before the attack went live (So the attackers relied on GMX)
There were hundreds of victims. People who booked, same as I did, and who were all sent an email — from the real hotel this time; trust me, I checked — saying their reservation was cancelled because the hotel was supposedly already fully booked.
A ton of people, several dozens of them, showed up on consecutive days in front of the hotel, uninvited.
The hotel stated in an email to me that they saw 53,000 fraudulently listed bookings appear online. The front desk employee confirmed it.
Multiple hotels in Paris got hit at the same time, in the same way, with the same outcome (a newspaper article confirmed this).
During the attack, staff tried deleting fake Booking.com listings in the portal but any they deleted would be back up within minutes. I was also told it took Booking.com several days to stop the attack, and they opted to Hiroshima and Nagasaki the hotel by first deleting every single booking — fraudulent or legit — and then breaking ties with the hotel (so the hotel couldn't stop the attack, and Booking.com's final option, as they evidently saw it, was to kill everything).
I had no reason to doubt the clerk's stories and information as it was all told in a coherent way and never contradicted anything. Besides, it's beyond unlikely for this individual to have been involved in any deliberately malicious way since multiple hotels were hit by the scam-campaign — either the other hotels all had compromised staff or not. A one-off case of a compromised individual aiding the attackers was a dubious assumption to make here.
After this visit I headed home.
I returned with more information to work with, but did not get the image, nor was I able to speak with the owners. At first this was considered a failure by me but realistically speaking, the only thing I didn't get my hands on was a system's image. It was still possible to deduce what happened, accurately enough, by going over the data. You'd never get a 100% accurate answer this way — but for a solo, private investigation this was still a good outcome in my opinion. (I knew only the hotel owner could grant me permission to image their systems and without him being there that day, I simply did not want to put anyone in an awkward position)
What I concluded was as follows:
The bad actors first target specific hotels that aren't managed by a parent company but are run privately — every hotel that got hit had this one thing in common — then they infect those hotels with malicious code, most likely a RAT, deployed through phishing emails.
An infostealer was still technically possible, but I leaned towards a RAT. The stealer logs explained how the hotel's credentials first leaked, yet the way deleted listings kept reappearing within minutes pointed to live, hands-on access — and that, combined with the technical prowess, the persistence, and the multi-stage setup and execution of the whole campaign, made me go with the RAT.
After gaining access to a hotel, the attackers move on to the Booking.com portal, create fraudulent bookings and launch them.
Having observed how quickly I received that first message and email — and the fact that the attackers owned multiple domains, each identical to the others — I reasoned that they relied on automation.
As the attack runs, victims first pay Booking.com, get redirected to a webpage designed to steal their financial information, and ultimately end up with an empty bank account.
While this is going on, the hotel can only watch. Any attempt to stop the attack gets undone within minutes — perhaps another sign of automation, or of someone monitoring live.
The only thing that seemed able to stop the campaign, apparently, was Booking.com itself and their scorched earth approach.
This concluded my investigation. The writeup already lived in my head and I was fighting to get the first words onto paper when I stumbled on an article from Sekoia called "I paid twice." Worth being clear on the timing: I'd reached my conclusions before I ever opened their piece — but my god, it was a massive help because now I knew I had reasoned right along the way.
And we landed on the same end-to-end picture of how this scam works, start to finish. The difference is how we got there. Sekoia had SOC telemetry and actual malware samples to work from — the kind of access I was never going to get as one person poking at a live domain from the outside. I came at it from the opposite end: a victim's-eye view, stealer logs dug out of IntelX, a partial phone number lifted from a password-reset page, and a 1.5-hour conversation with a clerk in a Paris hotel lobby. Two completely different vantage points, same conclusion.
I look back fondly at this adventure. “Paying” €85 for all of this is money well wasted to me.
A special thanks goes to my friend who helped me during parts of the investigation and offered great advice, worked with me until deep in the night and let me crash on his extremely comfortable couch;)
Lastly, I want to thank IntelX for their indirect help.
I’d have never expected to get that free account and at the time it meant my investigation stayed alive when every other angle turned into a dead-end.