Microsoft Takes Steps to Offset Midnight Blizzard Damage

Greater Control Over Exchange Web Services by Blocking Application Impersonation

Microsoft’s March 7 update about the Midnight Blizzard attack on their Microsoft 365 tenant is a salutary reminder that the effects of compromise can persist over time. In this instance, the attackers exfiltrated email from selected email accounts, including some belonging to members of Microsoft’s leadership team and are now attempting to use that information to access other systems. No evidence exists about compromise of any customer-facing system using information shared in email, but it seems like some “secrets” (like passwords) were sent in messages, which is never a good thing.

The original January 19 report revealed that the attackers used a password spray attack to compromise a “legacy non-production system.” Although Microsoft isn’t saying what kind of system this was, it’s likely to be a development tenant spun up for testing purposes that is no longer used. Development systems often don’t have the same kind of security protection as production systems. For instance, because a password spray attack was successful, the targeted accounts likely didn’t use multifactor authentication.

When I heard about the attack, I speculated that an OAuth app was involved. On January 25, Microsoft confirmed that the attackers used a malicious OAuth app “that had elevated access to the Microsoft corporate environment.” In addition, the attacker created other OAuth apps and a user account to grant consent for the apps to use the permissions needed to access data, including the Exchange Online full_access_as_app permission, which allows apps to access user mailboxes without a signed-in user using Exchange Web Services (EWS). This is an Office 365 Exchange Online permission (Figure 1), not a Graph permission.

Removing EWS Application Impersonation

Microsoft has been clear that they are taking steps to close off holes and harden systems. It’s a case of finding a silver lining in what is an embarrassing episode for a company that has all the necessary systems deployed to detect and hunt attackers staffed by some of the best security professionals in the business. Reading between the lines, it seems like the February 20 announcement about the retirement of RBAC application impersonation in Exchange Online is a good step forward.

Microsoft is not retiring the RBAC application impersonation role from Exchange Server. The Graph APIs do not exist for on-premises servers and EWS functions in a completely different environment. For instance, few Exchange Servers can be accessed via the internet in the same way that Exchange Online can.

EWS is not an insecure protocol. The MSRC posts make it clear that the attackers used EWS to exfiltrate mailbox data. That’s unsurprising because EWS is a well-known protocol for mailbox access that’s been around since Exchange 2007. Over the years, many developers have learned how to extract mailbox data using EWS.

The big problem that EWS has is the lack of granularity in access control. It’s easy to criticize a protocol designed nearly 20 years ago to run in on-premises environments that has moved to the cloud without a redesign. Microsoft designed EWS to make it easy for administrators and developers to access mailbox content and it is very good at doing just that.

However, once EWS is assigned the ability to impersonate user access to mailboxes, it can access everything in the mailbox, including calendar items, contacts, messages, and notes plus the compliance records for Teams and Viva Engage messages generated by the Microsoft 365 substrate. It’s possible to scope application impersonation to a specific set of mailboxes, but that step is often overlooked when assigning permissions.

Using Application Impersonation with EWS

Application impersonation is used by ISV products to access mailbox content. For instance, backup products use EWS to stream mailbox data to a backup location. Naturally, backups should protect all mailboxes, so the applications used for this purpose tend to be all powerful. Apps often use a service account that is granted the ApplicationImpersonation role to run EWS code. If the service account is not protected, it represents a point of weakness that an attacker could exploit if they succeed in getting the account credentials, perhaps using a password spray.

Knowing these things, it’s unsurprising that Microsoft is moving to retire RBAC application impersonation for EWS from Exchange Online as quickly as possible. Blocking RBAC assignments for the role will begin in May 2024 and the retirement happens in February 2025. Although a good case can be argued for a faster retirement, developers need time to update their applications to use the Graph APIs via a registered app instead.

Tenants still need to control the permissions allowed to apps to access data using the Graph APIs. However, Graph API access is more granular and can be more easily tracked using audit logs. A delegated EWS.AccessAsUser.All permission is available for apps to continue using EWS, but the future for EWS in Exchange Online is limited as Microsoft will retire EWS on October 1, 2026.

In these circumstances, it would be better to migrate apps to use Graph permissions like Mail.Read.All to read mailbox content. An example of using this permission is in a script showing how to report mailbox contents. Optionally, tenants can use RBAC for applications to scope Graph API access for apps to mailboxes.

Check Role Assignments

Tenants should start by checking if any apps use the EWS application impersonation RBAC role. Microsoft provides a PowerShell command in their blog. I used a slightly altered version and discovered that the role is assigned to some accounts but no apps:

Get-ManagementRoleAssignment -Role ApplicationImpersonation -GetEffectiveUsers | Format-Table RoleAssigneeName, AssignmentMethod, EffectiveUserName

RoleAssigneeName                                  AssignmentMethod EffectiveUserName
----------------                                  ---------------- -----------------
RIM-MailboxAdmins877f977c7e1b43e88126a512e29b58dd Direct           All Group Members
Organization Management                           Direct           All Group Members
Organization Management                           RoleGroup        Sarah Smith
Organization Management                           RoleGroup        Break.Glass.Account
Organization Management                           RoleGroup        Administrator
Organization Management                           RoleGroup        Brian Jones
Organization Management                           RoleGroup        Azure.Management.Account

The RIM-MailboxAdmins object is a management group created to manage the BlackBerry devices that were once ubiquitous in Exchange. This is an old artefact that speaks to the age of my tenant. It can safely be removed. The other assignees are accounts that hold either the Global administrator or Exchange administrator role and can be left in place.

If any apps are reported, you should check what the app does and why it uses EWS application impersonation A quick internet search revealed that a broad range of ISV products look for the full_access_as_app permission (here’s an example Reddit thread). If a vendor mentions that their app needs full_access_as_app as a prerequisite, confirm if they’re talking about the RBAC role (which is being retired) or the permission (which is not). Any app that depends on the RBAC role must be updated before Microsoft retires the role in February 2025.

Lessons for Microsoft 365 Tenants

Microsoft is extracting value from the Midnight Blizzard episode by moving to improve the security of their tenant and customer tenants. However, they can only do so much. Tenants must take responsibility for actions that they can execute to further tighten security. For example:

• Think about the nature of the Midnight Blizzard attack and to protect the tenant against similar attempts.
• Close and remove development tenants once they are no longer needed. Although these tenants are not connected to your production tenant in any way, they might contain information or apps that give attackers useful hints to find ways into the production environment.
• Use multifactor authentication, even for development tenants. Check that accounts use multifactor authentication instead of just having an authentication method registered. Overall, multifactor authentication within Microsoft 365 tenants remains low, which creates an open door for attackers to push.
• Review the permissions assigned to Entra ID registered apps, especially high-priority permissions that allow apps to access user data across the tenant. Use scripts to monitor the assignment of high-priority permissions to apps and query those assignments to make sure that they’re justified.
• Remove registered apps that are no longer needed or in active use. Orphan apps (those whose owner has left the organization) should be scrutinized and potentially removed.
• If the tenant uses Microsoft Sentinel, consider using these tips to detect similar attacks.

Microsoft’s step to remove EWS RBAC application impersonation from Exchange Online is a sensible step. I expect that we will see more actions flowing from the Midnight Blizzard attack. Stay tuned for developments.