Microsoft 365 Direct Send Exploited in Major Phishing Campaign: How to Protect Your Organization

Few security challenges expose both the evolving sophistication of cybercriminal tactics and the unintended weaknesses of enterprise cloud platforms as starkly as the recent abuse of Microsoft 365’s “Direct Send” feature. In a rapidly intensifying phishing campaign discovered in May 2025, threat actors targeted more than 70 organizations—predominantly in the United States—by exploiting a feature meant for legitimate business communications, effectively bypassing robust email security measures with alarming ease. This article unpacks the mechanics of Direct Send, examines the scope and specifics of the campaign, analyzes Microsoft’s and the security community’s response, and considers the implications and necessary steps for organizations worldwide.

Understanding Microsoft 365's Direct Send Feature​

Microsoft 365 has become synonymous with flexible, scalable cloud communication, connecting teams and automating critical workflows. An integral part of this landscape is the “Direct Send” function, designed to let on-premises devices and applications—such as scanners, printers, or custom software—send email through the organization’s authenticated smart host. For IT administrators and workflow engineers, the feature promised a seamless bridge between legacy hardware and cloud-based messaging, sidestepping the need for complex re-architectures.
At its core, Direct Send allows these devices to dispatch messages as if they originated from an internal address, typically using the format “[device]@[company.com]” through the tenant's mail-protection gateway (e.g., company-com.mail.protection.outlook.com). Crucially, it requires no authentication for the sending entity: as soon as a device or script connects to the smart host, the system implicitly trusts and processes the outbound message as internal traffic.

Why Direct Send Was Created—and the Hidden Risks​

Direct Send was intended to solve a practical problem. Many organizations, especially those with complex infrastructures, have legacy devices that can’t easily be reprogrammed for SMTP authentication or OAuth-based modern cloud protocols. Removing the password requirement for these devices seemed, until recently, like a necessary compromise—especially when an internal network perimeter was assumed.
However, the move toward hybrid and cloud-first operations has eroded those perimeters. With the growing prevalence of remote work, API-driven automation, and cloud networking, the once-sensible trust model underpinning Direct Send is increasingly fragile. As security researchers have long warned, any system feature that bypasses authentication—even for ostensibly internal roles—represents a potent attack vector when configuration or monitoring lapses arise.

How the Phishing Campaign Unfolded​

In May 2025, analysts at Varonis’ Managed Data Detection and Response (MDDR) team began to notice unusual email flows in numerous organizations, soon tracing the activity to a single, highly coordinated phishing operation. More than 70 companies came under attack, with over 95% of victims based in the United States and the bulk operating in Financial Services, Manufacturing, Construction, Engineering, Healthcare, and Insurance.
The attackers’ MO was both clever and insidious. Harnessing PowerShell scripts, they sent messages through the victims’ own smart hosts—servers at addresses like company-com.mail.protection.outlook.com. These servers, by design, would accept any unauthenticated email from any source claiming to be internal. By sending messages “from” employees’ actual addresses, but originating from external, often foreign, IP addresses, the attackers achieved several goals:

• Impersonation: Emails looked indistinguishable from genuine, internal corporate messages, with sender and recipient addresses matching legitimate formats (e.g., joe@company.com).
• Bypassing Filters: Because Direct Send traffic is treated as internal and SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance) checks are not enforced on this channel, many defensive mechanisms were rendered moot.
• Evading Authentication Requirements: The reliance on "trusted" smart hosts enabled unauthenticated external actors to inject messages straight into inboxes.

A typical attack chain exploited PowerShell like so:
Send‑MailMessage -SmtpServer company‑com.mail.protection.outlook.com -To [email]joe@company.com[/email] -From [email]joe@company.com[/email] -Subject "New Missed Fax‑msg" -Body "You have received a call! Click on the link to listen to it. Listen Now" -BodyAsHtml
The approach left minimal trace besides the originating IP (such as 139.28.36[.]230 from Ukraine or 51.89.86[.]105) and the recipient’s logs.

Anatomy of the Fake Voicemail Lure​

Phishing campaigns thrive on social engineering, and this operation added an original twist: rather than embedding malicious links directly in email or PDFs, the attackers attached branded PDF files that urged recipients to scan a QR code with their smartphone. The files bore legitimate-looking company logos and filenames like ‘Fax-msg’, ‘Caller left VM Message’, ‘Play_VM-Now’, or ‘Listen’, with subject lines such as "Caller Left VM Message" or "New Missed Fax‑msg".
This multi-stage process had several strengths:

