Exposing the Hidden Threat of Microsoft 365's Direct Send Abuse in Internal Phishing Campaigns

Leveraging trusted internal channels has long been a gold standard for cybercriminals seeking to evade organizational defenses, but a recent campaign uncovered by Proofpoint signals a new level of ingenuity in exploiting a familiar Microsoft 365 feature: Direct Send. This functionality, designed primarily for allowing multifunction printers and legacy on-premises applications to relay messages to internal users without full authentication hurdles, now finds itself at the center of an escalating cyber threat landscape.

Anatomy of the Attack: Exploiting Direct Send​

Microsoft 365’s Direct Send is an often-overlooked feature that permits devices and line-of-business apps to direct SMTP messages to corporate tenants without the sender verifying themselves, provided the recipient is an internal address. On paper, this supports operational convenience, especially for printing and scanning workflows. In practice, however, it’s a loophole that has recently been weaponized in striking fashion.
Proofpoint’s analysis describes a campaign where threat actors start by connecting to virtual hosts on Windows Server 2022 machines via Remote Desktop Protocol (RDP) through the typical entry point of port 3389. Once in, they initiate SMTP connections to third-party, and crucially, poorly secured email security appliances provided by regional Infrastructure-as-a-Service (IaaS) vendors.
These compromised appliances are not just a pass-through: They effectively act as relays, bridging communications between attacker-controlled infrastructure and Microsoft tenants. The technical sophistication is apparent: Valid DigiCert SSL certificates secure the front-end of these SMTP services, with support for encrypted authentication mechanisms like AUTH PLAIN LOGIN with STARTTLS. However, a deeper probe into secondary ports—8008, 8010, 8015—reveals expired or self-signed certificates, suggesting that while attackers are keen to appear legitimate, operational shortcuts and resource constraints occasionally betray their presence.
What’s particularly alarming is the attackers’ strategy of using spoofed internal sender addresses, making outbound phishing emails appear as though they originated from within the tenant’s own environment. Even when Microsoft’s composite authentication technology correctly flags many of these for “compauth=fail”—meaning composite authentication check failed—the emails bypass strict rejection. Instead, they end up in user junk folders, remaining accessible to those who might fish through, looking for missed communication.

Social Engineering 2.0: The Power of Internal Trust​

What differentiates this campaign is its manipulation of implicit organizational trust. Most users are trained to scrutinize external emails, but psychologically associate internal mail with authenticity and urgency. Initial lures observed in this campaign reflect this paradigm:

• Task reminders with specific dates (“Your-to-do-List/MM/DD/YYYY”).
• Payment and wire transfer prompts (“Payment ACH-Wire Authorization”).
• Voicemail notifications referencing what looks like call records (“WIRELESSCALLER (XXX)YYY-ZZZZ-MM/DD/YYYY”).
• General reminders crafted to resemble automated business intelligence or scheduling tools (“Daily Reminder: Today’s Tasks – MM/DD/YYYY”).

By mimicking the cadence of everyday business operations, adversaries boost the likelihood that users will interact—click links, enter credentials, or download malware-laden attachments.

Impact: Undermining Security and Organizational Morale​

The consequences extend beyond the immediate risk of credential theft or malware deployment. Once users realize that authentic-looking internal messages are potentially dangerous, the ripple effect is a loss of trust. Collaboration stalls when staff question every internal alert, impeding productivity and morale. Over time, this campaign could breed widespread “alert fatigue,” where genuinely urgent business requests are met with suspicion or ignored.
It’s not only a technical breach; it’s a psychological campaign against the operational backbone of the modern enterprise.

Modern Cloud, Old Risks: Why Legacy Features Create Contemporary Headaches​

