How Microsoft 365’s “Direct Send” Feature Becomes a Phishing Attack Vector

Sophisticated cybercriminals have recently demonstrated yet another way to exploit trust in internal communications—this time, by leveraging a Microsoft 365 feature originally intended for convenience. The Varonis Managed Data Detection and Response (MDDR) forensic team has uncovered a striking phishing campaign that uses Microsoft’s “Direct Send” function to deliver spoofed emails that appear to originate within an organization, all without requiring account compromise, stolen credentials, or malware. This revelation highlights a critical blind spot in cloud-based security posture and offers a cautionary tale for enterprises relying on Microsoft 365 as their primary communication and collaboration environment.

Inside the Attack: How “Direct Send” Becomes a Threat Vector​

Microsoft 365’s Direct Send feature was designed with a simple goal: to make it easier for devices like printers, scanners, and internal apps to distribute notifications or reports via email within a single tenant—without requiring device authentication. By connecting to a tenant-specific smart host, for example, tenantname.mail.protection.outlook.com, these devices could directly send messages into a company’s internal user inboxes.
The vulnerability arises from the very nature of its design: Direct Send requires neither username nor password. If a user or device connects from a public IP address, correctly identifies the tenant’s domain, and guesses a valid internal email format, they can distribute emails masquerading as legitimate internal communications. No account needs to be compromised; no credentials need to be stolen. A basic PowerShell script and a public IP are all that’s needed to launch the attack.
Security researcher Michael Solomon at Varonis summarizes the threat: “The simplicity of this attack is what makes it so dangerous. You don’t need credentials, malware, or even access to the target environment. All you need is a public IP and a basic PowerShell script.”

Anatomy of the Campaign: From Ukraine to U.S. Enterprises​

Since May 2025, this phishing operation has targeted over 70 organizations, predominantly in the United States, according to Varonis forensic findings. Threat actors pinpointed probable tenant email formats (such as [email protected]) and orchestrated attacks from foreign IPs, including Eastern European sources like Ukraine. The forensic connection was pinned down through similarities in sender IP addresses, messaging behavior, and content.
What’s particularly menacing is that since these emails route through Microsoft’s infrastructure, they often evade conventional email filters. Even though they fail critical authentication checks such as SPF, DKIM, and DMARC, Microsoft may treat them as internal-to-internal messages, especially within the same tenant. That dramatically increases the rates of delivery and the likelihood users will trust and interact with them.
The attackers’ tool of choice? The humble PowerShell script. This tool is used to automate delivery, mimicking believable messages such as “New Missed Fax-msg” or “Caller Left VM Message.” Nearly all the emails analyzed came with PDF attachments, frequently disguised as internal voicemails, which were embedded with QR codes (“quishing” attacks) that redirected victims to credential-harvesting sites. This method combines classic phishing tactics with social engineering, exploiting not only technical blind spots but also human trust in what appear to be routine internal communications.

Technical Deep Dive: Why Filters Fail​

At the heart of this issue are multiple overlapping security and usability gaps:

• No authentication required: Direct Send does not require credentials. Any internet-facing system can attempt to send messages as an internal user.
• Emails appear internal: By sending mail from within the organization’s own infrastructure, the phishing emails inherit a false sense of legitimacy.
• Authentication checks fail but may not block delivery: Despite the fact these emails fail SPF, DKIM, and DMARC, Microsoft systems occasionally route them as legitimate internal messages.
• Filter reliance on sender context: Many email security solutions rely on sender authentication, domain reputation, or external-to-internal routing cues; with Direct Send, these signals are absent or misleading.

Varonis highlights several ways to detect attacks that exploit Direct Send:

• Scanning message headers for external IPs sending internal mail
• Identifying failed authentication steps (SPF, DKIM, DMARC)
• Tracing PowerShell-based sending patterns
• Watching for messages sent from a user to themselves or from unexpected geolocations

According to both the Varonis report and analysis by TechWorm and other independent researchers, the abuse of this feature exposes a common blind spot across organizations that assume internal correspondence can always be trusted.

Critical Analysis: Microsoft 365 Feature or Flaw?​

On one hand, Direct Send solves a genuine business need: it streamlines how printers, scanners, or internal ERP systems send emails—especially in environments with thousands of users and many unmonitored devices. It’s an example of a powerful, flexible cloud feature.
Yet, that very flexibility is its Achilles’ heel. APIs and relay features that operate without authentication are inherently risky in the modern age of cloud identity. The ability to spoof any internal user without so much as a login represents a fundamental misalignment between security best practices and the need for backward compatibility with legacy devices.
Microsoft’s documentation warns administrators to restrict and monitor relay and send permissions, but many organizations overlook these recommendations or lack the resources for continuous auditing. As a result, a feature meant for operational efficiency becomes a stealthy vector for social engineering attacks.

Notable Strengths of Attackers’ Approach​

