Microsoft 365 Security

This blog post will be targeted for organizations that are still operating with On-Premises Exchange servers. Exchange has always been an interesting piece, since it’s so tightened within AD. This can introduce security challenges as well. In this blog post, we will cover how we can implement the Exchange Split Permission Model to reduce the chance of an Exchange compromise leading to a full AD compromise.

First, we will be starting with covering a well-known attack path. After we have done that, we’ll explain the difference between Shared Permissions Model and Split Permissions Model, and what the Split Permissions Model can solve. Last, but not least. We also explain the pros and cons about the Split Permission Model and what you have to re-think when implementing this.

Over the years, we have seen attackers targeting On-Premises Exchange servers which allowed them to elevate their privileges to a Domain Admin or equivalent. Here is a classic example of a common attack path that I’ve seen in plenty of organizations:

For those that are familiar with BloodHound. This is how an attack path may look like when it comes down to abusing Exchange Windows Permissions that has WriteDACL on the Domain Naming Context. If you’re not familiar with this attack path. It just means that every Exchange Admin can technically become a Domain Admin or equivalent. Since having WriteDACL (Modify Permissions) allows you to modify the permissions on the DNC, which then can be used to assign DCSync permissions to replicate all the credentials within AD.

Exchange Windows Permissions having this permission was by ‘design’. It provides Exchange administrators the flexibility to manage attributes on Exchange Server objects that are consistent with their role as an Exchange administrator. However, Microsoft came to the conclusion that it is possible to make changes that lower the permissions that are granted within an Active Directory domain.

In order to solve this issue, there are CU upgrades available for Exchange servers to remove this permission. I highly recommend reviewing your current CU level.

Run the following PowerShell script on your Exchange server to view CU level:

function Get-ExchangeCU() {
    Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*" | ? DisplayName -Match "Microsoft Exchange Server \d{4}" | Select -ExpandProperty DisplayName
}
Get-ExchangeCU

At the result, we can see that I’m using Exchange 2016 CU23. This means that I’m not vulnerable for this attack path.

What is the Shared Permissions Model?

The Shared Permissions Model is the default installation in Exchange. This model doesn’t separate the management tasks between Exchange and Active Directory objects. What does this mean? It means that an Exchange Admin can use something like Exchange Management Shell or Exchange Control Panel to create security principals within AD. As example, any member in Organization Management and Recipient Management can create security principals in AD. Since both of these groups are by default part of an Exchange Management Role, which is Mail Recipient Creation Role. This role has the permissions to create mailboxes, mail users, mail contacts, distribution groups, and dynamic distribution groups.

Something that people are often not aware of. However, despite that you may have removed WriteDACL from Exchange Windows Permissions after upgrading to the latest Exchange CU version. It still has a bunch of other privileges that are by default delegated on the Domain Naming Context, which will inherit down to the OU level.

Exchange Windows Permissions can still perform the following operations:

• Create/Delete User objects
• Create/Delete Computer Objects –> (Except Domain Controllers)
• Create/Delete Group Objects
• Create/Delete Organizational Units
• Reset password of user and computer accounts –> (Except Tier-0 equivalent users and Domain Controllers)
• Modifying the DACL of user accounts –> (Except Tier-0 equivalent users)
• Adding users to groups –> (Except Tier-0 equivalent groups like DA/EA, Enterprise Key Admins, DnsAdmins, etc.)
• Etc.

This means that it could still be possible to elevate privileges in Active Directory via Exchange.

By default, Exchange computer accounts are a member of the Exchange Trusted Subsystem group. Exchange Trusted Subsystem is a member of Exchange Windows Permissions. In other words, Exchange Trusted Subsystem has the same privileges within AD as Exchange Windows Permissions. The slight difference may be that Exchange Trusted Subsystem is also a local admin on every Exchange server.

Organization Management can by default control the memberships of Exchange Windows Permissions and Exchange Trusted Subsystem. It’s like the ‘DA’ equivalent but in Exchange.

Implementing the Exchange Split Permissions Model

The concept around Exchange Split Permissions Model is to separate the management tasks between Exchange and Active Directory objects. Permissions to create security principals in the Active Directory domain partition are completely removed from any Exchange user, service, or server. In order to allow Exchange Admins to still do their job. The permissions need to be delegated and Exchange Admins also need to start using the RSAT toolkit as well. Like for example tools such as Active Directory Users and Computers, and so on. We will be explaining this later in detail.

1. Download the Exchange ISO setup. This is also a good opportunity to upgrade to the latest Exchange CU level if applicable.

Since I’m using Exchange 2016 and the latest CU version. Here is the URL to Exchange 2016 CU23: https://www.microsoft.com/en-us/download/details.aspx?id=104132

