Mitigating the Microsoft 365 Direct Send Phishing Attack: A Comprehensive Guide

Microsoft 365 tenants across the United States have recently become the focal point of a sophisticated, widespread phishing campaign that leverages a rarely-discussed but highly impactful vulnerability in Exchange Online’s Direct Send feature. Security researchers have confirmed that, since May 2025, the campaign has targeted more than 70 organizations in various industries, stressing the urgency for IT administrators and CISOs to understand this novel attack vector, its operational mechanics, and how it circumvents traditional email defenses.

Anatomy of the Direct Send Attack​

Direct Send is a legitimate Microsoft 365 (M365) capability, primarily intended to allow devices such as multifunction printers, scanners, or on-premise applications to send email internally on behalf of a tenant. Typically, these devices lack full authentication capabilities and benefit from the feature’s ease of use. However, this very design—the absence of strict authentication on the smart host endpoint—has become fertile ground for exploitation.
At the core of the problem is the fact that the smart host (formatted as tenantname.mail.protection.outlook.com) will accept messages from any source, provided the correct recipient addresses and tenant domain are used. Attackers do not require login credentials, compromised accounts, or even advanced persistence—just a publicly discoverable email address and the organization’s domain, both of which are easy to obtain via corporate websites, social media, or through earlier breaches.

Attack Workflow​