The core vulnerability lies in a design philosophy rooted in older architectures, where perimeter defenses and static device rosters dictated trust models. Microsoft’s Direct Send, intended to enable backward-compatible workflows, now finds itself outpaced by the realities of contemporary cloud and hybrid threats.
A key concern highlighted by Proofpoint is the lax posture many organizations maintain regarding SMTP relay settings. Threat actors exploit what should be tightly controlled features—unsecured relays, lenient authentication, and open ports—using tactics that blend the old (phishing, spoofing) with the new (cloud-hosted proxies, SSL-certified infrastructure, automation).

The Digicert Deception: Certificates as a Cloak​

Analysts noticed the use of valid DigiCert SSL certificates on compromised SMTP appliances. This is noteworthy because DigiCert is one of the most trusted names in certificate authorities, and their certificates are used by enterprises seeking to assure users of secure connections.
While most users won’t examine the server certificate chain, security solutions may be less likely to flag communication when valid SSL is detected. This ruse imparts an illusion of safety, aiding in bypassing superficial security checks. However, the lower-level ports later revealed expired or self-signed certificates, possibly for attackers’ operational convenience, staging, or to support other (potentially malicious) lateral movement within the compromised environment.

Microsoft’s Authentication Fails: The “compauth=fail” Loophole​

It’s important to dissect why these attacks, even when detected as spoofing attempts (with messages tagged “compauth=fail”), are still delivered—albeit to junk mail folders. Microsoft’s email hygiene system relies on a composite approach, factoring DMARC (Domain-based Message Authentication, Reporting & Conformance), DKIM (DomainKeys Identified Mail), and SPF (Sender Policy Framework) results. Yet, unless explicit organizational rejection policies are set, even clearly malicious messages may slip through to users.
This issue highlights the importance of aligning technical defense-in-depth policies with active enforcement—not just monitoring and alerting. Moreover, organizations relying solely on Microsoft’s default protections risk exposing users to preventable attacks.

Security Recommendations: Going Beyond Defaults​

Proofpoint’s recommendations underscore the urgency of moving beyond “security by default” to active hardening and visibility:

• Audit Direct Send Usage: IT teams should rigorously review where and how Direct Send is enabled inside their environments. Disabling this functionality organization-wide is possible using PowerShell (Set-OrganizationConfig -RejectDirectSend $true), with exceptions for devices and apps requiring explicit, well-controlled access.
• Review Unauthenticated Relay Settings: Administrators must scrutinize mail flow rules and relay IP addresses, closing doors to unauthenticated external mail streams.
• Enforce Advanced Authentication Protocols: Adopting strict implementation of SPF, DKIM, and DMARC—linked to robust reject or quarantine policies—is essential. For cloud-savvy attackers, only reject policies reliably prevent spoofed or malformed messages from entering mailboxes.
• Monitor Message Headers: Consistently inspect delivery headers for warning signs, including “compauth=fail,” and incorporate these insights into threat-hunting and alert frameworks.
• Deploy Advanced Security Solutions: Supplementing built-in Microsoft 365 protections with third-party, AI-powered email security tools can bridge gaps in detection and response, especially as actors use automation and cloud infrastructure.
• Secure Application-Generated Email: Where printers or apps must send mail, use authenticated, single-purpose mailboxes with locked-down permissions and strict IP whitelisting.

Indicators of Compromise (IOCs): Key Technical Clues​

System administrators and network defenders should be alert for the following IOCs, as outlined by Proofpoint and corroborated by additional threat intelligence feeds:

Type	Value
SSL Subject	CN=WIN-BUNS25TD77J (self-signed by attacker)
IP Address	163.5.112[.]86 (SMTP host)
IP Address	163.5.160[.]28 (SMTP host)
IP Address	163.5.160[.]119 (SMTP host)
IP Address	163.5.160[.]143 (SMTP host)
IP Address	163.5.169[.]53 (SMTP host)

Observed phishing lures may appear as:

• “Your-to-do-List/MM/DD/YYYY”
• “WIRELESSCALLER (XXX)YYY-ZZZZ-MM/DD/YYYY”
• “Payment ACH-Wire Authorization”
• “Daily Reminder: Today’s Tasks – MM/DD/YYYY”
• “Reminder – To Do – MM/DD/YYYY”

