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 appthat 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.

 Assigning the full_access_as_app permission to an Entra ID registered app
Figure 1: Assigning the full_access_as_app permission to an Entra ID registered app

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:

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.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.

Comments

  1. Jeff

    The Real Person!

    Author Jeff acts as a real person and verified as not a bot.
    Passed all tests against spam bots. Anti-Spam by CleanTalk.

    The Real Person!

    Author Jeff acts as a real person and verified as not a bot.
    Passed all tests against spam bots. Anti-Spam by CleanTalk.

    Hi Tony, I cannot seem to remove the RIM-MailboxAdmins(…) role group.
    Error:
    “…may not be performed on the management role group
    ‘RIM-MailboxAdmins(…)’ with capablity ‘Partner_Managed’. Membership of a partner managed role group can’t be changed.” (yes, capability is spelt incorrectly in the error, haha)
    Any idea how to remove it or modify the ‘capability”? I’ve also tried using -BypassSecurityGroupManagerCheck and -force.
    Thanks.

      1. Jeff

        The Real Person!

        Author Jeff acts as a real person and verified as not a bot.
        Passed all tests against spam bots. Anti-Spam by CleanTalk.

        The Real Person!

        Author Jeff acts as a real person and verified as not a bot.
        Passed all tests against spam bots. Anti-Spam by CleanTalk.

        I did end up opening a case. It seems the RIM-MailboxAdmins(…) group is currently locked by Microsoft, preventing deletion. It’s likely to prevent new assignments due to the deprecation of the application impersonation role.

  2. Adam

    Hi, so basically the retirement of the RBAC application impersonation in Exchange online means nobody will be able to assign full_access_as_app as a app role in Office 365 Exchange Online to any service principal within the API permissions blade for any given application, correct (since MSFT will start blocking RBAC assignments for the role in May 2024)?

    1. Avatar photo
      Tony Redmond

      Correct. That’s the way we are heading. The strong preference within Microsoft is for apps to use fine-grained Graph permissions instead of these ‘administrator is God’ permissions.

Leave a Reply