• Bypassing Security Gateways: Many spam filters are configured to scan links in email bodies or attached PDFs for indicators of phishing. By avoiding clickable links and instead relying on QR codes, the attackers circumvented much of the static and behavioral analysis meant to protect users.
• Social Engineering Under the Radar: QR codes are less likely to be scrutinized by automated security measures. Employees, eager not to miss a business-critical voicemail, might scan the code with a smartphone, potentially outside the computer's security perimeter, increasing the chance of credential harvesting.
• Credential Theft: The phishing website behind the QR code typically presented a convincing Microsoft login page, designed to harvest Office 365 credentials that could be used for further compromise or resale.

The layered tactic—masquerading as internal, leveraging trusted workflow notifications, and exploiting cross-device user behavior—dramatically improved the campaign’s success rates.

Why Traditional Defenses Failed​

The campaign’s effectiveness can be directly traced to the interplay of trust assumptions and gaps in existing protections:

• SPF, DKIM, and DMARC Limitations: Organizations often rely on these protocols to authenticate message origins. Direct Send, however, bypassed these checks entirely. Even though emails originating from atypical IPs failed SPF or DMARC, the fact that they traversed the organization’s official smart host convinced Exchange Online and other systems to treat them as safe.
• Internal Email Blind Spots: Corporate environments often apply less scrutiny or raise lower alarms for emails flagged as internal. Security professionals may focus anti-spam and quarantine policies on external senders, allowing privileged lateral movement for anything appearing “intra-company.”
• Smart Host Misconfiguration: Microsoft’s own guidance long recognized the dangers of incorrect configuration for Direct Send. For advanced admins prepared to tightly restrict incoming traffic, the risks could be minimized. Yet, complex environments and staff turnover often left these endpoints exposed.

Microsoft’s Response and Mitigation Efforts​

Microsoft has historically been aware of Direct Send’s risk profile, recommending its use only for “advanced customers willing to take on the responsibilities of email server admins.” Specifically, the company notes, “You need to be familiar with setting up and following best practices for sending email over the Internet. When correctly configured and managed, Direct Send is a secure and viable option. But customers run the risk of misconfiguration that disrupts mail flow or threatens security.”
In April 2025, Microsoft introduced a new “Reject Direct Send” toggle in the Exchange Admin Center, allowing admins to block unauthenticated Direct Send attempts outright. This feature, still in public preview at the time of this writing, was a direct response to the inability of SPF, DKIM, or DMARC hardfail policies to reliably block internal spoofing without risking legitimate mail delivery failures. Microsoft previously recommended SPF soft-fail (“~all”) precisely because aggressive blocking could disrupt valid routing scenarios—an uneasy compromise now exposed by this attack.
Though disabling Direct Send is as simple as toggling the “Reject Direct Send” setting, the practical challenge for many enterprises lies in identifying and updating every system and device that depends on the feature. Legacy scanners, line-of-business apps, or even contract manufacturing systems might silently break if the smart host channel is summarily closed.

Varonis’ and Industry Best Practices​

Beyond Microsoft’s direct recommendations, the security and risk management community has issued a suite of urgent guidance in the wake of the attack:

• Implement Strict DMARC Policies: Moving from a “none” or “quarantine” stance to a full “reject” policy (p=reject) can help mitigate spoofing across the board, though it requires careful analysis to avoid unintended routing failures.
• Flag or Quarantine Unauthenticated Internal Messages: Even messages appearing to originate within the organization should be subject to authentication and anomaly detection, especially when traveling through paths typically reserved for external communications.
• Enforce SPF Hardfail Where Possible: For critical domains or systems, increasing the strictness of SPF evaluation may yield added safety, but with potentially disruptive side effects.
• Enable Advanced Anti‑Spoofing and Anomaly Detection: Exchange Online Protection and other email security gateways can be tuned for more aggressive anti-spoofing, monitoring for sender-recipient address pairings, unexpected geographies, or odd device fingerprints.
• User Education and QR Phishing Awareness: Regular training—especially around unexpected QR codes, links, or requests for credentials—is vital. Employees should recognize that, in the modern threat landscape, even internal-looking emails may be compromised.
• Monitor for Indicators of Compromise (IOCs): Varonis and others have published lists of malicious domains, IPs, and behavioral fingerprints to help organizations rapidly detect and respond to suspected abuse.

The Attacker’s Playbook: Adaptability and Escalation​

