A highly targeted phishing campaign has been hitting hotel guests across Luxembourg. Originally flagged by the Computer Incident Response Center Luxembourg (CIRCL), this campaign stands out not because of advanced malware, but because of its impeccable contextual credibility.
Threat actors aren't guessing targets; they are hitting actual hotel guests on WhatsApp with exact, legitimate booking details to steal credit card data.
As part of a technical review into the infrastructure, we analyzed a recent Indicator of Compromise (IoC) linked to this campaign: [https://stay-hotel607923.com](https://stay-hotel607923.com). Here is the deep dive into how this attack works, the infrastructure behind it, and how to track it.
The Attack Workflow: Smishing with Context
Most phishing campaigns rely on volume, hoping a small fraction of a massive email list bites. This campaign relies on precision.
The Data Exposure: CIRCL assesses that the campaign's source data may originate from services integrated with myLighthouse, a widely used property management and business intelligence platform in the hospitality sector. While a definitive breach of Lighthouse has not been confirmed, potential entry points include credential stuffing of hotel staff accounts, API integration abuse, or unauthorized data exfiltration.
However, I did a bit of OSINT research and it did lead me to find leaked credentials for myLighthouse, so it is possible that the actors used those credentials to gaina access to gather their victim list.
The Lure: Victims receive a WhatsApp message referencing their actual hotel reservation, including correct dates, names, or hotel locations.
The Call to Action: The attacker claims there is an issue with the booking payment or validation, pressuring the victim to click an infrastructure link to "confirm" their stay.
Infrastructure Breakdown: stay-hotel607923.com
When looking at the technical indicators of the domain provided in the CIRCL MISP event (10a94632-a0a1-4062-a3a5-95fe321ae045), we can uncover a clear picture of the threat actor's operational playbook.
1. Registration and Lifecycle Analysis
An analysis of the WHOIS data reveals an incredibly tight operational timeline:
Registrar: DYNADOT LLC
Creation Date: 2026-05-26 22:56:46 UTC
Updated Date: 2026-05-26 23:10:03 UTC
The Analyst's Take: Notice the gap between the creation time and the update time—exactly 13 minutes and 17 seconds. This is the footprint of automation. The threat actor script-purchased the domain via Dynadot's API, instantly modified the nameservers to point to their hosting/defensive setup, and launched the campaign immediately.
The short lifecycle and random numerical string appended to the domain (hotel607923) point heavily to automated domain generation algorithms (DGAs) or high-velocity domain spinning to stay ahead of automated domain-age blocklists.
2. Edge Defenses & Fronting
Interrogating the live endpoint yielded typical modern phishing defenses:
Response Headers:
Server: cloudflareHistorical Availability: Complete dead-end on the Wayback Machine.
The Analyst's Take: The threat actor is using Cloudflare as a reverse proxy. This accomplishes three tactical goals for the attacker:
It hides the true backend IP address of the malicious server, complicating direct takedown attempts.
It provides free, trusted SSL certificates (
HTTPS), which modern browsers require to look legitimate to victims.It allows the attacker to use Cloudflare's Web Application Firewall (WAF) to geofence traffic or block security researchers (like us) who try to programmatically scan the site outside the targeted Luxembourg IP range.
3. Backend Fingerprinting
Because the domain was pulled out in the open, the threat actor cut the campaign and burned the infrastructure shortly after exposure. Direct web requests no longer serve the malicious front-end. However, analysis of the historical session architecture gives away the core tech stack:
Observed Cookie:
PHPSESSID
The Analyst's Take: The presence of the PHPSESSID cookie tells us that the phishing engine is running on a standard PHP backend. This indicates a highly modular, lightweight phishing framework—likely a customized panel or kit that handles the incoming guest data, validates the credit card formats in real-time, and exfiltrates the stolen credit cards to the threat actor via a Telegram bot API or a centralized command-and-control (C2) database.
The CTI Blueprint: How to Hunt This Campaign
Because the threat actors are rotating domains and WhatsApp numbers rapidly, static IoC blocking is an insufficient defense. Security teams, specifically those protecting hospitality or retail organizations, should shift to behavior and infrastructure hunting.
1. Passive DNS (pDNS) Hunting
Since the threat actor relies on Dynadot and specific naming conventions, hunters should pivot on pDNS fields to search for adjacent infrastructure creations:
Look for newly registered domains matching the regular expression:
^stay-hotel[0-9]{6}\.com$Monitor for new registrations via Dynadot LLC that utilize Cloudflare nameservers within identical 15-minute creation-to-update windows.
2. Defensive Actions for Hospitality Networks
If your infrastructure integrates with platforms like myLighthouse, standard credential hygiene is no longer optional:
MFA Enforcement: Ensure Multi-Factor Authentication is explicitly enforced for all hospitality SaaS integrations (Lighthouse enforced this globally on June 1, 2026, but legacy or auxiliary integrations should be manually audited).
Log Auditing: Query SaaS logs for anomalous API calls or export actions containing customer booking details, focusing on API tokens used by third-party integrations.
Comments
Post a Comment