The Call Is Coming From Inside the House: Microsoft Office 365 Direct Send & Why You Need to Mitigate Now

A new technique for sending spoofed emails was recently discovered – one that allows an attacker to send messages from anywhere on the internet while spoofing the sender in a way that lands directly in the target’s inbox.

Microsoft Office “Direct Send,” a feature of all Microsoft 365 environments with an Exchange Online plan that cannot be removed, is intended to allow printers and scanners to send email inside a trusted network. However, this feature also allows for unauthenticated use and the ability to not only send from inside to inside, but also outside to inside. What could go wrong?

For a spoofed email to arrive in an end user’s inbox, an attacker must first find the “smart host” endpoint. Luckily, this endpoint is static across all deployments:

Basically, if an attacker knows your email format and associated domain for email, then they have what they need to perform this attack. We use this technique in almost every external penetration test we perform given its effectiveness and the ready availability of tools to take advantage of it.

With a basic PowerShell command, this process is very straightforward:

A brief rundown of the fields in use:

• -SmtpServer: The Direct Send endpoint that we will send mail through.
• -To: The user we are targeting at company.com.
• -From: The internal user we are spoofing the mail coming from within company.com.
  • Note: This does not have to be a valid user. However, any user that does not exist in the domain will not appear to be as legitimate (no profile picture in Outlook, etc.) and the email is more likely to land in spam.
• -Subject: The email subject line.
• -Body: The email body, which can be plaintext or pulled from an HTML template the attacker creates to make it look more authentic.

Once this command is sent, the end user will likely get the email delivered directly to their inbox (assuming mitigations are not in place, more on that later).

Here are just a few examples of the ways we have leveraged this “feature”:

• To entice a user to go to a malicious page we have setup that steals end user credentials. This can be an email from internal user A to internal user B that would naturally seem trustworthy.
• To get an end user to complete a login via device code phishing
• To convince an end user to take some internal action that opens up pathways for further network exploitation

So, about that mitigation…

Given that you cannot just turn Direct Send off, the best way to stop this attack is to ensure that all incoming mail to your organization is forced through your mail proxies like Mimecast, Proofpoint, etc. Email should not be allowed into the organization from an untrusted source.

This can be accomplished via Exchange Admin Center using connector rules, an example of which is included below (this is for Mimecast, but can be used in a similar fashion for other mail proxies):

Direct Send is a dangerous feature of Microsoft 365 if used by the wrong people. Given DenSecure’s success using it to help clients remediate risk, the relatively young age of the attack vector, and the ease with which the attack can be performed, we will not be surprised to see this attack become prevalent amongst threat actors.

Why Microsoft Direct Send Should Be on Your Radar

Direct Send is a dangerous feature of Microsoft Office 365 if used by the wrong people. Given DenSecure’s success using it to help clients remediate risk, the relatively young age of the attack vector, and the ease with which the attack can be performed, we will not be surprised to see this attack become prevalent amongst threat actors.

Make sure your environment is protected — read more about threat emulation vs. penetration testing to understand how testing methodologies can reveal vulnerabilities like this. Then, get in touch with our team to assess your exposure and strengthen your defenses.