Phishing Without a Password: How Attackers Hijacked Microsoft 365’s Direct Send

hi. buckle up. we’re talking about emails that look like they came from your coworker, were sent through your own domain, and landed right inside your users’ inboxes…

…without a single login, compromised account, or auth token.
this ain’t magic. this is Microsoft 365 Direct Send — and it just got weaponized.

what’s Direct Send anyway?

it’s a legit M365 feature. sounds innocent:
“send email directly from a local app or device through your tenant’s smart host.”

like: your scanner → sends PDF to your inbox. or your fax machine, if you still live in 2003.

how it works:

  • anyone who knows your domain can guess your smart-host pattern
    (e.g. your-company-com.mail.protection.outlook.com)

  • and then: send mail through your tenant’s SMTP relay

  • as long as it’s to a valid recipient — it goes through

  • no login. no token. no OAuth. just SMTP and vibes.

enter the exploit: phishing-as-a-service

Varonis Threat Labs found it in May 2025:
a phishing campaign targeting 70+ orgs, mostly US-based, mostly financial, engineering, health & insurance.

attackers used:

  • PowerShell + SMTP

  • external IPs from Ukraine (139.28.36[.]230)

  • smart-hosts like acme-corp-com.mail.protection.outlook.com

they spoofed internal users using M365’s own infra. mails passed through internal routing. and they looked native.

📎 email body: fake voicemail alert
📎 attachment: PDF with a QR code
📎 scan it? → M365 login page clone with a credential harvester

Microsoft’s filters? they watched it happen

you’d think SPF, DKIM, DMARC would help, right?
nope.

📎 SPF failed
📎 DKIM? none
📎 DMARC? nope
📎 verdict? delivered anyway — since it came from your own smart host

🙃 Direct Send has no sender auth by design
it assumes the person sending knows what they’re doing
(surprise: they didn’t)

what to do before your domain sends malware to your CEO

✅ disable Direct Send unless you’re using it and actually need it
admin center → mail flow → connectors → block unauthenticated relay

✅ set strict DMARC policy
p=reject isn’t optional anymore

✅ audit all inbound headers for:

  • mismatch between IP and domain

  • use of smart-host IPs from unknown networks

  • no DKIM / SPF alignment

✅ lock down SPF to static IPs and block catch-all includes

✅ enable MFA on all accounts, even low-priv apps

📎 Microsoft’s official guidance:
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#direct-send-send-mail-directly-from-your-device-or-application-to-microsoft-365-or-office-365

IOC time: what’s out there right now?

📎 IPs used:

  • 139.28.36[.]230

  • others in that subnet

📎 domains:

  • fake voicemail senders from spoofed internal identities

  • target-specific pages hosted on external compromised infra

Varonis shared a full IOC list here:
https://www.varonis.com/blog/direct-send-exploit

TL;DR: when Microsoft sends phishing on your behalf

this isn’t a “bad Microsoft” story.
this is a “misused feature built for sysadmins, not for attackers” story.

Direct Send was made for convenience. but now?
it’s a backdoor with a smiley face.
no login. no creds. just SMTP packets and QR scams.

your mail gateway won’t see it. your EOP filters might not catch it.
but your users? they’ll click. because it looks internal.

and that’s how phishing just leveled up.