.png){kind=logo}
Multiple threat actors are still actively abusing Microsoft 365's "Direct Send" feature to deliver phishing emails that appear to originate from legitimate internal users within target organizations. Our monitoring has identified 23 active malicious sending IPs involved in these campaigns. The attacks span a wide range of payloads — quishing (QR code phishing), malicious HTML, malicious SVGs, credential harvesting, and remote access trojans — with nearly half (48.3%) exhibiting targeted rather than mass-blast characteristics. All observed emails used custom domains as the sending infrastructure. This report details the Direct Send abuse vector, the scope of observed activity, and a deep-dive into one particularly sophisticated adversary-in-the-middle (AiTM) phishing kit recovered during investigation.
To understand the severity of this threat, one must first understand the standard defense architecture. Most organizations protect their users with a Secure Email Gateway. This perimeter security layer sits in front of Microsoft 365, filtering incoming traffic for malicious links, attachments, and spam before it reaches the inbox.
However, Direct Send is designed to bypass this flow. Because it connects directly to the Microsoft 365 infrastructure, it circumvents the email security gateway entirely, rendering traditional MX record filtering useless against these internal-to-internal spoofing attacks.
Direct Send is a method by which applications or devices send email to internal recipients within a Microsoft 365 tenant. It works by connecting directly to the tenant's publicly facing MX endpoint — typically <domain>.mail.protection.outlook.com on TCP port 25 — and delivering mail without any authentication. No username, password, OAuth token, or certificate is required. The MX endpoint address is deterministic from the domain name alone.
Microsoft documents three methods for sending email through Microsoft 365:
Despite requiring zero authentication, Direct Send remains widely deployed because many operational systems cannot support modern auth. Common legitimate use cases include:
These dependencies make it difficult for organizations to simply disable Direct Send — making it an easy target for threat actors to target.
Direct Send abuse occurs when a threat actor exploits this unauthenticated pathway to execute Business Email Compromise (BEC) attacks, spoofing internal email addresses to deceive employees and deliver phishing content that appears to originate from within the target organization.
The attack requires only three pieces of information: the target's domain name (to derive the MX endpoint), a valid internal email address to impersonate, and a valid recipient address. No credentials or account compromise are needed. The attacker connects to <domain>.mail.protection.outlook.com:25, sets the MAIL FROM to any address within the organization's accepted domain, and delivers the message. Exchange Online processes it as anonymous inbound email and delivers it internally.
This is a known, low-effort vector. It can be automated with a single PowerShell Send-MailMessage command or a few lines of Python using smtplib — no -Credential parameter or server.login() call is needed. Once a valid recipient is known, the attack is trivially repeatable at scale.
Our monitoring has identified the following across active campaigns:
The campaigns employ a diverse range of payloads:
During our investigation of Direct Send-facilitated phishing, we recovered one particularly sophisticated phishing kit that warrants detailed analysis. This kit targets Google Accounts and operates as a modular, single-page application (SPA) capable of bypassing multiple forms of two-factor authentication in real time.
The kit acts as a real-time adversary-in-the-middle (AiTM) proxy between the victim and legitimate Google login servers. It does not simply harvest static credentials — it synchronizes an interactive session with Google's authentication flow, allowing the attacker to complete login on behalf of the victim, including handling any MFA challenge Google presents.
The C2 infrastructure is hosted at hxxps[://]stackblitz[.]waidrufroo[.]ru.
The attack proceeds through five distinct phases, driven by a payload that synchronizes the browser UI with C2 backend commands.
The victim encounters a lure page hosted on Adobe Acrobat (acrobat.adobe.com) — a legitimate, trusted platform. The page mimics a shared document interface, displaying a red PDF icon with the message "You've received (3) new PDF Documents for your review" and a prominent "VIEW SECURE DOCUMENT" link.
Clicking the link redirects to hxxps[://]storage[.]googleapis[.]com/assorthealth/offline_attachment[.]html. This page contains a reflective loader for the phishing kit.
The loader performs several filtering checks:
hxxps[://]grey[.]teashaboulouve[.]qpon/dallal!twairyd — This prevents analysis in sandboxed environments that block this obscure domainhttps://www.bigcartel.com — a benign e-commerce platform
The kit POSTs to hxxps[://]stackblitz[.]waidrufroo[.]ru/kfv4mqUo0oTtqn... to retrieve a payload. The payload uses a multi-layered encryption and obfuscation strategy that combines custom Shift-XOR stream ciphers with memory-only Base64/eval execution to prevent disk-based detection. It further secures the payload by employing server-side conditional delivery, ensuring core functions and keys are only transmitted if specific client-side criteria are met. This multi-layered mechanism ensures the core phishing logic is never present in the initial page load — defeating static analysis and preventing researchers who simply download the HTML from recovering the attack code.
Once the payload is decrypted and loaded, it sends telemetry (IP, User-Agent) to the C2 via a pagevisited() call. The C2 may respond with a captcha show command, overlaying a textual/image CAPTCHA before displaying the login form. This validates humanity and filters automated analysis bots.
The victim then encounters a pixel-perfect replica of the Google Sign-in page, rendered entirely within the phishing kit's SPA. The URL bar still shows storage.googleapis.com — the only indicator that this is not the real Google login.
After email entry, the client sends the data to the C2. After password entry, the data is sent again. The C2 attempts to login to Google in real time using the captured credentials.
Based on Google's response, the C2 instructs the kit to display the appropriate MFA challenge overlay — SMS code entry, authenticator app code entry, mobile device approval prompt, backup code entry, phone number verification, or voice call code entry. The victim enters the code, the client POSTs it to the C2, and the attacker completes the Google login session.
Upon receiving a success message from the C2, the kit redirects the victim to a dynamic URL provided by the server — typically mail.google.com — seamlessly handing off to the now-authenticated Gmail session.
Evaluate and restrict Direct Send. Audit whether your organization actively uses Direct Send. If not, enable RejectDirectSend in Exchange Online: Set-OrganizationConfig -RejectDirectSend $true. If Direct Send is required for legitimate devices, create partner inbound connectors with IP or certificate-based authentication for authorized senders, then enable RejectDirectSend for all other traffic.
For many organizations, disabling Direct Send is not operationally viable. Legacy printers, ERP systems, monitoring platforms, and third-party integrations create hard dependencies that cannot be re-architected overnight — and in some cases, cannot be re-architected at all. Furthermore, when Direct Send traffic goes directly to the MX endpoint, it bypasses any third-party Secure Email Gateway sitting in front of Exchange Online entirely.
Meanwhile, the traditional email security gateway was not designed for this problem. Static blocklists cannot keep pace with 23+ rotating IPs across decentralized campaigns. Signature-based detection cannot catch a phishing kit that delivers its payload conditionally and encrypts its core logic with a custom stream cipher. Rule-based email filtering cannot distinguish a spoofed Direct Send message from a legitimate one when both arrive via the same MX endpoint with the same AuthAs: Anonymous header — the difference is intent, and intent requires understanding context, content, and behavioral signals simultaneously.
This is where the gap between legacy email security and the current threat landscape becomes most visible. The attacks documented in this report — dynamic AiTM proxies, multi-layered obfuscation, conditional payload delivery, real-time MFA interception — are adaptive, context-aware, and designed to defeat static analysis. Defending against them requires AI-powered email security that is equally adaptive: one that can reason about the semantic content of a message, evaluate behavioral anomalies in real time, and make decisions about novel threats it has never seen before — not just match patterns from threats it has seen in the past. Organizations that remain dependent on Direct Send should critically evaluate whether their current enterprise email security stack is capable of operating at the same level of sophistication as the threats now flowing through that channel.
