Three Angry Hotel Guests, Two Hijacked Mailboxes, One Script

A guest wrote to a UK luxury hotel to say a confrontation on the property had turned physical, that they had kept the complete video, and that they would be filing a complaint and taking legal action. Ten days later, a different guest wrote twice in 36 minutes: their card had been charged for an October 10 room, the booking never confirmed, and a screenshot was attached.

There was no screenshot. There were no guests.

All three emails came from real, long-established institutional mailboxes on two different continents: a business association in Asia and a government ministry in Latin America. Neither has any reason to book a hotel room or complain about an assault. Both accounts had been hijacked, and the same sending script drove them.

The Hotel Was the Target, Not the Brand

Most hospitality phishing we see casts the hotel as the sender: a fake reservation confirmation, a spoofed booking portal. This campaign inverted that. The hotel was the audience, and the pretext was its own duty of care.

Front-of-house and HR are paid to move fast on exactly two things: a guest who says they were charged wrongly, and a guest who says they were hurt. The first lure landed on the HR alias, reaching four HR mailboxes, with the subject promising a numbered guest complaint and "photo/video evidence." The second wave split across two shared mailboxes with subjects like "Payment charged without booking confirmation" and "Booking confirmation request for October 10."

Each message used a Western persona display name that matched nothing about the account behind it. And each put its evidence behind a single link displayed on www.google.com itself.

The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and pretexting at 6% of initial access vectors. A grievance script is pretexting tuned to a specific job description.

Two Hijacked Institutions, Full Authentication

This is where the usual triage instincts fail. Every message was sent through the institution's own submission server using authenticated SMTP, then relayed through that institution's legitimate outbound servers. Mapped to MITRE ATT&CK, that is T1586.002 (compromised email accounts) feeding T1566.002, spearphishing link.

At the hotel's inbound gateway, the first hop the hotel controls, the DMARC results were clean:

• The Asian association's two sends: DKIM pass, SPF pass, DMARC pass against a p=reject policy.
• The ministry's send: DKIM pass, SPF pass, DMARC pass against a p=quarantine policy.

Downstream, Microsoft 365 recorded SPF, DKIM and DMARC failures. That is a recipient-side artifact, not evidence of interference: the hotel's hybrid path relays mail through its own on-premises server, and the gateway rewrites every link, which breaks the DKIM body hash. Read the verdict at the edge, not the last hop.

On the association's sends, the submitting client announced itself with a foreign IP literal in its greeting while the recorded connection came from inside the institution's own address range. On the ministry's send, submission came from the mail server's own loopback interface. Neither pattern suggests header forgery. Both point to someone holding working credentials. If you want the defensive frame for that, it lives under account takeover protection.

See Your Risk: Calculate how many threats your SEG is missing

The Header That Tied Two Continents Together

Two unrelated institutions, two pretexts, ten days apart. What made them one campaign was a header the attacker's client set itself.

All three Message-IDs share one layout: a centisecond epoch timestamp, a process ID and a 64-bit random number, followed by the institution's domain. The timestamp decodes to the Date header to the second on all three.

Message-ID is client-set and survives relays. The two institutions run different mail server software, and the ministry's server stamps its own queue IDs in an entirely different format. So the shared layout came from the sender, not from either institution. It matches what Python's standard email library generates, which is suggestive of a script, though not proof of the tool.

That is linkage evidence, not the story. The story is that one operator rotated one grievance script through whichever trusted mailbox it could get into, aiming at the same hotel.

What Was Behind the Evidence Link

The links used Google's own share-link endpoint, so the visible host was google.com. On the two association sends, the platform's scanner followed the codes off Google to an unrelated .com, which returned an HTTP 404 at scan time. Cloaked, rotated or already pulled: the record does not say which. The ministry's link destination was never resolved, so there is no basis to say all three led to the same place.

No payload was observed. The emails did everything right up to the click: trusted sender, authenticated path, a link host nobody blocks, and a promised attachment that pushed the reader toward that link.

Why Every Automated Layer Said Yes

Microsoft 365 delivered both association sends to the Inbox with a spam confidence level of 1. It junked the ministry's send. The gateway's impersonation checks fired on nothing, because nothing was impersonated: these were the real domains. Automated triage on the two sibling incidents classified them as spam.

A human analyst overrode all three to malicious and grouped them into one family. The catch was contextual: an Asian business association and a Latin American ministry do not book UK hotel rooms under names like the ones on these messages, and a complaint that says "screenshot attached" with nothing attached is steering a click. That kind of cross-message judgement is what human-in-the-loop threat intelligence exists to capture, drawing on 36,000+ security professionals across 18,000+ organizations.

Treat the Grievance as an Event

Compromised accounts and social engineering are recurring themes in the FBI IC3 2024 report and the Microsoft Digital Defense Report 2024. CISA phishing guidance starts with the user, and for a hotel the user is the person whose job is to respond.

• Verify in your own systems first. A charge dispute or incident report should be checked against your PMS and incident log before anyone opens the guest's evidence.
• Flag sender-to-content mismatch. A chamber of commerce, a ministry or a university complaining as a hotel guest is a signal, whatever DMARC says.
• Treat "attached" with no attachment as hostile. That mismatch exists to push a link.
• Route grievance mail to security when it threatens. Legal threats and assault claims belong in a reporting workflow, not a race to click.

DMARC told the hotel who signed the mail. It could not tell the hotel who was holding the keys.