Hackers are bypassing email security gateways and sending phishing emails directly to Google and Office 365 root domains. If you’re using a gateway, and your mail flow accepts emails not from the gateway, then hackers can send mail directly to your users.
Why is this happening?
If you use Office 365 and G Suite, you have a root domain. (They are free, built-in domains used during email setup.) The DNS of these root domains are managed by Google and Microsoft — not by you.
If you use an email security gateway (like Proofpoint, Mimecast, or Barracuda), you probably changed your MX records to point to the gateway so it can scan your emails. But you can't change the MX records of root domains, because they aren't managed by your organization. This means that you can't point the MX record of your root domain to your gateway.
As a result, your email gateway doesn't scan messages sent directly to the root domain. Hackers are taking advantage of this loophole to send phishing emails directly to end users.
How do hackers exploit this root domain vulnerability?
To find potential victims, hackers simply run an MX DNS lookup to identify root domains.
First, the hacker discovers if the target company is using SaaS-based email and an email security gateway. Then, they'll send the email directly to firstname.lastname@example.org. (Office 365) or email@example.com (Gmail).
Office 365 Mail Flow — Exploited
G Suite Mail Flow — Exploited
How to protect your organization
This vulnerability (which is a common misconfiguration) may be resolved with a reconfiguration.
Reconfigure Office 365
You must block direct delivery, reconfigure inbound relaying, and close the vulnerability. Make sure that Office 365 only accepts emails from the gateway.
In his blog, Akers offers another solution. He recommends creating a new connector and transport rule so that emails follow the correct MX path.
If you use Gmail, you must deactivate your users' test addresses. To do so, remove the domain alias your_domain.com.test-google-a.com so that it no longer points directly to user mailboxes.
What does Proofpoint recommend for Office 365 users?
Proofpoint has released customer-facing documentation (titled "Office 365 Integration: Proofpoint to Office 365 — Best Practices") about how to block direct delivery within Office 365. According to Proofpoint, this configuration is "Optional," but we recommend following the steps below to protect yourself.
1. When you're logged into the O365 Exchange Admin Center, select "mail flow," click "connectors," and add a connector.
2. In "From," choose "Partner Organization" from the drop down box.
3. In "To," select Office 365 from the drop down. Then click "Next."
4. Name and describe the connector, then click the checkbox turn it on. Hit "Next."
5. Identify the Partner Organization (Proofpoint) on the next screen under "Use the sender's domain." Click "Next."
6. In the "What sender domain do you want to use to identify your partner" pop-up, add the "*" character to apply this mail connector's settings to every domain. Click "Next."
7. In the "Connection Security" section, click the "Reject email messages if they aren't sent of TLS" checkbox.
8. Click "Reject email messages if they aren't sent from within this IP address range," then add entries for all sending IPs in your Welcome Letter under "Firewall Settings — Inbound." Click "Next."
9. Confirm the settings are correct, then save.
How Avanan tested this vulnerability
We asked several of our enterprise customers who also use Proofpoint and Mimecast if we could send an email with a clean link directly to their Office 365 or Gmail. If the email arrived and the URL wasn't rewritten, they were vulnerable.
70% of G Suite or Office 365 customers who use Proofpoint and Mimecast are vulnerable to this domain hack. Keep in mind that all tested organizations are security savvy, with full-time CISOs and a strong security practice. Consequently, Avanan believes that the actual impacted population is of larger scale.
Are Avanan customers vulnerable to this attack?
No. Avanan scans the email after Office 365 and Gmail, as opposed to gateways, which scan before Office 365 and Gmail. This vulnerability exists because gateways require MX record changes and email reconfiguration because they're not cloud-native.
This video explains how Avanan secures email differently than gateways to protect against domain hacks.