Phishing From Microsoft's Own Mail

Jake Marchese | SOC Analyst | 20 August 2026

Attackers are making Microsoft send their phishing emails for them, and the lures have been localised for Australia.

Over the last two weeks, Fortian has observed a campaign matching research recently published by Abnormal AI, in which threat actors abuse Entra ID tenant branding to inject social engineering lures directly into legitimate Microsoft security notifications. The emails arrive from msonlineservicesteam@microsoftonline.com, pass SPF, DKIM and DMARC - because they are genuine Microsoft emails.

How it works

• The actor registers a disposable Microsoft 365 free-trial tenant on an onmicrosoft.com subdomain, then edits the Name field under tenant properties in Entra ID to contain their lure.
• They create a user in that tenant, open Security info at mysignins.microsoft.com, select "Add sign-in method" and choose Email, then enter the victim's address instead of their own. That triggers Microsoft's verification workflow, and the automated template builds the subject line as {Tenant Name} + "account email verification code".
• Sixty or more characters of injected text push the legitimate portion off screen, and the tenant name is reused in the signature block to reinforce the lure.

A subject line from the samples we observed:

Dràmà Rèèlš šübšçrïptïön rènèwèd 349.99 AUD TRX ÏD NBÜDYŠ87 Ünàpprövèd ördèr Vèrïfy wïth PÏN ör çàll 61 (02) 7258-0712 account email verification code

Note the localisation. Where the publicly reported samples used a US callback number and a Bitcoin or PayPal pretext, this one uses AUD, a fabricated transaction reference and a Sydney landline. The number is also formatted inconsistently, combining the country code with the domestic trunk prefix. This is something no legitimate Australian sender would do.

Why this defeats most controls

• Sender reputation and authentication provide no signal. The mail genuinely originates from Microsoft infrastructure.
• Most email security products won't act on mail from Microsoft's own notification infrastructure. That trust is the delivery mechanism.
• There are no conventional IOCs. The only URLs are Microsoft's own privacy and legal pages. The payload is a phone number - telephone-oriented attack delivery rather than credential phishing.
• Every vowel and several consonants carry combining diacritics. The obfuscation set varies between samples, so character blocklists won't hold.

The samples we observed are commodity fraud, a fake subscription renewal designed to funnel victims into a callback scam. But the delivery mechanism is the story, not necessarily the payload itself. The orchestration methods such as a disposable tenant, injected branding, legitimate Microsoft infrastructure as the mail relay, is available to any threat actor with a credit card and five minutes. A more capable adversary using this for targeted credential harvesting or BEC against a specific organisation looks very different, because the lure arrives from a sender your mail gateway already trusts, inside a notification template your users already expect, with no URL or attachment to detonate. No link to click, no attachment to sandbox, and your gateway already trusts the sender.

Durable artefacts worth hunting on

• The trailing string account email verification code. This is fixed by the Microsoft template and cannot be altered by the attacker, making it the most reliable anchor in the entire message.
• Anomalous subject length preceding that string. A legitimate verification subject carries a short organisation name.
• The callback number: +61 2 7258 0712.
• The sending tenant's onmicrosoft.com subdomain in the signature block. This rotates per tenant under a burn-and-churn model, but is useful for scoping and retrospective search.

What we recommend

• Treat allowlisting as a delivery decision, not a trust decision. Content inspection should still apply to allowlisted senders.
• Decompose to NFKD and strip combining marks before applying regex. NFKC alone won't recover the plaintext, and without that step your keyword rules won't fire on any of the above.
• Brief your service desk. This campaign produces no click, no credential submission and no attachment detonation, so your email stack sees nothing. Users who react will contact internal IT with a billing question rather than report a phish, and that ticket may be the only indication the campaign reached your environment. Make sure it gets escalated rather than closed.

Microsoft won't be the last platform abused this way. Any SaaS product that reflects user controlled metadata into an outbound notification template is a candidate. If your detection logic stops at "the sender authenticated correctly", this walks straight through. The technique is freely available to anyone who can register a trial tenant, and the next campaign to use it may not be aiming at individuals.