Mitigating Exchange Permission Paths to Domain Admins in Active Directory
The Issue Recently a blog post was published by Dirk-jan Mollema titled "Abusing Exchange: One API call away from Domain Admin " (https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/) which highlighted several issues with Exchange permissions and a chained attack which would likely result in a regular user with a mailbox being able to become a Domain Admin in the AD forest. Tools have been released to take advantage of this issue.
He highlights the key components of the issue in the blog post introduction:
This blog combines a few known vulnerabilities and known protocol weaknesses into a new attack. There are 3 components which are combined to escalate from any user with a mailbox to Domain Admin access:
* Exchange Servers have (too) high privileges by default * NTLM authentication is vulnerable to relay attacks * Exchange has a feature which makes it authenticate to an attacker with the computer account of the Exchange server ... The main vulnerability here is that Exchange has high privileges in the Active Directory domain. The Exchange Windows Permissions group has WriteDacl access on the Domain object in Active Directory, which enables any member of this group to modify the domain privileges, among which is the privilege to perform DCSync operations. Users or computers with this privilege can perform synchronization operations that are normally used by Domain Controllers to replicate, which allows attackers to synchronize all the hashed passwords of users in the Active Directory.
Exchange Permissions in Active Directory
At the Microsoft Blue Hat in 2017, Sean Metcalf, Trimarc founder and Active Directory Subject Matter Expert (SME) highlighted issues with Exchange permissions. Some slides from this presentation are shown here as representative samples (the full presentation slide deck is in the Presentations section.
More information about this issue has been highlighted in presentations by Andy Robbins (@_wald0) and Will (@Harmj0y), including at Black Hat USA 2017.
The Bloodhound tool written by Andy Robbins, Rohan Vazarkar, and Will can identify attack paths involving Exchange permissions configured in Active Directory.
Microsoft recently published an article (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007) on how to configure EWS throttling which will mitigate the issue(s) that Dirk-jan Mollema raised. The issue with this is that EWS throttling could negatively impact applications like Outlook for Mac and doesn't resolve the escalation path with Exchange permissions configured in AD. Trimarc has discovered Exchange having elevated permissions in AD in many customer environments while performing Active Directory Security Assessments (ADSAs).
Some of the Exchange permissions discovered during Trimarc ADSAs:
* Organization Management has Full Control ("GenericAll") rights at the domain root. * Exchange Trusted Subsystem has Full Control ("GenericAll") rights at the domain root. * Exchange Recipient Administrators has Full Control ("GenericAll") rights at the domain root. * Exchange Windows Permissions has Modify Permissions ("WriteDACL") rights at the domain root.
The last permission on the list is one that, if in place in an AD forest, will likely result in AD compromise. This right should not be required, so removing it from the domain root should have no negative impact on day to day operations. We recommend creating a new AD group (something like "Privileged Modify Domain Permissions") and grant this right to that group. Add the Exchange Windows Permissions group to this new Privileged Modify Domain Permissions group when this right is required (should be rare).
PowerShell command to scan and report on the AD domain permissions (requires the AD PowerShell module):
Note that this script is provided as a sample and the domain name needs to be changed to correctly gather data. In more recent versions of Exchange, extensive permissions at the domain level are typically not required.
Furthermore, Exchange permissions persist even when the only Exchange server remaining on-premises is for managing Office 365.
Mitigating The Active Directory Security Issues with Microsoft Exchange Permissions
The references noted above highlight issues relating to Exchange permissions and often the mitigations are complicated and difficult to implement.
The goal of this article is to provide a stop gap option that mitigates Exchange permissions that have extensive rights in Active Directory with minimal day-to-day operational impact while organizations can implement a more permanent fix.
For those that are running Exchange on-prem in the Default Shared Permission model and it is not isolated in a dedicated resource forest you need to decide with a fair amount of criticality how you are going to address the permission issue regarding the Exchange Windows Permission group described in https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/.
The best method to mitigate the issue with Exchange having elevated AD permissions, and maybe more importantly the way that won’t get the “we don’t support that” answer from Microsoft, is to switch to Active Directory (AD) split permissions (Exchange) or isolate Exchange in its own resource forest (or both). The split permission model (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help) requires AD management tools for creating security principals in AD (such as users and security groups). Implementing the split permission model is not trivial once Exchange has been deployed, but does effectively limit Exchange rights in AD.
Microsoft notes the following functionality changes when enabling Active Directory split permissions:
* Creation of mailboxes, mail-enabled users, distribution groups, and other security principals is removed from the Exchange management tools.
*Adding and removing distribution group members can't be done from the Exchange management tools.
*All permissions granted to the Exchange Trusted Subsystem and Exchange servers to create security principals are removed.
*Exchange servers and the Exchange management tools can only modify the Exchange attributes of existing security principals in Active Directory.
The key change this stop gap option implements is the removal of the Exchange Trusted Subsystem group from the Exchange Windows Permissions Group, with the work around of temporally restoring the default membership to get around any unforeseen issues.
So here’s what that looks like, note that this is just a general overview, this premise will need to be customized based on the nuances of your AD and Exchange environments.
Save this link to use as a reference as to what permission changes Exchange made to your Active Directory environment when deployed: https://docs.microsoft.com/en-us/exchange/exchange-2013-deployment-permissions-reference-exchange-2013-help
Create a custom RBAC group with the same roles as the Organization Management group removing the requirement for administrators to have permanent membership in Organization Management. Call this group something like "<DOMAIN/FOREST_NAME> Exchange Organization Management" This can be easily be done using the RBAC cmdlets in Exchange Management Shell. By default, the Organization Management group can modify group membership of the Exchange Trusted Subsystem, Exchange Windows Permissions, and other Exchange privileged groups in Active Directory. This article from Microsoft walks you through the process of copying an Exchange role group: https://docs.microsoft.com/en-us/exchange/permissions/role-groups?view=exchserver-2019
Delegate more appropriate AD rights to the group created in step 2 ("<DOMAIN/FOREST_NAME> Exchange Organization Management") at the appropriate OU level based on your AD OU design. Reference the link provided in Step 1.
Remove the Exchange Trusted Subsystem group from the Exchange Windows Permissions group and any other groups that are members of Exchange Windows Permissions group. This isolates Exchange from having AD permissions. Ensure that only Exchange Servers are members in the Exchange Trusted Subsystem group.
Use the reference in step 1 to apply the permissions delegated to the Exchange Windows Permission group by default to the Exchange Trusted Subsystem group but this time at the appropriate OU level versus at the domain root.
Remove any membership from the Organization Management group.
Ensure that monitoring and alerting is configured for membership changes of the following groups: * Exchange Windows Permission * Exchange Trusted Subsystem * Organization Management
When the removed permissions are required, temporarily add the Exchange Trusted Subsystem group to the Exchange Windows Permissions group. Ensure that this group is removed when the required tasks are completed.
Ensure that you use groups instead of adding individual user or computer accounts directly in these permission groups as this should reduce the need to reboot computers and log off and then back on again. Note that this configuration will break things and add some additional burden to the administration of Exchange but hopefully have little to no impact in the day to day use of Exchange by end users.
For example if you attempt to install a new Exchange Server in the environment you should get an error, but to get around this you can add the admin account that is installing the new Exchange server temporarily to the default Organization Management Group and temporarily add Exchange Trusted Subsystem group to the Exchange Windows Permission Group, this is the work around for anything this new configuration might break which should mostly be related to object creation in the domain partition in AD.
Also, if using the AD split permission model as an example as to what other things this premise might break, using the Add-ADpermission cmdlet to add permissions to a mailbox will probably break as well but should still work for receive connectors because mailbox objects are stored in the domain partition and receive connectors are stored in the configuration partition.
Also should you need to engage Microsoft support its easy enough to put yourself back into the “supported” configuration by simply giving the Exchange Trusted Subsystem group temporary membership to the Exchange Windows Permission Group.
This premise is not been fully tested out to see what all the unintended consequences in every environment might be but can be switched back to the supported configuration temporarily as a work around when something breaks.
It has to be emphasized again that this is only a stop gap meant to give organizations a possible short term option that can be implemented rather quickly while the correct fix or path is put in place for that Organization.
On February 12, 2019, Microsoft released patches that modifies Exchange Web Services Push Notifications to protect against the issue identified in Dirk-jan Mollema's blog post and Microsoft also reduces the rights that Exchange has to Active Directory. This requires that the new version of setup.exe /PrepareAD is run.
When Exchange was originally installed, it configures and grants itself extensive Active Directory permissions. These permissions provide necessary access that Exchange may ever need. The issue is that these permissions are overly permissive, especially when early versions of Exchange were deployed (since Exchange 2000/2003 added extensive permissions compared to current versions). The Microsoft Exchange split permission model or deploying an Exchange resource forest are the best methods to mitigate attacks on AD through Exchange permissions, though these are not easy to deploy or configure (or retrofit). Trimarc has identified a method that switches the configuration from a permanent Exchange permissions model to one where the required permissions can be provided on a "when needed" (or just in time) basis.
This post was primarily authored by Jason Crawford, Trimarc's Exchange & Office 365 Subject Matter Expert (SME), with contributions from the rest of the Trimarc team.