Remember the good ‘ol days of Zip drives, Winamp, the advent of “Office 365,” and copy machines that didn’t understand email authentication? Okay, maybe they weren’t so good! For a while there, as we migrated from on-prem Exchange to “Office 365” Exchange Online, we still needed to scan and email files from our multi-function devices, which had limited mail-delivery and authentication options. Microsoft’s solution was “Direct Send,” an automatically created, unauthenticated SMTP endpoint accepting mail for all of a tenant’s accepted domains. What could go wrong? Check out this blog post for details:  https://www.blackhillsinfosec.com/spoofing-microsoft-365-like-its-1995/ 

Although Direct Send is not new, we have seen a recent surge in threat actors abusing it, effectively “spoofing” someone inside your organization to someone else inside your organization. Lately, we’ve seen the threat actors claim that they’ve “hacked” your account to gain access to your mailbox, when in fact they’ve just sent you email as yourself via Direct Send! Thanks to Microsoft, no hacking required!  

It’s important to note that while Direct Send can only be used to send to legitimate recipients within your tenant, it can also be used to “impersonate” a sender that does not exist in your tenant, as long as the domain is accepted, e.g. mail from ‘[email protected]’ (assuming that “yourbusiness.com” is legit and you don’t have a “Captain America” account).  

This is just a side note, but if a threat actor messages you to let you know they’ve “hacked” your account, that’s often a good sign that they haven’t “hacked” your account! I’m not suggesting that you be dismissive of any such messages and/or indicators but checking Direct Send configuration should be a priority response! 

Until recently, you couldn’t just disable Direct Send. You could implement an inbound connector or make some creative SPAM-detection rules, etc., but these were not trivial to configure and test, especially for a “service” that you may very well not use!  

So, I have good news and bad news. Let’s start with the bad…there is no easy way to report on Direct Send utilization in your tenant (at the time of this writing, Direct Send reporting options were “in progress”). If you are uncertain as to whether or not Direct Send is being used for authorized business operations, you should conduct some internal review/discussion to identify legitimate use cases and consider implementing connectors accordingly: Configure mail flow using connectors in Exchange Online | Microsoft Learn 

Now for the good news! If you are confident that you do not have legitimate use cases for Direct Send and/or those use cases are covered by an existing connector, you can now test a new “Public Preview” command to easily disable Direct Send. As a counterpoint to the “bad news,” because of the simplicity of the command to disable Direct Send, you can also easily reenable it should you need to.  

Before making any changes to your M365 tenant, I’m a huge fan of testing, documenting, changing, retesting, and updating your documentation!  

To disable Direct Send, you’ll need to “enable” the “Reject Direct Send” feature. Clear as mud? Yeah, sorry…not my fault! First, you’ll need to authenticate to your tenant via Exchange Online PowerShell. General guidelines can be found here: https://aka.ms/exov3-module. Once you are authenticated, you can run the following command:  

 Set-OrganizationConfig -RejectDirectSend $true 

Since we didn’t exactly get verbose feedback, you can check/confirm configuration using the following command: 

 Get-OrganizationConfig | select RejectDirectSend 

Below, I am running a very basic command to test Direct Send:  

Send-MailMessage -SmtpServer sometestdomain-com.mail.protection.outlook.com -From  [email protected] -To [email protected] -Subject “Did it work?” -Body “This is a test of direct send.” 

IMPORTANT: There are some caveats to testing, especially “your ISP must allow outbound TCP port 25 and your IP must not be on an email blocklist,” which it probably is if it’s a residential provider!  

For details and considerations on testing Direct Send, you can re-visit this link: https://www.blackhillsinfosec.com/spoofing-microsoft-365-like-its-1995/ 

Once you’ve enabled the “Reject Direct Send” feature, if you re-test Direct Send, you should now see “Direct Send not allowed for this organization,” as below:  

Now you know, and knowing is half the battle! Go, Joe! But seriously, one of the most challenging aspects of Direct Send is that IT and security staff are often unaware of its existence until the “CEO” sends a message to the “Executive Assistant” with an “important” link to click! So, thanks for reading and please feel free to share. Let’s slam this particular door shut! 

---

---

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

---

---