Skip to main content

Security Advisory - Microsoft 365 Direct Send Abuse in Active Phishing Campaigns

Security Advisory

The Armada team has observed active exploitation of an ongoing security risk in M365. Due to the low effort required to exploit this risk and the high impact from its use, the Armada team expects this activity to increase.

Bottom Line Up front

  • Microsoft released a feature into public preview in April of 2025 named Direct Send
  • This functionality is meant to be used by printers and scanners to send email on behalf of the tenant.
  • This functionality can be used to send internal emails that bypass traditional email controls by issuing a Powershell request to any tenant to .mail.protection.outlook.com
  • Threat actors have begun abusing this functionality to send phishing emails internally

Background

Threat actors have been actively exploiting Microsoft 365’s Direct Send feature to push credential-harvesting emails that look like they originate inside the victim’s tenant. Direct Send was meant for printers or scanners that need to relay mail through a tenant-specific smart-host (tenant-name.mail.protection.outlook.com) without authentication. When that smart-host is left open to the Internet, anyone can spoof internal addresses and route mail through Microsoft’s infrastructure, dodging SPF, DKIM, DMARC, reputation checks, and “external sender” banners.

This campaign was first identified by Varonis Threat Labs on June 27th and confirmed 70-plus organizations (finance, manufacturing, construction/engineering, healthcare, insurance) have already been hit. Attackers use a single-line PowerShell Send-MailMessage command from commodity VPS IPs to drop emails with various themes.

Send-MailMessage -SmtpServer 
  
   .mail.protection.outlook.com -To joe@company.com -From joe@company.com -Subject "Payment Required" -Body "Please see attached remittance as required. -BodyAsHtml
  

Mutliple payloads have been observed but all lead to either a PDF or image containing a QR code that pushes users to a fake Microsoft login page. No account compromise or malware is needed—just the exposed smart-host.

What is direct send?

Direct Send is an Exchange Online option that lets printers, scanners, and line-of-business apps relay mail through the tenant’s smart-host ( tenant.mail.protection.outlook.com ) without authentication. The idea is convenience: no SMTP creds, no OAuth, just fire-and-forget. When that smart-host is left open to the internet, anyone can connect, spoof an internal sender, and slip past SPF, DKIM, DMARC, and “external sender” banners—because the message now originates from Microsoft’s own infrastructure.

Impact

When successfully delivered, the spoofed email arrives in the user’s inbox looking authentic and internal- because it is.

Once credentials are harvested, adversaries can:

  • Pivot to Business Email Compromise (BEC) — use the freshly stolen O365 session for wire-fraud or invoice-swap attacks.
  • Steal or destroy data in SharePoint / OneDrive with the victim’s token.
  • Abuse internal trust to phish deeper into the organization or its partners.
  • Escalate privileges or register malicious applications for persistent access.

Because the email never fails “external” checks, traditional secure-email-gateway (SEG) and EOP policies may never flag it.

Indicators of Compromise (IOCs)

Look for these signals in mail-flow and firewall logs:

Category Example Why it Matters
Malicious sender IPs 139.28.36[.]230, 51.89.86[.]105 External IPs observed relaying through tenant smart-hosts. NOTE: These are legitimate Microsoft hosts
Subjects “Caller Left VM Message”, “New Missed Fax-msg” Consistent across campaigns
Attachments PDFs named Fax-msg.pdf, Play_VM-Now.pdf, Listen.pdf containing QR codes Drive users to phishing sites
Header Anomalies Received: shows smart-host → internal mailbox, but SPF/DKIM/DMARC = fail Spoofed yet delivered internally

Recommendations

  • Disable or Restrict Direct Send
    • In Exchange Admin Center, enable Reject Direct Send (public preview, April 2025). Only allow if you must support unauthenticated device mail.
  • Tighten Email Auth
    • Enforce SPF hard-fail and DMARC p=reject; quarantine or flag any unauthenticated “internal” mail.
  • Monitor for Abuse
    • Hunt headers for external IPs hitting *.mail.protection.outlook.com.
    • Alert on self-addressed mail or unexpected PowerShell Send-MailMessage usage.
  • User Awareness
    • Brief staff on QR-code (“quishing”) lures and remind them that voicemail/fax notices can be faked.
  • Layered Defenses
    • Enable anti-spoofing policies, Sender-ID checks, and Conditional Access for risky sign-ins.
    • Require MFA everywhere—stolen creds are less valuable when tokens are short-lived.

Resources

Like our content? Subscribe and stay informed.

Tags

See all