The email was not sent by an attacker's mail server. It was generated by Microsoft's own Transport Message Recall Routing Agent, authenticated as Internal, with direction set to Originating. And it told the recipient to log in with their email address and password.
The message arrived at a mid-size insurance brokerage as a "Message Recall Report." The subject referenced what appeared to be a legitimate insurance claim: a wind damage report for a Texas school district, complete with file numbers, reference codes, and a named vendor. The From address was Office365Reports@microsoft[.]com. The headers confirmed: Auto-Submitted: auto-generated, X-MS-Exchange-Generated-Message-Source: Transport Message Recall Routing Agent.
The "View Message Recall Report" link pointed to outlook[.]office[.]com/mail/messageRecall.html with a full message ID parameter. A legitimate Microsoft URL, hosted on Microsoft infrastructure, following the expected recall report format.
But the body also contained this line: "If prompted, login with your email address and password."
That is not standard language in a Microsoft message recall notification. It is a credential harvesting prompt embedded in what the mail system treated as trusted internal traffic.
Because the Transport Message Recall Routing Agent generated this email, it carried AuthAs=Internal with AuthMechanism=05. The direction was Originating, not Incoming. SCL was 1. From the perspective of any security tool that distinguishes internal from external mail, this was system traffic.
That classification matters. Internal messages typically bypass the inbound scanning pipeline entirely. URL reputation checks, sender verification, content analysis: all of these are calibrated for external threats. An email that the mail platform itself generated sits inside the trust boundary by definition.
The MITRE ATT&CK framework maps this to T1534 (Internal Spearphishing): using internal messaging systems to deliver malicious content that bypasses perimeter controls. The twist here is that the attacker did not need to compromise an internal account in the traditional sense. They triggered a Microsoft system mechanism that produced the delivery vehicle for them.
Themis, the IRONSCALES Adaptive AI, classified the message at 72% confidence with a VIP Recipient label. The detection signals were behavioral: the sender was a first-time correspondent to this recipient, the message was flagged as high risk, and the community intelligence layer identified the pattern as anomalous. Four mailboxes were quarantined.
The recall subject referenced a specific insurance claim that the recipient's organization had no documented relationship with. That contextual mismatch, combined with the credential prompt, was the signal that authentication and system trust could not provide.
See Your Risk: Calculate how many threats your SEG is missing
| Type | Indicator | Context |
|---|---|---|
| Sender Address | Office365Reports@microsoft[.]com | Microsoft system-generated sender |
| Auth Status | AuthAs=Internal, AuthMechanism=05 | Internal authentication, system-generated |
| Message Source | Transport Message Recall Routing Agent | Microsoft Exchange recall mechanism |
| Recall Link | outlook[.]office[.]com/mail/messageRecall.html?messageid=DM8P221MB0523B843476359C224750363B40B2@DM8P221MB0523[.]NAMP221[.]PROD[.]OUTLOOK[.]COM | Legitimate Microsoft recall URL |
| SCL | 1 | Low spam confidence, consistent with internal traffic |
| Direction | Originating | Not inbound, generated within the mail platform |
| Technique | ID | Relevance |
|---|---|---|
| Internal Spearphishing | T1534 | System-generated internal message used as delivery mechanism |
| Valid Accounts | T1078 | Leveraged Microsoft internal authentication status |
| Phishing: Spearphishing Link | T1566.002 | Credential prompt with link to outlook.office.com recall page |
| Attack | What happened |
|---|---|
| The SOC Alert That Came From a Compromised FinTech: An Authenticated BlueVine Sender Delivering a Typosquat Link Buried in Operational Context | A fully authenticated email from bluevine.com impersonated an internal SOC quarantine notification. |
| The Email That Passed Every Security Check (Because Adobe Sent It) | A phishing campaign targeting school district staff used Adobe's own sending infrastructure, real DKIM signatures. |
| When the Safety Wrapper Becomes the Disguise: Brazilian NF-e Phishing via Safe Links Rewrite | A Portuguese-language invoice lure authenticated through a compromised Brazilian domain used is.gd to hide its payload. |
| The Insurance Claim That Passed Every Check (Progressive's Own Infrastructure Sent It) | A credential theft attempt sent through Progressive Insurance's own Salesforce Marketing Cloud infrastructure. |
| When the Sender Domain Is Also the Phishing Kit Host: Dual-Purpose Domain Compromise | An attacker compromised a legitimate manufacturing company domain and used it two ways at once: as the authenticated sending address and as the host for... |