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:

1
dig +short MX domain.local

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.

1
2
3
4
5
swaks --server (tenant MX endpoint) \
  --from [email protected] \
  --to   [email protected] \
  --header "Subject: EMAIL TEST" \
  --body 'Email test'

If the client disabled direct send, Swaks will tell you it is not permitted. Picture of direct send erroring out with swaks and displaying its disabled

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. Picture of GoPhish sending profile

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.

Picture of unverified email

Picture of unverified email

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:

1
Install-Module ExchangeOnlineManagement -Scope CurrentUser -Force

After the module is installed, we need to authenticate to Exchange.

1
Connect-ExchangeOnline

Finally after authenticating to exchange, we can disable it with the Set-OrganizationConfig cmdlet with the RejectDirectSend option.

1
Set-OrganizationConfig -RejectDirectSend $true

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

0%