The Hotel Reservation Was Real. One Link Was Not.

Most phishing emails fail the first-glance test. The sender looks wrong, the formatting is off, the ask is too urgent. This one passed it. The email was a hotel reservation amendment for a one-night stay at a luxury London property. The sender domain was real. The content was professionally formatted with a confirmation number, guest details, check-in and check-out dates, and a reservations agent's signature block. The body contained no credential request, no payment demand, no manufactured urgency.

Among a dozen legitimate hotel links, one URL was different. Its display text showed what appeared to be a hotel subdomain. Its actual destination was a tokenized emailprotection[.]link wrapper that automated scanners could not resolve to a final target.

The attack did not need to look dangerous. It needed to look routine.

A Reservation That Checked Every Box

The email arrived from reserve-portmansquare@nobuhotels[.]com with a display name referencing the hotel's London Portman Square property. The subject line referenced a reservation amendment. The body contained the kind of structured transactional content that corporate travelers and executive assistants process without a second thought: a guest name, a confirmation number, a one-night booking for a specific date, room rate details, and a closing signature from a named reservations agent with the hotel's physical address and phone number.

A small detail: the body text referenced "slaying" instead of "staying." This kind of minor typographical error is easy to dismiss in isolation, but it is the sort of artifact that distinguishes content generated or manipulated outside a hotel's standard reservation platform from content produced by the platform itself.

The email also carried a PDF attachment labeled as a confirmation letter. Antivirus and sandbox analysis returned a clean verdict. The file may contain embedded links routing to the same wrapper domain, but this was not confirmed during analysis.

Authentication Was Mixed, but Explainable

The email traversed a Mimecast secure email gateway relay (relay[.]mimecast[.]com) before reaching the recipient. This relay path explains the mixed authentication signals:

• SPF: Softfail for IP 195[.]130[.]217[.]221 at the initial check
• DKIM: Failed at the Microsoft evaluation layer, but passed at the relay level via Mimecast (selector2 for nobuhotels[.]com)
• DMARC: nobuhotels[.]com publishes a p=quarantine policy
• ARC: Passed, documenting the relay chain

These results are consistent with legitimate email security gateway behavior. When a message passes through a relay like Mimecast, the relay may modify headers or routing in ways that break the original SPF and DKIM alignment at the next hop. ARC (Authenticated Received Chain) exists specifically to preserve trust across these hops. The mixed results here do not indicate spoofing. They indicate a real email from a real domain that traversed a real security gateway.

This is precisely what makes the attack effective. An analyst reviewing these headers would find explainable authentication, not red flags.

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

The One Link That Was Not Like the Others

The email body contained several links. Most pointed directly to nobuhotels[.]com subdomains and resolved cleanly to legitimate hotel pages. A handful used link[.]rs[.]nobuhotels[.]com, a marketing tracking subdomain consistent with standard CRM link wrapping. All of these were clean.

One link was different. Its display text read London-portman[.]nobuhotels[.]com, matching the hotel's legitimate subdomain pattern. But the underlying href pointed to a parameterized URL on url[.]emailprotection[.]link, a link-wrapping domain that has been documented in threat reports as abused by phishing operators. The wrapper resolved to IP 199[.]193[.]205[.]140 (CNAME: urlrs[.]gslb[.]serverdata[.]net) with a valid SSL certificate.

The wrapper performs client-side or interaction-based redirection. When automated scanners attempted to resolve the final destination, they could not determine where the link ultimately led. The probable intent is credential harvesting, but the terminal destination remains unconfirmed.

This is the architecture that makes the attack work. A recipient scanning the email sees a dozen hotel links and one more that looks like a hotel link. The display text matches. The context is transactional. There is no reason to hover, inspect, or question the one URL whose destination is not what it appears to be.

What the Gateway Could Not Evaluate

A secure email gateway examining this message would find: a legitimate sender domain, explainable authentication, clean link destinations for all but one URL (which sits behind a wrapper with valid SSL), a clean PDF attachment, and professional transactional content with no payload indicators. The gateway would pass it.

The signals that matter here are contextual. Was this reservation expected? Does the recipient have a travel booking with this property? Has the organization received prior correspondence from this sender address? Is the emailprotection[.]link wrapper consistent with the hotel's normal email infrastructure, or is it foreign to the sender's domain?

These are questions that require sender-recipient relationship modeling, organizational context awareness, and the ability to evaluate each link against the sender's known infrastructure patterns. The IRONSCALES platform evaluates these behavioral dimensions, identifying when a single anomalous link appears inside otherwise legitimate communication.

MITRE ATT&CK Mapping

Indicators of Compromise

One Bad Link Is All It Takes

This attack did not rely on urgency, fear, or authority. It relied on normalcy. A hotel reservation is transactional content that corporate recipients expect, process quickly, and rarely scrutinize link by link. The attacker (or compromised system) placed a single weaponized URL among legitimate hotel links and let the context do the work.

Defenses that evaluate emails holistically, comparing each link against the sender's known infrastructure, modeling the recipient's communication patterns, and resolving wrapper URLs to their terminal destinations, catch the one link that does not belong. Defenses that trust display text and authentication headers alone do not.