These indicators provide essential leads for threat hunting and forensics teams working to detect persistence, lateral movement, or recurring attacks.

Broader Trends: The Rise of Internal Phishing​

This Direct Send abuse campaign is part of a discernible shift in attack methodology: Adversaries increasingly use legitimate cloud services (Microsoft 365, Google Workspace, etc.) as springboards to circumvent external filtering and embed themselves within victim organizations. According to multiple independent analyses—including recent reports from Proofpoint, Palo Alto Networks, and Cybersecurity & Infrastructure Security Agency (CISA)—the rate of “internal phishing” or “lateral phish” attacks leveraging trusted platforms has sharply risen over the last 12 months.
Why is this happening? Cloud adoption blurs the line between “internal” and “external”—and attackers capitalize on organizations’ trust in their sanctioned platforms. Most legacy defenses still focus on filtering mail from outside domains, underestimating the risk of “legitimate” traffic delivering malicious payloads from compromised infrastructure.

Critical Analysis: Strengths, Weaknesses, and Unanswered Questions​

Notable Strengths of This Attack​

• Stealth and Psychological Leverage: By mimicking legitimate, internal workflows, adversaries evade both technical controls and user intuition, raising click and response rates.
• Abuse of Trusted Certificates: The use of valid SSL certificates suggests a higher level of operational discipline, making network monitoring and incident response more challenging.
• Cloud-Agnostic Attack Infrastructure: By exploiting gaps in regional IaaS platforms, attackers can rapidly spin up, tear down, and relocate infrastructure—outpacing IP blacklists.

Limitations and Evolution Risks​

• Potential for Attribution: Repeated use of specific infrastructure (e.g., recurring IP addresses, certificate subject names) may allow security vendors to build robust detection signatures.
• Dependency on Legacy Features: Organizations moving toward full OAuth2 and Modern Authentication with conditional access will reduce the footprint for attacks of this type.
• Microsoft’s Junk Handling: While messages landing in Junk is a barrier, “alert fatigue” or mailbox mismanagement means the risk is not fully eliminated.

Potential Risks​

• Erosion of Trust: The most insidious danger is the slow erosion of confidence among staff, fostered by repeated internal phishing incursions.
• Operational Disruption: If organizations overcorrect with overly restrictive mail policies, they may inadvertently break business-critical workflows dependent on automated emails.
• Forward Proliferation: If techniques prove effective, expect further copycat campaigns and exploitation of parallel cloud features across other SaaS or IaaS providers.

What Remains Unclear​

• How quickly can Microsoft adapt its composite authentication and Direct Send scope to neutralize this class of threats?
• Are there regional trends in targeting, or in the IaaS vendors being abused, that merit tailored national response?
• What downstream risks exist for organizations that rely exclusively on Microsoft 365’s built-in controls without advanced threat protection overlays?

Concluding Thoughts: Security as a Living, Layered Process​

This attack typifies the evolving nature of cyber risk in cloud-first deployments. As organizations automate, virtualize, and federate more of their workflows, boundaries soften. What was once an advantageous feature—an open relay for trusted printers—becomes a prime vector for adversaries willing to chain together disparate infrastructure, certificates, and social engineering components.
Ultimately, defending against this class of attack requires a mindset shift: Legacy trust models must give way to continuous verification, rigorous audit, and the embrace of defense-in-depth principles. Enterprise defenders should treat every mailbox, every relay, and every sender—internal or otherwise—as potentially suspect until proven otherwise.
Cloud security is not a set-it-and-forget-it proposition. Only through sustained vigilance, regular configuration audits, and layered security controls can organizations anticipate and neutralize the next permutation of phishing—whether it appears to come from the outside, or, worryingly, from within.

---

Source: Cyber Press Hackers Leverage Microsoft 365’s Direct Send Feature to Launch Internal Phishing Attacks