2. Start mounting the downloaded Exchange ISO

This will lead to something like this. In this case, the Exchange setup is in the F:\ drive in my case. This could be different for you.

3. Verify AD Replication Health first before proceeding further

Open PowerShell and run the following command:

repadmin.exe /replsummary

If everything is looking fine. Please proceed further with the next steps.

4. Configuring the Exchange Split Permissions Model via Exchange Setup

This task requires temporary Enterprise Admins and Schema Admins and local admin on the server that we’re going to install this Exchange setup.

Open PowerShell as an admin and run the following command:

.\Setup.EXE /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAD /ActiveDirectorySplitPermissions:true

READ ME: If you have multiple Active Directory domains in your organization, you must run the Exchange setup in every Child Domain that contains Exchange servers or objects.

Follow the same procedure and execute the following command as admin:

.\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareDomain

5. Restart all your Exchange servers one by one

Restart every Exchange server in your AD domain one by one. Do not restart all of them right away, because this may disrupt some business operations.

6. What has changed after we implemented the Exchange Split Permissions Model?

A quick summary of all the changes that have been made within AD:

• All AD permissions of Exchange groups have been removed

We can see that all the AD permissions have been stripped for groups like Exchange Windows Permissions on the Domain Naming Context.

• A new OU has been created

After implementing the Exchange Split Permissions Model. A new OU has been created that is called ‘Microsoft Exchange Protected Groups‘. This is also a quick way to verify whether an organization has the Exchange Split Permissions model implemented.

• GenericAll has been removed from Organization Management on Exchange Windows Permissions

Organization Management does not have control anymore over the Exchange Windows Permissions group.

• Exchange Trusted Subsystem have been removed from Exchange Windows Permissions

The cons about Exchange Split Permissions Model

As discussed before, Active Directory split permissions completely remove the permissions that allow Exchange administrators and servers from creating security principals in Active Directory or modifying non-Exchange attributes on those objects.

Let’s say that an Exchange Admin is trying to assign Send As permission. This won’t work anymore and will throw a similar error that may look like this:

The following Exchange Management Shell cmdlet won’t be available anymore:

• Add-DistributionGroupMember
• New-DistributionGroup
• New-Mailbox
• New-MailContact
• New-MailUser
• New-RemoteMailbox
• Remove-DistributionGroup
• Remove-DistributionGroupMember
• Remove-Mailbox
• Remove-MailContact
• Remove-MailUser
• Remove-RemoteMailbox
• Update-DistributionGroupMember
• Add-ADPermission

Here is an example where it throws an error saying that we have insufficient permissions. Keep in mind that not every cmdlet is blocked. All the Exchange-Only cmdlets are still available to separate Exchange and AD management tasks from each other.

Solution

Exchange Admins can still use Exchange servers or any other management server with RSAT installed to perform the common Exchange related tasks. They have to re-think from now on that some of the tasks cannot be performed in Exchange Management Shell anymore, so they have to lean towards using ADUC or the AD PowerShell Module to perform some of the tasks. However, before this can be done, the proper rights need to be delegated in AD.

1.Create an AD group and put all Exchange Admins in that group

In this example, I’ve decided to pick the name ‘Tier-1-Exchange-Admins‘. Add all the Exchange Admins to this group.

2. Delegate permissions on the OU level

We have Exchange Admins that need to do the following task:

• Assign Send as Permissions

Let’s say you have an OU that contains end-users. They are often the one’s asking for Send as Permissions, and so on.

What we could do is delegate create a group called Tier-1-Exchange-Admins and have it ‘Modify permissions‘ on ‘Descendant User Objects‘ at the OU that contains all the end users.

Example:

An Exchange Admin can now open Active Directory Users and Computers or use AD PowerShell for example to assign ‘Send As‘ permission to a Security Principal.

3. Delegate optional AD permissions if needed

If your Exchange Admins need to perform any specific AD tasks. This can be delegated on the OU level like we just did with the ‘Send as’ permission. Let’s say that we want to our Exchange Admins to do the following:

• Create/Delete Contact Objects
• Create/Delete Distribution Groups
• Create/Delete users

We can delegate the permissions for your Exchange Admins, which may then look like this. At this example, I’ve delegated all the permissions on the parent OU, which will then inherit down to all the Child OUs.

References

• Configure Exchange Server for split permissions: https://learn.microsoft.com/en-us/exchange/permissions/split-permissions/configure-exchange-for-split-permissions?view=exchserver-2019
• Understanding split permissions: https://learn.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help
• aclpwn.py: Active Directory ACL exploitation with BloodHound: https://securityonline.info/aclpwn/