Microsoft Security Report Highlights OAuth Compromise of Exchange Online

Attackers Hijacked Exchange Online in Microsoft 365 Tenant to Send Spam

On September 22, the Microsoft 365 Defender Research Team published an article explaining how attackers used OAuth permissions granted to Azure AD applications to compromise Exchange Online. The essence of the attack was that the threat actor (attacker) gained access to Microsoft 365 tenants via unsecured administrator accounts and used these accounts to create a malicious OAuth application that added a connector to Exchange Online to send spam.

The article says that the attacker “added a malicious inbound connector in the email server.” The mention of a mail server might confuse some into thinking that the exploit featured Exchange Server. Further detail in the article points to Exchange Online.

In any case, there’s some good learning in the article that every Microsoft 365 tenant should take on board. Let me explain what those points are.

MFA Again

At the TEC 2022 conference, Alex Weinert, Microsoft VP for Identity, revealed that only 34.15% of Azure AD accounts holding an administrative role use multi-factor authentication (MFA). The report explains how attackers used credential stuffing (attempts to compromise many user accounts with stolen credentials, usually obtained from a data breach) to target tenants. Given that two-thirds of admin accounts don’t use MFA, a high chance exists that they’ll be lucky and compromise an admin account. Microsoft notes that 86% of the compromised tenants had at least one admin account with a real-time high-risk score (highly likely to be compromised).

The first learning is to always protect administrator accounts with MFA. If you have Azure AD Premium licenses, consider using Privileged Identity Management (PIM). Even if you run a small tenant with limited funds available for add-on licenses, you can still take steps like periodically reporting admin accounts that don’t use MFA. Of course, you need to take action to enforce MFA on the accounts you discover through reports.

Security professionals also argue the case to enforce a clear separation between administrator and user accounts to avoid the risk that attackers can penetrate administrator accounts through techniques like business email compromise. If you do allow administrator accounts to receive email, take steps to limit who can send messages to those accounts.

Microsoft also recommends the use of conditional access policies, especially to protect administrator accounts. During his TEC 2022 session, Alex Weinert observed that Microsoft enforces Security Defaults in Azure AD for many tenants as part of their program to increase the level of security across Microsoft 365. You don’t need to run Security Defaults (and in some cases it’s better not to), but Security Defaults makes sure that your administrator accounts use MFA.

Creating a Malicious OAuth Application

After gaining access to an administrator account, the attackers created a registered Azure AD app. Each app has a service principal. The attackers added the Exchange.ManageAsApp permission to the app’s service principal to give the app the ability to manage Exchange Online. Because they controlled an administrator account, they could grant consent for the app to use the permission.

The attacker then increased the capabilities of the app by assigning it the global administrator and Exchange administrator roles. The result is that the app could do anything to manage Exchange Online and Microsoft 365. They also added some app credentials to allow them to authenticate and use the app, even if the compromised administrator account woke up and decided it would be a good idea to change their account password (or even belatedly enabled MFA).

Microsoft observed that in some cases the attacker left the highly permissioned app in place for some weeks or months before using the app. In some instances, the apps were in place for months and used multiple times by the attacker.

Our second set of learnings is that it’s important to monitor apps that hold high-priority app permissions like Exchange.ManageAsApp. Microsoft’s article recommends tools like Microsoft Defender for Cloud Apps or the App governance add-on available for Microsoft Defender for Cloud Apps. Both help to highlight apps with high permission levels (Figure 1).

These tools require licenses, but you can report high-priority app permissions using PowerShell without any further licenses using the basic information recorded in Azure AD. Audit information is available to help understand when apps received permissions. The point is that valuable Azure AD data is available to help detect and head off problems. But that data must be used and actioned to pick up bad apps before attackers get the chance to wreak havoc.

Updating Exchange Online

The attackers’ objective is to use Exchange Online to transmit spam. To do this, they used the app to run Exchange Online PowerShell and authenticate using the credentials they created for the app. Once connected, they created a new connector to receive messages from the IP addresses for their email server and on to unsuspecting victims. The intention of the spam was to convince recipients to provide credit card details. They also created 12 mail flow (transport) rules to force the transport service to remove specific X-headers from messages to make their spam less detectable.

After running a spam campaign, the attackers removed the connector and mail flow rules to avoid detection. The app remained in place ready to be used to recreate the connector and mail flow rules for the next spam campaign.

The third learning is that Exchange Online generates audit events to record the creation and deletion of connectors and mail flow rules. Any creation of these objects is suspicious. Exchange Online normally doesn’t need additional connectors for mail flow, so the existence of extra connectors in a tenant should be questioned. It’s easy to detect these events with commands like:

[array]$Records = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date).AddDays(1) -ResultSize 5000 -Operations New-TransportRule, New-InboundConnector -Formatted -SessionCommand ReturnLargeSet
$Records | Group-Object Operations | Sort-Object Name | Format-Table name, count

Name                 Count
----                 -----
New-InboundConnector     1
New-TransportRule        12

Once you’ve found some records to check, you can review the set of connectors and mail flow rules in the organization to decide if they’re good or bad, and then respond appropriately.

Control Your OAuth Apps

The exploit analyzed by Microsoft was only possible because the tenant administrators:

• Did not defend their accounts sufficiently well to resist attacks against their credentials. Eventually, one or more accounts were compromised.
• Did not review Azure AD apps that hold high-priority permissions and ask questions like “what does this app do?” and “why does the app need those permissions?”
• Did not use the data in the Office 365 audit log to detect suspicious activities that adjusted the Exchange Online configuration.

You can make all the excuses in the world for why the tenant administrators failed so abysmally. None of the excuses hold water. All are poor justifications for behavior that is known to lead to problems. By not using MFA, administrators made it easier for attackers to compromise accounts, create the malicious app, and assign the app some high-priority permissions. By failing to review the data that’s available in plain sight, they let the app sit there until the attackers decided to send their spam. They then failed to detect the changes made to Exchange Online.

Everything goes back to the original account compromise. Don’t be silly and end up being the subject of a Microsoft security article. Use tools like Microsoft Defender for Office 365, Office 365 Cloud App Security (included in Office 365 E5), or Microsoft Defender for Cloud Apps to automate the checking of audit records and app permissions. That makes sense if you have that software. For anyone else, getting MFA deployed for all accounts is the single best way to prevent problems. Afterward, some PowerShell will help you understand what’s happening in your tenant. And that’s the most important thing to do.