The email

I received my sample email(s) from someone who had recently booked a stay with a specific Austrian Hotel (Hi5-Hotel) through Booking.com. At a later point (2025-06-01) they received a notification from Booking.com about the need to provide additional information, otherwise their stay would be cancelled, with the hotel being named as the sender.

Reviewing the mail itself it looked technically clean, actually coming from a Booking.com subdomain & passing SPF. I will not even include any IOCs for the email itself here as I am rather certain this is, technically, a legitimate email.

The link in the body, however, was highly suspicious: https://hi5XXXX.gstlly.com/ (with XXXX being four random lowercase alphabetic characters). By the time my recipient interacted with that email (2025-06-02) the specific domain had already been flagged as malicious in a security product in use by the recipient, so no damage was done in this case.

Booking.com partner compromises

Booking.com has a problem: It partners with millions of properties. This makes it a certainty that a good number of their partners will have security incidents on a regular basis. While Booking.coms infrastructure is likely not at significant risk from this their customers are: Enterprising attackers can compromise the Booking.com accounts of partners, steal customers data, and send notifications to customers using legitimate notification channels.

I am rather certain this is also what happened in this case, given we had a technically clean email, knowledge about the hotel this person was staying at & the correct dates.

This unfortunately makes recipient-side filtering... is rather tricky, not that I think it should be on the recipient, this is on you, Booking.com.

The website

One thing I found initially fascinating is the URL/Link provided in the email (https[://]hi5XXXX.gstlly[.]com/): No, there was nothing missing there. It just is / as the path, no parameters, no nothing. Yet when following the site (in a sandbox) it prefilled the recipients data. This means: There are individual domain names for individual targets! I have no idea why, tbh. My first theory was that this allows for identifying ... delivery or analysis based on DNS queries, even if parameters get stripped?

But that doesn't really make sense given that the entire thing is hosted on Cloudflare anyway, including using CF nameserver. So I don't know, if you got ideas lmk.

Anyway, the site immediately 302-redirects the user to https[://]booking.confirmation-id91753[.]com/YYYYYYYYYY where YYYYYYYYYY is a 10-digit number. This 10-digit number maps to various details of the stay, including property, date, names, price. Interestingly the name is not always pre-filled.

The destination page mimics the style of a Booking.com website reasonably well & is prefilled with the above mentioned information. The visitor is asked to provide some additional data such as an Email & Phone number.

Once that information has been provide the website lets you proceed to https[://]booking.confirmation-id91753[.]com/C3REEV2V5/ for credit card harvesting. Here the path is the same for every victim, target information is maintained in a cookie, again using the 10-digit number from above. The visitor is asked to enter Credit Card information, including Cardholders Name, Card Number, Expiration Date, and CVC. You are even given the option to opt-in to marketing emails, nice touch!

After filling in CC information the visitor is being forwarded to a holding page & told, both by the site & the support chatbot box, to please wait while the CC data is being checked. The path is again universal to all targets (https[://]booking.confirmation-id91753[.]com/EC1G5P8X9/), victim specific data is maintained as cookies & in the request itself.

This is where, I assume, the magic happens - the page loads for a few minutes while the backend presumably attempts to conduct some light financial crimes with the given CC information. As I gave it some fake CC data I am unfortunately unable to confirm this but I am only going to put in so much effort into this.

If the CC validation fails the visitor is being send back to the previous page, asked to enter new CC information.

Overall a pretty clean website, ngl, pretty believable if you dont look to closely.

If an "ununsed" page is loaded all you get is a "AD not found (captcha2)" page which feels like it could be turned into identifying the underlying stack but appears to be pretty much completely GenAI generated, given the amount of unnecessary comments in the code.

Unfortunately the page, in general, doesn't yield a lot of other information I could find - used ressources appear to exclusively be hosted on the same domain, with a minority being loaded from central CF servers. As mentioned above, the default failure page appears to be GenAI generated. Comments are in Russian. There are also a few other places in the website that point to a Russian-language preference of the creators, incl. some CF links pointing to the ru-ru version of pages. The chatbot, which... isn't really functional most of the time, also has a tendency to default to Russian if unexpected non-language inputs are given.

Other than that the site itself is pretty non-descript to my untrained eye. Doing some searches on code snippets shows that this exact website code & design has been used since at least February 2024 (Urlquery example). That gives me an opportunity to go for the scheduled CF rant though...

Cloudflare, but for criminals

Scraping

Because I didn't just want to look at a trainwreck but actually do something semi-useful I went ahead & tried to identify impacted hotels. For this I used Hi5 as a starting point & enumberated the entire 4-character subdomain space. This was quite trivial as the HTTP status code immediately yielded success/failure: 444 for a miss, 302 (with a Location Header) for a hit.

This gave me 165 10-digit IDs & I noticed that these were quite closely grouped, none below 1720637422, none above 1748504819. This means that the density may be in the realm of doable for some random scraping.

Here, unfortuantely, the status code was 200, no matter of hit or miss. Fortunately the HTML expressed easy-to-identify hit/miss & it was even possible to obtain (noisy) information about the respective property. This was ... honestly ideal for me, I don't even get send personal data on the targets but still get the hotel name. Neat!

Some hideous BeautifulSoup4 code & 500k random IDs from the range later I had 400ish IDs for 70ish properties. This is definitely not all of them but with my terrible code this was already an entire evening. A (noisy, non-clean) list of the properties can be found here.

Reporting

So, let's do something good & actually report this.

Fortunately the site is already on the Safe Browing & similar shitlists so that's already done.

Cloudflare reports suck as usual but the John Johnson report is out, not that I believe they'll actually do much... . As Cloudflare is Cloudflare I can't report all of this at once (only one fqdn per report, great, thanks) so I just send a report for the final domain, not the gstlly one & mentioned gstlly in the comments.

Finally, Booking.com. I don't have a particular hate for their IT teams so I feel kinda bad for the reporting path - unfortunately I am unable to submit a report through their webforms as I am neither a customer nor a partner. This feels... kinda bad? While they have a security.txt it only mentions their HackerOne & their appsec email address. This doesn't fall under either but I can't not report it so... yeeeet, it goes to the appsec email, with an explicit apology & explanation.

Let's see what comes from this, I am sure booking.com already knows this one by heart... .