Several aspects of this phishing campaign raise the stakes for defenders:

• Out-of-Band Techniques: By leveraging device-agnostic workflow lures (e.g., “Play Voicemail” PDFs) and migrating the credential theft process onto users’ smartphones, adversaries evade many endpoint and network defenses.
• Living Off the Land: The abuse of PowerShell, combined with non-malicious infrastructure (legitimate smart hosts), makes investigations and attribution difficult. These campaigns often blend seamlessly with normal business operations until too late.
• Industry-Agnostic Targeting: While the attackers focused on highly regulated sectors (finance, healthcare, manufacturing), their tooling could easily be turned against any organization using Microsoft 365 with Direct Send enabled and insufficiently monitored.

Critical Analysis: Strengths and Weaknesses in the Response​

The response from the Microsoft ecosystem, while brisk, surfaces some enduring tensions:

• Strengths:
• Rapid Mitigation Deployment: The introduction of the “Reject Direct Send” control and proactive communication reflect a welcome shift toward secure-by-default cloud operations.
• Transparency and Community Engagement: Both Microsoft and security research partners like Varonis have shared detailed IOCs, technical indicators, and practical remediation steps, empowering defenders at every level.
• Educational Pivot: The speed with which organizations have incorporated QR code phishing into awareness training is encouraging.
• Weaknesses and Ongoing Risks:
• Reliance on User Configurations: The effectiveness of mitigations still depends on the sometimes opaque, decentralized practices of IT, especially in sprawling multitenant or hybrid cloud environments.
• Legacy Device Dependency: Many companies cannot quickly or safely decommission Direct Send-reliant devices and applications, leaving an uncomfortable exposure window. Transition plans to modern, authenticated SMTP or OAuth-based relay solutions must be prioritized.
• Attackers’ Next Moves: With the playbook now exposed, attackers will almost certainly probe for subdomains, shadow IT mail relays, or exploit residual Direct Send paths in mergers, acquisitions, or recently migrated environments.

The Broader Lessons: Trust, Zero Trust, and the Future of Cloud Messaging​

Perhaps the most enduring takeaway from this campaign is the erosion of the “inside is safe” ideology. In cloud-first, perimeter-less environments, every internal channel represents a potential risk if not actively authenticated, monitored, and risk-scored. While features like Direct Send were conceived with benign internal networks in mind, today’s threat actors reliably exploit implicit trust wherever it resides.
This attack also underscores the need for aggressive zero-trust policies for messaging—authenticating not only user logins but every system, device, and email relay. This means inventorying legacy devices, implementing strong device identity, and shifting toward cloud-native workflow tools that are designed with security in mind.

Actionable Steps for Organizations Using Microsoft 365​

For business and technical decision-makers, the path forward is clear but not always simple.

• Review and Audit Direct Send Usage: Identify all printers, devices, and systems dependent on the feature. Quantify the business impact of disabling or restricting Direct Send.
• Enable “Reject Direct Send” Where Feasible: Microsoft’s new setting offers a robust, low-effort protective layer for environments able to discontinue unauthenticated relay.
• Tighten Authentication and Monitoring: Mandate SPF, DKIM, and DMARC hardfail wherever business continuity permits; monitor logs for failed or unauthenticated traffic, even from internal IPs.
• Train, Test, Simulate: Incorporate scenarios involving internal spoofing, PDF lures, and QR phishing into security training and regular phishing simulations.
• Plan for Device Modernization: Sunset unsupported or unupdateable line-of-business appliances. Move toward cloud-native, authenticated solutions.
• Collaborate Across Departments: Security is more than IT's task; legal, compliance, procurement, and line-of-business leaders must be engaged in prioritizing email trust and safety.

The Final Word: Secure Foundations in a Changing World​

This campaign’s success—drawing upon a blend of technical misconfiguration, psychological manipulation, and infrastructural complexity—serves as a sobering reminder: in the race to modernize workplace tech, security fundamentals must never be left behind. Features like Microsoft 365’s Direct Send were built for a different era; administrators must embrace a posture of proactive vigilance, not reactive firefighting.
For those leveraging Microsoft 365 or any major cloud platform, the imperative is clear: audit all trust boundaries, lock down legacy pathways, demand and verify authentication for every transaction, and commit to a culture of constant vigilance and awareness. As phishing campaigns get smarter, organizations must work systematically to ensure that features created for convenience never become conduits for catastrophe.

---

Source: BleepingComputer Microsoft 365 'Direct Send' abused to send phishing as internal users