{
	"id": "4d92c377-da1b-4b9a-899e-05c375139165",
	"created_at": "2026-04-06T02:11:45.522927Z",
	"updated_at": "2026-04-10T13:12:53.710875Z",
	"deleted_at": null,
	"sha1_hash": "90a192d3845587cf34034d37e2e3d342ad26ad6f",
	"title": "Ongoing Campaign Abuses Microsoft 365’s Direct Send to Deliver Phishing Emails",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 219445,
	"plain_text": "Ongoing Campaign Abuses Microsoft 365’s Direct Send to Deliver\r\nPhishing Emails\r\nBy Tom Barnea\r\nPublished: 2025-06-26 · Archived: 2026-04-06 02:00:57 UTC\r\nVaronis Threat Labs has uncovered a novel phishing campaign targeting more than 70 organizations. In this post,\r\nwe dive into the specifics to help you better understand what happened, how to detect the attack and how to\r\nprevent it moving forward. \r\nThis campaign exploits a lesser-known feature in Microsoft 365: Direct Send.\r\nDesigned to allow internal devices like printers to send emails without authentication, Varonis warns that threat\r\nactors are abusing the feature to spoof internal users and deliver phishing emails without ever needing to\r\ncompromise an account. Identified victims spanned multiple verticals and locations but were predominantly US-based organizations. \r\nIn many of their initial access attempts, the threat actor utilized M365 Direct Send functionality to target an\r\nindividual organization with phishing messages that were subject to less scrutiny compared to standard inbound\r\nemail.\r\nThese individual events were linked to one another based on commonalities in the attack vector, such as email\r\nsubject, sender IP address and other factors. The campaign appears to have started in May 2025 with consistent\r\nactivity over the past two months. \r\nIn this blog, we’ll break down how Direct Send works, how attackers are abusing it with real-world examples\r\nfrom the incidents we investigated and how your organization can detect and defend against this tactic.\r\nWhat is Direct Send? \r\nDirect Send is a feature in Exchange Online that allows devices and applications to send emails within a Microsoft\r\n365 tenant without authentication. It uses a smart host with a format like:\r\ntenantname.mail.protection.outlook.com \r\nThis setup is intended for internal use only. But here’s the catch: no authentication is required. That means\r\nattackers don’t need credentials, tokens, or access to the tenant — just a few publicly available details. \r\nIdentifying vulnerable organizations is trivial. Smart host addresses follow a predictable format as shown\r\nabove and internal email formats (like first.last@company.com) are often easy to guess or scrape from public\r\nsources, social media, or previous breaches. \r\nOnce a threat actor has the domain and a valid recipient, they can send spoofed emails that appear to originate\r\nfrom inside the organization, without ever logging in or touching the tenant. This simplicity makes Direct Send\r\nhttps://www.varonis.com/blog/direct-send-exploit\r\nPage 1 of 6\n\nan attractive and low-effort vector for phishing campaigns. \r\nHow attackers exploit Direct Send \r\nIn the campaign observed by our forensics experts, the attacker used PowerShell to send spoofed emails via the\r\nsmart host. Here’s an example PowerShell command: \r\nThe email appears to come from a legitimate internal address, even though it was sent by an unauthenticated\r\nexternal actor. \r\nWhy this method works: \r\nNo login or credentials are required \r\nThe smart host (e.g., company-com.mail.protection.outlook.com) accepts emails from any external source \r\nThe only requirement is that the recipient is internal to the tenant \r\nThe “From” address can be spoofed to any internal user\r\nBecause the email is routed through Microsoft’s infrastructure and appears to originate from within the tenant, it\r\ncan bypass traditional email security controls, including:\r\nMicrosoft’s own filtering mechanisms, which may treat the message as internal-to-internal traffic. \r\nThird-party email security solutions, which often rely on sender reputation, authentication results, or\r\nexternal routing patterns to flag suspicious messages. \r\nDetection: What to look for \r\nTo detect this kind of abuse, you’ll need to dig into message headers and behavioral signals: \r\nMessage header indicators:\r\nReceived headers: Look for external IPs sent to the smart host. \r\nAuthentication-Results: Failures in SPF, DKIM, or DMARC for internal domains. \r\nX-MS-Exchange-CrossTenant-Id: Should match your tenant ID. \r\nSPF record: Look for a smart host to be present. \r\nBehavioral indicators: \r\nEmails sent from a user to themselves. \r\nPowerShell or other command-line user agents. \r\nUnusual IP addresses (e.g., VPNs, foreign geolocations). \r\nSuspicious attachments or filenames. \r\nHow can I separate legitimate use from abuse? \r\nNot all Direct Send usage in emails is malicious. Some legitimate use cases include: \r\nAutomated notifications from internal tools. \r\nhttps://www.varonis.com/blog/direct-send-exploit\r\nPage 2 of 6\n\nIT scripts sending alerts or reports. \r\nThird-party integrations (e.g., HR or marketing platforms). \r\nThat’s why context is key — don’t assume, validate. \r\nReal-world example: Direct Send in action \r\nVaronis Threat Labs has observed multiple instances across different environments where organizations received\r\nalerts for, “Abnormal behavior: Activity from stale geolocation to the organization.”\r\nIn one case, the alert was triggered by a Ukrainian IP address, an unexpected and unusual location for the affected\r\ntenant. \r\nTypically, alerts tied to abnormal geolocation are accompanied by authentication attempts. This time, however,\r\nthere were no login events, only email activity. Even more unusual, users were sending emails to themselves\r\nwith PowerShell as the user agent. \r\nThis pattern was distinct from other geolocation-related incidents and immediately pointed us toward a likely root\r\ncause: Direct Send abuse.\r\nThe lack of authentication, combined with internal-looking spoofed messages and scripting behavior, aligns\r\nperfectly with how Direct Send can be exploited. \r\nFurther forensic analysis revealed that the emails were crafted to resemble voicemail notifications, complete with\r\na PDF attachment. The PDF contained a QR code that redirected users to a phishing site designed to harvest\r\nMicrosoft 365 credentials. \r\nHeader analysis confirmed our hypothesis: the attacker was leveraging Direct Send to spoof internal users without\r\nneeding to authenticate. \r\nReceived: from [127.0.0.1] (139.28.36[.]230) by company.mail.protection.outlook.com \r\nauthentication-results: spf=softfail (sender IP is 139.28.36[.]230) smtp.mailfrom=company.com;\r\ndkim=none (message not signed) header.d=none;dmarc=fail action=oreject \r\nx-ms-exchange-crosstenant-id: [tenant-id] \r\nThe email originated from an external IP, failed SPF and DMARC checks, and lacked DKIM signatures, yet it was\r\naccepted and delivered internally via the smart host. This is a textbook example of how Direct Send can be\r\nexploited when left unprotected. \r\nPrevention: What you can do to protect your org \r\nEnable “Reject Direct Send” in the Exchange Admin Center. \r\nImplement a strict DMARC policy (e.g., p=reject). \r\nFlag unauthenticated internal emails for review or quarantine. \r\nEnforcing “SPF hardfail” within Exchange Online Protection (EOP). \r\nUse Anti-Spoofing policies. \r\nhttps://www.varonis.com/blog/direct-send-exploit\r\nPage 3 of 6\n\nEducate users on the risks associated with QR code attachments (Quishing attacks). \r\nIt’s always recommended to enforce MFA on all users and have Conditional Access Policies in place, in\r\ncase a user’s credentials are stolen. \r\nEnforce a static IP address in the SPF record to prevent unwanted send abuse — this is recommended by\r\nMicrosoft but not required \r\nIndicators of Compromise (IOCs) \r\nIP Addresses: \r\n185.101.38.41\r\n141.95.79.227\r\n176.107.181.26\r\n62.90.188.108\r\n38.22.104.236\r\n185.174.101.87\r\n45.83.43.192\r\n163.5.149.5\r\n212.95.55.172\r\n51.38.109.135\r\n51.38.106.141\r\n176.107.181.26\r\n83.229.70.9\r\n51.89.53.34\r\n51.89.109.70\r\n51.195.53.217\r\n139.28.36[.]230 \r\nThe Threat Actor used multiple IP addresses within the 139.28.X.X space in this campaign to launch\r\nemails \r\nDomains: \r\nhxxps://voice-e091b.firebaseapp[.]com \r\nhxxps://mv4lh.bsfff[.]es \r\nEmail Subject Lines often contain: \r\nhttps://www.varonis.com/blog/direct-send-exploit\r\nPage 4 of 6\n\nCaller Left VM Message * Duration\r\nFax-msg mm/dd/yyyy, hh:mm:ss AM/PM (2 Pages) RefID: XXXX \r\nNew Missed Fax-msg \r\nNew Missed Fax-Msg (2 pages) \r\nYou have received a new (2 pages) *Fax-Msg* to email@**** \r\nFax Received: Attached document for review REF \r\nWireless Caller Left Vm\r\nEmail Attachments often contain: \r\nFax-msg\r\nCaller left VM Message\r\nListen\r\nWireless Caller Left Vm\r\nA Caller Left VM MSG * DURATION\r\nDirect Send is a powerful feature, but it becomes a dangerous attack vector in the wrong hands. If you’re not\r\nactively monitoring spoofed internal emails or haven’t enabled the new protections, now is the time. Don’t assume\r\ninternal means safe. \r\nThis list has been updated with more IoCs as of September 9, 2025.\r\nAuthor’s Note: A special thanks to Michael Solomon and his internal research surrounding Microsoft Direct\r\nSend. \r\nDon't wait for a breach to occur.\r\nA combination of Varonis’ leading threat detection and response capabilities for Exchange Online and our\r\nManaged Data Detection and Response (MDDR) service is the ultimate defensive measure for detecting and\r\nstopping email-based threats in their tracks.\r\nOur team of world-class cybersecurity experts proactively hunts for indicators of compromise to protect your\r\norganization and data 24x7x365. Threat actors don’t take breaks — neither do we. \r\nIf you are not a Varonis customer and need assistance securing and monitoring your data, please contact our team. \r\n×\r\nhttps://www.varonis.com/blog/direct-send-exploit\r\nPage 5 of 6\n\nTom Barnea Tom is a Forensics Specialist at Varonis who helps unravel cybersecurity cases, protect organizations,\r\nand provides answers quicker than a \"Can you hear me?\" moment during a virtual meeting. He is always ready to\r\ndevise creative solutions to new challenges.\r\nSource: https://www.varonis.com/blog/direct-send-exploit\r\nhttps://www.varonis.com/blog/direct-send-exploit\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.varonis.com/blog/direct-send-exploit"
	],
	"report_names": [
		"direct-send-exploit"
	],
	"threat_actors": [],
	"ts_created_at": 1775441505,
	"ts_updated_at": 1775826773,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/90a192d3845587cf34034d37e2e3d342ad26ad6f.pdf",
		"text": "https://archive.orkl.eu/90a192d3845587cf34034d37e2e3d342ad26ad6f.txt",
		"img": "https://archive.orkl.eu/90a192d3845587cf34034d37e2e3d342ad26ad6f.jpg"
	}
}