• Zero need for compromise: No credentials or malware requirement short-circuits many detection frameworks.
• Low technical skill required: A simple PowerShell script can automate the attack.
• Infrastructure trust: By leveraging Microsoft’s own infrastructure, malicious messages evade warnings and bans often triggered by foreign domains.
• Flexible decoy options: Attackers can mimic a range of legitimate notifications—missed calls, faxes, internal warnings, etc.—increasing the chances of a successful phishing attempt.

Key Risks and Weaknesses​

• Reliance on format guessing: Attackers must accurately guess the organization’s email pattern, though formats like firstname.lastname or firstinitiallastname are often trivial to deduce via LinkedIn or public staff directories.
• Detection through header and network analysis: Security-aware organizations scrutinizing header origination and IP geolocation can spot anomalies.
• Failed authentication markers: Though sometimes ignored by default rules, failed SPF/DKIM/DMARC are still red flags to advanced tools or proactive administrators.

Defensive Measures: How to Harden Microsoft 365 Against Direct Send Abuse​

Given the alarming simplicity and potential reach of this phishing vector, a layered defense strategy is essential. Varonis and other security organizations recommend several practical steps:

1. Enable “Reject Direct Send” in Microsoft Exchange Admin Center​

Microsoft allows organizations to configure their tenants to reject emails sent through Direct Send that lack proper authentication. Activating this setting is a high-impact, low-effort action that immediately reduces the attack surface.

2. Implement Strict DMARC Policy​

A DMARC policy of ‘p=reject’ instructs receiving mail servers to reject emails that fail authentication. Organizations should ensure that DMARC, along with underlying SPF and DKIM records, are rigorously configured, and that exceptions are tightly controlled.

3. Quarantine or Flag Unauthenticated Internal Messages​

Configure email filtering policies to quarantine or at least flag any message that appears internal but fails SPF/DKIM/DMARC authentication. This is especially vital for messages sent from questionable or foreign IP addresses.

4. Enforce SPF “Hardfail” and Anti-Spoofing Policies​

Use Exchange Online Protection (EOP) to enforce strict SPF “hardfail” (–all in SPF record) and enable anti-spoofing policies. These will ensure that across-the-board, only explicitly authorized IP addresses can send mail on behalf of the organization’s domain.

5. Educate Employees on Phishing and “Quishing”​

Staff should be made aware that not all internal-looking emails are trustworthy. Training should include warnings about QR code-based phishing (“quishing”), as PDFs with QR codes have become a popular method for bypassing URL and attachment filters.

6. Monitor for Anomalous Email-Sending Behaviors​

Security teams should set up monitoring for self-addressed messages, PowerShell-sent mail, and inbound email from IP addresses outside those normally seen in the organization’s geography or network profile.

7. Enforce Static IP in SPF Records​

Whenever possible, restrict SPF records to static IPs. This optional but recommended measure limits who can legitimately send internal emails and reduces the risk posed by misconfigured devices or shadow IT.

Quick Checklist for Microsoft 365 Tenants​

The Bigger Picture: Zero Trust for Internal Communications​

This incident is a startling reminder that perimeter-centric defenses and implicit trust in anything “internal” are no longer sufficient. Trends like remote work, Bring Your Own Device (BYOD), and complex SaaS ecosystems mean that attackers are adept at abusing features once presumed secure due to internal-only access.
Adopting a Zero Trust model—in which all users, devices, and messages are continuously vetted regardless of source—is a rapidly emerging best practice. Within Microsoft 365, this means more than just enabling multi-factor authentication or email encryption. It requires:

• Rigorous monitoring of administrative settings and exceptions
• Detailed event logging and regular header reviews
• Proactive threat intelligence and rapid automation around suspicious observations

Microsoft and the Road Ahead​

Microsoft has consistently updated its documentation to highlight potential misconfigurations and offers both technical controls (such as conditional access, device management, and threat analytics) and best practice policies. However, the distributed nature of responsibility in many organizations—where IT, security, and business groups have shared but sometimes ill-defined oversight—can lead to dangerous gaps.
Cloud platforms must continue evolving tenant-level controls to allow granular, dynamic management of legacy features like Direct Send. More importantly, default configurations should err on the side of caution, especially for customers who may not have the resources for 24/7 incident response or forensics.

Conclusion: Trust, But Verify—And Act Now​

As the line between “internal” and “external” blurs in the cloud era, enterprises must recognize that attackers will exploit any trust or convenience feature left unguarded. The abuse of Microsoft 365’s Direct Send proves that even benign-seeming administrative functions can morph into major security blind spots.
All organizations using Microsoft 365 should immediately evaluate their Direct Send configurations, scrutinize internal email delivery pathways, and engage staff in meaningful security awareness programs. With phishing continuing to account for the majority of initial access breaches, proactive defense and rapid detection can make the difference between a near-miss and a devastating data loss event.
To paraphrase the closing recommendation from Varonis: “Don’t assume internal means safe. If you’re not actively monitoring spoofed internal emails or haven’t enabled these protections, now is the time.” Being one step ahead of adversaries means understanding your environment’s features as both assets and potential attack vectors—and acting decisively before threat actors do.

---

Source: TechWorm Hackers Exploit Microsoft 365 Feature To Send Phishing Emails