The Phish Arrived as an Automatic Reply You Never Asked For

The phishing email was an automatic reply. Not a fake one dressed up to look automatic, but a real reply generated by Exchange Online's own mailbox rules, answering a message the recipient never sent.

Two engineers at a US engineering and environmental consulting firm received it. One saw the subject "Automatic reply: Security Breach! Cloud Virus Detected! 6693." The other saw "Automatic reply: Re-Activate Cloud Protection Before Data Loss! 8846." Same sender, different subjects. That difference is the whole story.

An automatic reply copies the subject of whatever it is answering. So the alarm text in each subject was not written into the reply at all. It came from the trigger message, and whoever controls the trigger controls the headline.

Every Header Says Routine System Traffic

Read the headers cold and this looks like backscatter, the harmless noise of auto-generated mail bouncing around the internet.

• auto-submitted: auto-generated
• X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent
• X-Auto-Response-Suppress: All
• X-MS-Exchange-Inbox-Rules-Loop naming the sending mailbox
• Return-Path: <>, a null envelope sender

That null Return-Path matters. Auto-generated mail ships without an envelope sender by design, so it cannot trigger an endless loop of replies to replies. It is a convention that tells every downstream system "this is machine traffic, not a campaign."

Then there are the threading headers. In-Reply-To, References and x-ms-exchange-parent-message-id all point at the same outlook.com message ID. That message is not in the record. Neither recipient ever corresponded with the sender in either direction. The reply answers a conversation that, from the victim's side, never existed.

The evidence is consistent with a trigger message that carried the victim's address as its reply address. The sending tenant's mailbox rules did the rest. We cannot say from the record exactly how the trigger was sent, or whether it was an out-of-office response or a template reply rule. The Mailbox Rules Agent generates both. What we can say is that the lure was the body of an automatic reply generated by that tenant's mailbox rules.

The Lure Lived in the Reply Body

Below Microsoft's own "You don't often get email from" first-contact banner sat a single linked image: a branded antivirus graphic from a well-known consumer security vendor, pulled from a remote image host. Click the image and you went to a reurl[.]cc shortlink.

Underneath, a fake "click here to unsubscribe" line pointed to the same shortlink. When the opt-out link and the call to action resolve to one URL, the unsubscribe is a second button, not an exit. The template markup used Klaviyo-style kl- classes, a borrowed marketing-email skeleton.

The scareware pretext is not new, and neither is the shortener. What is worth your attention is the wrapper. The sender display name was "Antivirus-Protect #979665," sending from a mailbox on lakcyt.onmicrosoft.com. The random tenant name, the auto-numbered mailbox and the scareware display name are all consistent with a throwaway tenant, though ownership is not proven.

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

Microsoft Signed It Because Microsoft Sent It

The current-hop authentication results were clean across the board: SPF pass from a Microsoft outbound IP, DKIM pass with header.d=Lakcyt.onmicrosoft.com, DMARC pass, compauth pass (reason 100), and ARC pass.

Nothing was forged and nothing was relayed through a compromised third-party account. An earlier Authentication-Results-Original line reading dkim=none; dmarc=none is the pre-signing submit state inside the sending tenant, not a failure. Microsoft generated the reply and Microsoft signed it.

That is a supporting point, not the headline. Plenty of phishing from onmicrosoft.com tenants passes DMARC. The new part is that the message carried every marker of an auto-generated reply on top of the pass.

Exchange Online did not trust it blindly. It scored the message SCL 6 and filed it in Junk. So this is not a story about a filter bypass. It is about the assumption a human or a triage workflow makes when an "Automatic reply" lands in front of them: that it answers something they sent, so it must be harmless.

Mapping the Mechanics

• T1566.002, Phishing: Spearphishing Link. The image and the fake unsubscribe both pointed to the same shortened URL.
• T1585.002, Establish Accounts: Email Accounts. The sending mailbox sat on a tenant consistent with a throwaway setup.

The shortlink returned a clean scanner verdict and a news-like page at scan time. We did not observe a credential form, payment page or download behind it, and we are not claiming one. The intent signal is in the delivery, not the landing.

An Automatic Reply You Never Triggered Is the Tell

The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and phishing at 16% of initial access. Attackers keep finding wrappers that make a lure look like something a person does not need to think about. Auto-generated mail is one of those wrappers. NIST defines phishing by the deception, not the delivery format, and that is the right lens here.

IRONSCALES Adaptive AI automated detection resolved this as phishing and removed it from both mailboxes. The signals did not depend on authentication. A first-time sender. An automatic reply with no matching outbound message. An alarmist subject inherited from an unseen trigger. A branded scareware image. An unsubscribe link identical to the call to action. Individually, each is weak. Together, they describe a reply nobody asked for.

For your team:

• Check In-Reply-To against reality. A genuine automatic reply answers something in your Sent folder. If it does not, the reply is the lure.
• Stop treating auto-generated as a trust class. auto-submitted and a null Return-Path describe how a message was produced, not whether it is safe. The Microsoft Digital Defense Report 2024 is a useful reminder of how much attacker activity now runs on legitimate cloud infrastructure.
• Read subjects on automatic replies as attacker text. The prefix is Microsoft's. Everything after the colon came from the trigger.
• Teach the pattern, not the brand. CISA phishing guidance stresses user reporting as an early stage defense. "An automatic reply to an email I never sent" is a sentence any employee can learn to report.

If your stack is native M365 with an augmentation layer, make sure its logic weighs conversation history, not just the authentication verdict. Microsoft authenticated this message correctly. That was never the question.