Exploiting Office 365 Direct Send for Internal Phishing
What is Direct Send?
Direct Send is a feature in Microsoft 365 that allows emails to be sent internally without authentication. For example, [email protected] can email [email protected] using Direct Send, but he cannot email external domains such as [email protected]. The problem with Direct Send is that it is unauthenticated. If a threat actor discovers you are using Microsoft 365 they may try sending internal emails since Direct Send is enabled by default. This guide is for ethical hackers, penetration testers, and defensive security engineers to ethically test, defend against, and understand this risk.
Abusing Direct Send
Discovering the SMTP server
On Linux, before we are able to test direct send we have to find the target’s SMTP endpoint, which is usually their MX record. We can do that with the dig
command:
|
|
Testing if it works with swaks
The cool thing about direct send is that you actually don’t need to send from or to a valid user, you just need to send the email internally. So, if [email protected] is not a valid user, with direct send we can still send emails with the ITSecurity email if direct send is enabled. Testing against invalid internal users is a great way to check if Direct Send is still enabled.
|
|
If the client disabled direct send, Swaks will tell you it is not permitted.
Configuring GoPhish
With GoPhish it’s rather easy to configure a sending profile to use direct send. You really just need to configure an SMTP From mail address and the host which is the SMTP endpoint we discovered earlier. I also recommend setting an X-Mailer header manually. Otherwise, GoPhish will add one and identify itself.
Analyzing the email
Once the emails are successfully sent, they should end up in the main inbox unless the email has content that hits spam filters. When viewing the email, it has a tag that says “Unverified”. This is likely because SPF and DKIM fail as Outlook isn’t able to verify the authenticity of the sender.
Defenses
Microsoft only has one option to disable Direct Send, which is with PowerShell, but thankfully it’s easy to disable. If you don’t already have the Exchange module installed, you need it to disable direct send. Please install the Exchange Management module with the following command:
|
|
After the module is installed, we need to authenticate to Exchange.
|
|
Finally after authenticating to exchange, we can disable it with the Set-OrganizationConfig
cmdlet with the RejectDirectSend
option.
|
|
References
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
https://www.blackhillsinfosec.com/disabling-m365-direct-send/
https://learn.microsoft.com/en-us/answers/questions/4693270/warning-unverified-sender