• Reconnaissance: Threat actors gather target organization domains and valid email recipients—information typically available through public channels or data breaches.
• Exploitation: Using simple PowerShell commands (for example, Send-MailMessage -SmtpServer company-com.mail.protection.outlook.com -To [email protected] -From [email protected] ...), attackers construct emails that spoof internal users.
• Bypass of Security Controls: Because these messages flow through Microsoft’s protected mail infrastructure, they appear “internal.” Security solutions that emphasize the origin or authentication (e.g., SPF, DKIM, DMARC) are often bypassed, as are filters designed to flag suspicious external originators.
• Phishing Delivery: Classic lures such as “New Missed Fax-msg” or “Caller Left VM Message” combine with enticing attachments (“Fax-msg,” “Caller left VM Message”) or malicious links (such as hxxps://voice-e091b.firebaseapp[.]com) to exploit end-users’ trust in internal communications.

When user behavior analytics and security monitoring tools were deployed by affected organizations, analysts observed the attackers’ reliance on PowerShell and similar command-line tools, and a frequent use of VPN-endpoint or foreign IP addresses—one case notably originated from Ukraine, a clear anomaly for the tenant.

Strengths of the Attack Vector​

Several elements contribute to the exceptional effectiveness of this campaign:

• Authentication Bypass: No credential compromise is necessary; attackers are unauthenticated outsiders, yet can appear as “trusted” internal users.
• Internal Routing Evasion: Messages portrayed as internal can often slip past security controls designed for inbound external mail, such as those enforced by Microsoft Defender for Office 365 or third-party secure email gateways (SEGs) that typically focus on sender domain reputation, authentication results, or external origination.
• Low Technical Bar: Attackers need little more than PowerShell and a valid recipient list. The barriers to entry are minimal, making widespread, automated campaigns feasible with limited resources.
• High Trust Factor: End-users are trained to regard internal messages as safe, increasing susceptibility to phishing, credential harvesting, or malware payloads.

Unpacking the Technical Vulnerabilities​

The root issue lies within the Direct Send architecture and its default trust posture. The smart host for each tenant does not enforce authentication for mail submitted to recipients at the same domain. In practice, this means that anyone—threat actor or otherwise—who knows the domain can spoof internal nicknames or addresses, sending messages that undeniably look “legitimate.”
A thorough review of headers for affected emails typically reveals several red flags, including:

• "Sender IP" fields reflecting unexpected geolocations, often outside usual business operations (e.g., Ukrainian or randomized VPN addresses).
• User agent strings identifying PowerShell or other scripting environments.
• Spoofed "From" headers that match legitimate internal users with no corresponding Microsoft 365 authentication logs.
• Failing SPF, DKIM, or DMARC checks for messages that appear to be internal but originate externally.
• Mismatched tenant IDs in header fields, inconsistent with normal internal workflows.

These discrepancies may only be apparent upon forensic analysis, not through standard, real-time email filtering.

Forensics and Indicators of Compromise (IoCs)​

Security teams investigating incidents tied to this campaign have identified several tangible IoCs, critical for defenders to integrate into their detection frameworks:

• IP Addresses: Many attack emails originated from ranges such as 139.28.36[.]230 (and wider 139.28.X.X space).
• Suspicious Domains: Credential phishing hosts such as hxxps://voice-e091b.firebaseapp[.]com and hxxps://mv4lh.bsfff[.]es have appeared in message links.
• Subject Line Patterns: Consistently, messages include phrases like “Caller Left VM Message Duration-XXX...,“ “New Missed Fax-msg,” “(2 pages) Fax-Msg,” or “Fax Received: Attached document for review REF.”
• Attachments: Filenames referencing “Fax-msg,” “Caller left VM Message,” or “Listen;” file types often attempt to mask malware as legitimate voice or fax transmission.
• Email Behavior: Unusual sending patterns such as users emailing themselves, command-line agent headers, and absence of authentication logs.

Why Have Existing Defenses Fallen Short?​

Most modern email security postures—whether based on Microsoft’s native Defender suite or third-party mail gateways such as Proofpoint, Mimecast, or Barracuda—prioritize controlling and filtering external-to-internal traffic. Smarter filters include reputation data, IP origin, SPF alignment, and behavioral analysis. However, the Direct Send attack bypasses all of these by routing messages through Microsoft’s trusted “internal” system pathways.
In interviews and published investigations, security consultants repeatedly stress that organizations often lack robust detection for East-West (internal to internal) traffic. Instead, controls are overwhelmingly weighted toward perimeter or inbound boundary monitoring.
Moreover, if a device or service should be using Direct Send (such as a legitimate printer), blacklisting or disabling the feature enterprise-wide is rarely an option. Many organizations depend on this functionality for genuine business continuity, meaning that fully disabling Direct Send is, at best, a blunt instrument—with adverse operational impact.

The Response: Detection, Mitigation, and Threat Hunting​

Recognizing that outright disabling Direct Send is impractical for many, the cybersecurity community is now emphasizing a combination of advanced monitoring, alert triage, and layered policy controls to mitigate this threat. Key recommendations include:

• Augmented Monitoring and Alerting
• Centralize and actively monitor message trace logs, focusing on sender/recipient anomalies, command-line user agent flags, and geolocation mismatches.
• Correlate email activity with sign-in events; emails sent with no corresponding authentication may indicate Direct Send abuse.
• Track emails with headers indicating external origination routed through internal smart hosts—even when destined for internal recipients.
• Refined Detection Rules
• SIEM/SOAR platforms should be updated with custom rules to raise alerts when messages are sent to/from internal domains but originate from unusual IPs.
• Heavier reliance on behavioral baselines: users routinely sending themselves faxes or voice messages should be scrutinized if the pattern deviates from the norm or coincides with VPN/foreign IP usage.
• Re-examine Email Security Policies
• Tighten policies that determine which IPs, devices, or service accounts can legitimately use Direct Send; consider restricting based on approved network segments or known application fingerprints.
• Analyze the necessity and legitimacy of Direct Send setups in your environment—minimize exposure to only those printers/services that genuinely require it.
• User Training and Awareness
• Amplify education efforts regarding the risks of “internal” phishing. Make clear that even emails appearing to come from coworkers or internal addresses can be suspicious, particularly messages with urgent CTAs or common lure subject lines.
• Engage with Microsoft and Third-Party Vendors
• Organizations should provide feedback to Microsoft regarding the need for more granular authentication or at least conditional access controls on the Direct Send protocol.
• Coordinate with email security vendors to ensure they deploy updated heuristics for detecting internally abused smart host traffic.

Critical Analysis: Architectural Flaw or Acceptable Risk?​

While the ability to send unauthenticated email within a closed system might seem innocuous—perhaps even desirable for legacy device compatibility—the Direct Send abuse highlights a deeper architectural challenge: how to balance interoperability with zero trust security principles.

Notable Strengths of Direct Send (When Used Properly)​

• Operational Simplicity: Allows legacy and “dumb” devices—those without OAuth or SMTP authentication support—to send business-critical notifications.
• Continuity for Automation: Supports automated processes and internal applications that are difficult to re-engineer for modern authentication.
• Facilitates Integration: Enables seamless delivery of service-generated emails or alerts, including for applications outside the Microsoft 365 ecosystem.

Risks and Shortcomings​

• Zero Trust Erosion: The feature assumes that anyone targeting the smart host with the correct formatting is plausibly internal; there is no client verification.
• External Abuse Opportunity: The attack does not require inside access, making initial breach efforts trivial.
• Detection Complexity: Most organizations have not built out or tuned alerting for internal messaging abuses, leading to longer dwell times and higher risk of damage pre-detection.

The security community is divided over the lasting acceptability of this risk. Some argue that the operational benefits outweigh the now-proven threats, especially if organizations quickly pivot to enhanced monitoring and tailored controls. Others posit that any unauthenticated pathway—especially those that grant messages “internal trust”—represents an anachronism incompatible with best-practice, zero trust architectures.

The Importance of Holistic Email Security​

Recent events serve as a stark reminder that email security is never “set and forget.” Attackers consistently identify, weaponize, and exploit forgotten or niche system features, especially those outside the standard defensive focus.
To defend against such campaigns, organizations must:

• Map All Email Entry/Exit Points: Know every legitimate route into and out of the mail ecosystem, not just perimeter connections.
• Audit Internal Trust Boundaries: Consistently reassess what it means to be “trusted” within the tenant; internal ≠ safe.
• Leverage Threat Intelligence: Keep abreast of emerging IoCs and TTPs (Tactics, Techniques, and Procedures) relevant to current campaigns. Proactively feed these into detection infrastructure.
• Review and Harden Intra-Tenant Communications: Where possible, enable authentication, restrict sender IPs, and segment usage to only what is absolutely necessary for business function.

The Way Forward: Recommendations for Security Teams​

As remediation and long-term strategy steps, practitioners should be prepared to:

• Document and Verify All Devices Using Direct Send: Create a full inventory of applications and devices leveraging the feature. Remove or retrofit those that don’t require it.
• Restrict Smart Host Access: Use network access controls or firewall rules to severely limit which on-premise IPs or subnets can reach the Direct Send smart host.
• Explore Alternatives: Where feasible, transition devices and applications to authenticated SMTP (using OAuth or Modern Auth)—particularly as Microsoft continues to deprecate legacy auth mechanisms.
• Monitor, Iterate, Educate: Regularly review system and user behavioral logs for anomalies, update training based on latest phishing themes, and respond quickly to reports of anomalous “internal” mail.

Conclusion​

The rapid spread and impact of the Direct Send phishing campaign highlight a perfect storm: a technical feature built for business convenience, repurposed by attackers for phishing and credential theft—exploiting both technological blind spots and user trust. This campaign should serve as a clarion call for organizations: internal communications can no longer be assumed safe and should be scrutinized just as stringently as external threats.
CISOs, admins, and defenders must remain vigilant against both novel and “known but forgotten” attack vectors, adjusting controls and strategies as attackers shift their focus. Ultimately, embracing a true zero-trust mindset—where every communication is suspect until proven safe—remains the most effective blueprint for organizational resilience, no matter what new Microsoft 365 vulnerability tomorrow’s attackers might seek to exploit.

---

Source: CyberSecurityNews Microsoft 365's Direct Send Exploited to Send Phishing Emails as Internal Users