In the last couple of months there seems to be some issues with “direct send” which part of Exchange Online, being used for unofficial purposes, let us explore more about the technology and how it could be exploited.
This is very similar if not identical to an "open relay" SMTP solution, it requires you to have a Exchange Online license, but beyond that this is very much like an open relay scenario.
What is the Direct Send Security Issue?
Exchange Online has Direct Send feature was originally designed to enable internal devices like printers and applications to send emails without requiring authentication. However, this functionality creates a significant security vulnerability that attackers are actively exploiting.
The core problem lies in how Direct Send operates: it accepts emails from any external source to a predictable smart host address (formatted as tenantname.mail.protection.outlook.com) without verifying the sender's identity. This means malicious actors can craft emails that appear to originate from any email address - internal users, external partners, vendors, or even well-known service providers - without ever accessing your organization's systems.
How Attackers Exploit This Vulnerability
The exploitation process uses the PowerShell Send-MailMessage cmdlet with extensive customization options that make attacks highly sophisticated:
Basic Attack Syntax
Send-MailMessage -SmtpServer <tenant>.mail.protection.outlook.com -To lee@bythepowerofgreyskull.com -From lee@croucher.cloud -Subject "Password Reset : Expired Password" -Body "Your password has expired! Click on the link to reset your password. <a href="https://dodgysite.domain.com/password>Reset Password</a> -BodyAsHtml -Attachments "<payload-file>"
Essential Parameters:
-SmtpServer: The predictable smart host format-To: Target recipient(s)-From: Spoofed sender address - any email address from any domain-Subject: Email subject line-Body: Email content (plain text or HTML)-BodyAsHtml: Enables rich HTML formatting and malicious links-Attachments: Include malicious files (executables, documents, etc.)
Attack Capabilities
Attackers can leverage this vulnerability to send emails that appear to come from any email address, including:
- Internal users for credential harvesting or business email compromise
- External partners or vendors requesting sensitive information
- Well-known service providers (Microsoft, Google, banks) for phishing
- Trusted business contacts for social engineering attacks
The basic PowerShell syntax demonstrates the core vulnerability without authentication requirements.
The attack's sophistication lies in its ability to create emails that are virtually indistinguishable from legitimate communications from any domain. Attackers can craft professionally formatted HTML content, include company branding, attach multiple files, and spoof any sender address - all without requiring any actual access to your systems or the spoofed domain.
Security Impact
This vulnerability enables several attack vectors:
- Phishing Campaigns: Attackers can send credential harvesting emails that appear to come from trusted colleagues, partners, or service providers
- Business Email Compromise: Spoofed communications from executives, vendors, or business partners requesting wire transfers or sensitive data
- Malware Distribution: Emails appearing to come from trusted sources containing malicious attachments or links
- Social Engineering: Trust exploitation through seemingly legitimate communications from any domain
Detection Indicators
Organizations should monitor for these warning signs of these attempts:
Email Header Analysis:
- Missing or incorrect tenant ID cross-references in headers (X-MS-Exchange-CrossTenant-Id mismatches)
- SPF, DKIM, or DMARC authentication failures for domains that should have proper authentication
- Emails that bypass expected mail flow patterns for known senders
Behavioral Anomalies:
- Users apparently sending emails to themselves
- Emails originating from unexpected geographic locations
- Communications with suspicious attachments or urgent financial requests from known contacts
- Messages with grammar or formatting inconsistent with known sender patterns
- Emails showing only the email address without display names - Direct Send messages typically lack the display name formatting that legitimate emails contain
Remediation Steps
Immediate Actions
Enable Reject Direct Send Feature
Set-OrganizationConfig -RejectDirectSend $trueThis blocks unauthenticated Direct Send traffic organization-wide.
What happens when enabled: Any unauthorized Direct Send attempts will be blocked with the error:
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sourcesThe security change propagates across Microsoft's service within 30 minutes of implementation, immediately stopping exploitation attempts while clearly indicating your organization has implemented proper security controls.
Configure Authenticated Connectors For legitimate Direct Send needs, establish partner mail flow connectors that authenticate based on:
- Digital certificates (recommended)
- Specific IP address ranges
- Other secure authentication methods
Using Direct Send for legitimate reasons?
When disabling Direct Send, ensure legitimate services continue functioning by:
- Identifying current Direct Send users through SPF record analysis
- Creating authenticated connector configurations for approved services
- Testing email functionality for printers, applications, and third-party services
Conclusion
The Direct Send vulnerability represents a significant security gap that organizations must address immediately. By implementing the Reject Direct Send feature and establishing proper authentication mechanisms for legitimate use cases, organizations can eliminate this attack vector while maintaining necessary email functionality. Regular monitoring and user education remain critical components of a comprehensive email security strategy.