Attackers Exploit the Microsoft 365 Outage with Fake “Held Messages” Lures
By Mimecast Threat Research and Intelligence ·
Key Points
Attackers moved within hours: Phishing emails posing as Microsoft service notices followed the November 12 outage, using urgent lures and a single button.
The real destination is hidden: SendGrid click tracking encrypts the link’s destination, so checks that read only the visible URL miss it.
Template flaws give it away: An unfilled ”DOMAIN” placeholder, a fake incident ID and awkward wording are reliable signals. Mimecast is blocking the campaign’s links.
Within hours of the Microsoft 365 service disruption on November 12, 2026, we began seeing phishing emails that use the outage as a lure. The messages pose as Microsoft service notices, with display names such as ”Service Health”, ”Mail-Restore-Auth” and ”Health Status” and subjects that begin ”Outage -” and ”Restore –”, ”Strengthen-Security”. Each pushes the recipient to click a button, and the links run through SendGrid click tracking, to hide the real destination.
What the emails look like
We have seen two themes, each shown here with a representative email. Both borrow the Microsoft logo and a service-notice tone, and both rely on urgency.
Theme 1, held messages: ”messages held after the outage.” The email as shown in Figure 1.0 claims mail flow through Exchange Online was interrupted on 12 November 2026, cites an incident ID (EX1550543), and says four messages are held and will be deleted within 24 hours unless released. The button reads ”Restore messages.”
Theme 2, security issue: ”security issue found.” This as shown in figure 2.0 one carries a ”DOMAIN Support-Desk” header, says one security issue was found on your account, and offers a ”Take action” button.
Characteristics of the phishing emails
Related Tags
Email & Collaboration Security
Share this
Randomized subject token Both subjects follow the pattern ”Outage - ” plus a random alphanumeric token (20 characters in the held-messages example, 16 in the security-issue example). This looks like a per-message identifier generated by the sending tool, and it defeats exact-match subject rules.
Display-name impersonation. The sender display names ”Service Health” and ”Health Status”, ”Mail-Restore-Auth” are chosen to imitate Microsoft service notifications.
Unresolved template variable. The security-issue example renders the literal string ”DOMAIN” where a tenant or company name should be. The substitution never ran, which points to a mass-sending template with a tenant-name placeholder.
Urgency and a single call to action. The held-messages example sets a 24-hour deletion deadline and frames the message as an automated, do-not-reply notification. Both themes offer one button (”Restore messages”, ”Take action”), which leaves the recipient one path to follow.
Spoofed incident identifier. The quoted ID (EX followed by digits) mimics the format of Microsoft service incident numbers.
Resent-From header. The held-messages example carries a Resent-From header. This can indicate the message was relayed or re-sent through another mailbox.
The Call to Action URLs behind the buttons
We examined the structure of two call to action URLs tied to this activity.
URL in Service Health
URL in Health Status
Host
url7489.newbooker.com
u118254266.ct.sendgrid.net
Type
Branded SendGrid tracking domain
SendGrid’s default tracking domain
Path
/ls/click
/ls/click
Parameter
upn=u001.… (318 characters)
upn=u001.… (308 characters)
Decoded payload
212 bytes, random-looking
212 bytes, random-looking
Account identifier
None visible
u118254266 (in the hostname)
What they share. Both use SendGrid’s standard click-tracking format, and both hide the destination in an encrypted-looking value that cannot be read from the URL. Both are plain ASCII, with no lookalike characters.
What differs. The URL in Service Health is branded on a domain the sender controls, so it shows no SendGrid account ID. The URL in Health Status uses SendGrid’s own domain and exposes the sender’s SendGrid account ID, 118254266 (u118254266 in the hostname). That ID is a useful pivot for finding other messages from the same sender.
Conclusion
Outage-themed lures follow a predictable playbook: a trusted-sounding sender name, a deadline, and a single button. The two themes here differ in wording but share the same hidden infrastructure, SendGrid click tracking that conceals the destination from checks that read only the visible link.
Their template flaws, including the unresolved ”DOMAIN” variable, inconsistent copy, and a quoted incident ID that mimics Microsoft’s format, give defenders reliable signals to detect them. Mimecast is blocking the call-to-action URLs used in this campaign, so users who click the buttons are stopped before reaching the phishing page.
