Hospitality Sector Hit by Phishing Campaign Using Fake Guest Complaint Emails

Pierluigi Paganini
June 27, 2026

Microsoft warns of a phishing campaign targeting the hospitality sector with fake guest emails that install TonRAT using resilient persistence.

Microsoft Threat Intelligence published a detailed analysis on an ongoing hacking campaign against hospitality organizations that has been running since April 2026. The targets are specific: device names observed across compromised environments include strings like “reception,” “frontdesk,” “reservations,” “accueil,” “recepcja,” and “recepce” in English, French, Polish, Czech, and Spanish. The attacker knows exactly who opens guest-related emails without thinking twice about it.

The delivery mechanism is what Microsoft calls authentication laundering.

“The threat actor uses Calendly’s email notification system and Google’s URL redirect functionality to construct a multi-hop delivery chain in which the direct Calendly path passes Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks.” reads the report published by Microsoft.

The emails arrive with the display name “Booking Manager (via Calendly)” and carry lures about bedbug infestations, health inspections, guest complaints, final warnings, and threatened suspensions. They came in Japanese, Danish, and Dutch, with Japanese the most common. The researchers observed that the messages have no recipient name, no property name which suggests this is high-volume list-driven sending, not tailored spearphishing.

Upon clicking the embedded link, the victim is routed through four hops: a Calendly redirect to share.google, then to www.google.com, then to a freshly registered Cloudflare-fronted .cfd domain sitting behind a Turnstile challenge. That challenge serves double duty as an anti-analysis gate and a geolocation filter before the payload lands. The downloaded archive contains a shortcut file named IMG-<numbers>.png.lnk in Wave 1 or PHOTO-<numbers>.png.lnk in Wave 2, both sized consistently between 1,989 and 2,079 bytes, suggesting the same builder tool across the campaign.

Opening the shortcut fires PowerShell. The script uses BigInt arithmetic to decode a download URL, a technique that evolved across seven distinct obfuscation phases over the course of the campaign.

“A defining characteristic of this campaign is its steady but disciplined obfuscation evolution. Microsoft observed seven PowerShell obfuscation phases over the course of the campaign, but the underlying logic remained consistent: decode embedded data through arithmetic operations, recover the next-stage content, and retrieve a PowerShell script that runs from the %TEMP% folder.” continues the report. “This pattern suggests that the threat actor is iterating for durability against static detections rather than experimenting with entirely new tradecraft. “

The operators never abandoned PowerShell or Node.js. They just kept re-skinning the same working loader as detections caught up.

The decoded script downloads a legitimate Node.js v24.13.0 runtime from nodejs.org into user space, then runs a JavaScript implant tracked as TonRAT from AppData\Local\Nodejs\. No system-wide Node installation is needed. Wave 2 added an intermediate stage: the downloaded PowerShell script triggers dynamic .NET DLL compilation through csc.exe and cvtres.exe, producing small 3,072-byte DLLs with random names before reaching Node.js. Microsoft assesses this step is preparatory or conditional, as the compiled DLL wasn’t observed being explicitly loaded in available telemetry.

The persistence design is what makes this campaign technically notable.

“The persistence design itself is a meaningful post-compromise observation. The combination of a durable Node.js launch point in HKCU\Run and a repeatedly refreshed ProgramData payload through HKCU\RunOnce suggests an effort to maintain execution options across user sign-ins while also preserving a secondary recovery path.” states Microsoft. “This RunOnce loop is unusual enough that it might provide defenders with a strong hunting pivot even when file names, domains, or script syntax change.”

The RunOnce entry doesn’t fire once and disappear: the payload refreshes its own persistence after each execution, creating a loop. Microsoft observed this in practice: Defender blocked the PE payload xmnrwv9l.exe on a confirmed compromised device, but the Node.js Run key survived. Two days later, the implant reactivated, reconnected to new C2 domains, and resumed pushing additional payloads. Blocking one path left the other alive.

Post-compromise activity on a subset of devices included C2 beaconing to fixed IPs over non-standard ports including 56001, 56002, 56003, 8443, 8445, 8453, and 5555. Some hosts showed headless browser automation with --headless --no-sandbox flags, a geolocation check via ip-api.com, and a forced shutdown through cmd /c shutdown -s -t 0.

The forced shutdown may have served to interrupt user activity, reduce defender response time at a specific stage, or conceal visible symptoms after automated browser tasks completed. Microsoft has not confirmed data theft, ransomware deployment, or named any victims. The campaign’s ultimate objective remains unclear, which is itself a useful piece of information: whoever built this invested heavily in persistence and evasion for something they haven’t shown yet.

Complete remediation requires removing both persistence mechanisms simultaneously: the HKCU\RunOnce entry pointing into ProgramData, the HKCU\Run key pointing to the Node.js component, the Node.js runtime itself, and all associated .js files under AppData\Local\Nodejs\. Start with reception, reservations, and front office systems, and treat any device where Node.js appears in user-space paths as potentially compromised until proven otherwise.

The report includes Indicators of compromise (IoCs) for this campaign.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon