How MS Exchange on-premises compromises Active Directory and what organizations can do to prevent that.

At SpecterOps, we recommend our customers establish a security boundary around their most critical assets (i.e., Tier Zero) of Active Directory (AD). We help them find and remediate the attack paths that cross this security boundary with BloodHound Enterprise. One of the most common challenges we and our customers face is Microsoft Exchange on-premises (Exchange).

If you compromise Exchange in AD, you are almost guaranteed an attack path to full control over the domain because of the extensive AD permissions Exchange has. It has been like this for many years; Microsoft has reduced many permissions, but the problem remains.

In this blog post, we will explore what permissions Exchange has in AD that an attacker can abuse to compromise the domain; what effect the different Exchange permission model has in terms of compromising AD permissions; and what organizations can do to reduce the permissions such that the compromise of Exchange does not provide an attack path to full control of the domain.

Acknowledgments

A big thank you to the following people for their work which I have used in this blog post:

• Géraud de Drouas for the GitHub repo documenting Exchange AD attacks: Exchange-AD-Privesc
• Shay Ber for describing how DnsAdmins can compromise DCs: Feature, not bug: DNSAdmin to DC compromise in one line
• Dirk-jan Mollema for describing AD property sets: Abusing forgotten permissions on computer objects in Active Directory
• Oliver Lyak for describing the ESC9 and ESC10 abuse techniques: Certipy 4.0: ESC9 & ESC10, BloodHound GUI, New Authentication and Request Methods — and more!
• Charlie Clark for describing how explicit Kerberos mapping can be abused: CVE-2021–42287/CVE-2021–42278 Weaponisation
• Jean Marsault for describing how explicit certificate mapping can be abused: Microsoft ADCS — Abusing PKI in Active Directory Environment
• Hans-Joachim Knobloch for describing how explicit certificate mapping can be abused: Nilpferde, NDES und goldene Zertifikate als Schlüssel zum AD
• Ali Tajran for describing how to remove Exchanges permissions in AD: How to remove Exchange from Active Directory
• TEAL for describing how to configure relevant Exchange permissions in AD: Exchange Split Permission — AD Permissions and Processes

Exchange Attack Paths in the Past

When you install Exchange, the installation will create a set of Exchange AD groups for the Exchange admin users and the Exchange servers and grant those groups a lot of permissions in AD. Traditionally, that set of permissions has been very extensive and included permissions allowing Exchange to gain full control over the AD environment. For example, the group Exchange Windows Permissions used to have WriteDACL permission on the domain object by default, allowing the group to grant DCSync permissions and thereby compromising the domain.

However, Microsoft has reduced the Exchange permissions over time, such that an attacker that has compromised an Exchange server does not have a direct attack path to compromise the domain today. Microsoft fixed the WriteDACL permission on the domain object with a cumulative update for Exchange in 2019 (described here). Furthermore, the same update, “returns all environments to a common, reduced directory permission profile”, meaning that the update removed old unnecessary permissions. Later the same year, Microsoft introduced two deny permissions on the DnsAdmins group, to prevent Exchange groups from being able to compromise the domain using the attack described by Shay Ber here: Feature, not bug: DNSAdmin to DC compromise in one line.

Does that mean Exchange is harmless today? Not in the least.

What Can Exchange Do Today, BloodHound?

I have installed Exchange Server 2019 in my AD lab with the default shared permissions model (more on the different permission models in the next section). Running BloodHound reveals that the Exchange Windows Permissions group is still quite privileged in AD:

Exchange Windows Permissions has the following compromising permissions:

On users (without ACL inheritance disabled)

• WriteDACL: Permission to add any permission, including full control
• ForceChangePassword: Permission to reset the user’s password

On groups (without ACL inheritance disabled)

• AddMember: Permission to add members to the group

The permissions effectively allow you to compromise the users and groups in the sense that you can log in as the users and you can obtain membership in the groups. The permissions are set on the domain object with Access Control List (ACL) inheritance set to users/groups and will therefore apply to all users and groups in the domain except the ones having ACL inheritance disabled, like the users and groups that are AdminSDHolder protected:

Account Operators
Administrator
Administrators
Backup Operators
Domain Admins
Domain Controllers (The group)
Enterprise Admins
Enterprise Key Admins (Missing in the MS documentation)
Key Admins (Missing in the MS documentation)
KRBTGT
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators

Be aware that AdminSDHolder also protects the members of the above groups, including nested members, but not computer object members. The AdminSDHolder protection only works because the AdminSDHolder object has ACL inheritance disabled. The protection will become ineffective if you enable ACL inheritance on the object.

The Exchange Windows Permissions group has the Exchange servers of the AD environment as members through the Exchange Trusted Subsystem group by default. Both groups and the exchange servers are under the control of a third Exchange group called Organization Management:

The Organization Management group will have the Exchange admin users as members; this means that compromising either the Exchange servers or an Exchange admin user provides the privileges of the Exchange Windows Permissions group.

The permissions of the Exchange Windows Permissions group do not enable you to compromise the domain by default, as Domain Admins members and other privileged users are AdminSDHolder protected and not under Exchange Windows Permissions’ control. However, AdminSDHolder does not protect all Tier Zero users and groups and Exchange Windows Permissions will likely have an attack path to the domain anyway. For example, you can compromise any service account with the default ACL inheritance enabled. A common example of a Tier Zero service account is the Microsoft Entra Connect (formerly known as Azure AD Connect) service account ( i.e., AD DS Connector Account, typically named MSOL_nnnnnnnnnnnn). This account is very privileged in most configurations. For example, it must have GetChanges and GetChangesAll permissions on the domain object for the password hash sync feature to work, as Microsoft describes here. These permissions enable the DCSync attack which compromises the entire AD domain. You can protect the service account from inherited permissions by performing the Restrict Permissions on the AD DS Connector Account step of the Microsoft Entra Connect setup, but I have personally seen many environments where this has not been done and where there is an attack path from the Exchange Windows Permissions group to the domain through the AD DS Connector Account:

It is also important to remember that the attacker may not need to compromise the domain to execute their objectives. Suppose they have one or more business-critical systems as targets. In that case, they probably do not need to compromise Domain Admins to get to those targets and the Exchange Windows Permissions group will likely have an attack path to the systems with its extensive permissions.

The above Exchange permissions are true for Exchange configured in the default shared permissions model. What if you have configured Exchange in a more strict permission model? We will in the next section answer that question by taking a deeper dive into the AD permissions granted in the three Exchange permission models.

Exchange Models and Permissions in AD

You can configure Exchange after three different permission models:

1. Shared permission model (default)
2. Role-Based Access Control (RBAC) split permissions model
3. AD split permissions model

The purpose of the split models is to facilitate a management split of Exchange and AD. You can find Microsoft documentation for the models at Split permissions in Exchange Server.

Microsoft has documented the AD permissions of Exchange in the Exchange 2013 deployment permissions reference, but there is no similar documentation for Exchange 2016 and Exchange 2019 to my knowledge, unfortunately. Therefore, to check the AD permissions of Exchange in the different models, I installed Exchange Server 2019 in the default shared permission model in my lab, changed it to the RBAC split permission model, and changed it to the AD split permission model. Between each step, I ran SharpHound and a PowerShell script to list all non-inherited Access Control Entries (ACEs) of AD objects in the Domain Naming Context (NC), the Configuration NC, and the Schema (including the default security descriptor) using Get-AllADACLs.ps1. This allowed me to use Get-ACLDiff.ps1 to review and compare the AD permissions of the different models.

Before we dive into the AD permissions of the different models, it is important to have a basic understanding of Exchange Roles and RBAC.

Exchange Roles and RBAC

Exchange has its own RBAC authorization system. When a user attempts to perform an action in the Exchange Management Shell or the Exchange Admin Center interface, Exchange checks whether the user has an Exchange role that allows the user to perform the action according to the RBAC model. If RBAC authorizes the user, the user can perform the action regardless of their AD permissions. It is Exchange that executes the action, so AD will only allow the action if the Exchange server’s computer object has the required permissions in AD. The Exchange server has its permissions through the Exchange Trusted Subsystem group and Exchange Windows Permissions group, which we saw in the previous section.

The administrative Exchange roles exist in AD as universal security groups:

This includes the Organization Management group, which is the most privileged Exchange role. We will not cover what each of the Exchange role groups can do, as our focus for this blog post is what an attacker can do if they compromise Exchange and not just a limited Exchange role.

Exchange Shared Permission Model

The shared permission model is the default model. Exchange Trusted Permissions, Exchange Windows Permissions, and some of the Exchange role groups have permissions in AD with this model; however, most of the permissions are non-compromising like read and write access to Exchange-specific attributes. The permissions that result in outbound BloodHound edges to non-Exchange objects are the ones described in the What Can Exchange Do Today, BloodHound? section.

You can see all the AD permissions added to existing AD objects of my AD lab when I installed Exchange Server 2019 here: Exchange-AD-ACL-testing/01 Exchange installed diff.

Exchange RBAC Split Permissions Model

The RBAC split model is Microsoft’s favorite: (from Microsoft’s documentation)

“If your organization chooses to use a split permissions model instead of shared permissions, we recommend that you use the RBAC split permissions model. The RBAC split permissions model provides significantly more flexibility while providing the nearly same administration separation as Active Directory split permissions, with the exception that Exchange servers and services can create security principals in the RBAC split permissions model.”

It sounds promising, but what I found when I changed my Exchange deployment to this model was that not a single ACE in the Domain NC was added or removed outside the Microsoft Exchange Security Groups Organizational Unit (OU) and the Microsoft Exchange System Objects container. Likewise, in the Configuration NC, there were only changes in the Microsoft Exchange container. The attack paths under the shared permission model from the Exchange server/admin to users and groups are therefore also valid in the RBAC split model.

From the documentation of the model, we can read that the “RBAC split” refers to the permission being split in Exchange RBAC rather than in AD. This explains why we do not see more changes in AD. So, to be fair, I assume it might not be entirely the same picture, as the RBAC split mode gives you better options for delegating limited control in Exchange RBAC. However, from the perspective of an attacker with control over an Exchange server/admin, it seems the same.

AD Split Permission Model

Microsoft writes this about the AD split model:

“Several changes are made to the permissions granted to the Exchange Trusted Subsystem and Exchange servers to limit what Exchange administrators and servers can do. … Exchange servers and the Exchange management tools can only modify the Exchange attributes of existing security principals in Active Directory.”

That is correct. The Exchange Windows Permissions group changes a lot with the AD split model:

• The group is now empty; the Exchange Trusted Permissions group is no longer a member
• Inbound permissions on the group are limited to default privileged groups (i.e. Domain Admins, Enterprise Admins, etc.) meaning that Exchange Trusted Subsystem and Organization Management lost their permissions on the group
• All ACEs assigned to the group are gone except for a single deny ACE on the domain

The result of the AD split model is that the BloodHound attack paths from Exchange admins and Exchange servers to all users and groups with ACL inheritance enabled are effectively remediated. It is also worth noting that the Exchange no longer has permission to create AD users, groups, and computers (and some other classes), as Exchange Windows Permissions held that.

You can see the full list of AD permissions removed in my AD lab (on non-Exchange AD objects) after the configuration of the AD split permission model, at Exchange-AD-ACL-testing/02 AD split deployed diff.

There are still several AD permissions granted to the Exchange groups, even with the AD split permission model. In the next section, we will take a closer look at some of those.

A Closer Look Into Exchange AD Permissions

The Exchange groups have several permissions on non-Exchange AD objects even if you deploy the Exchange AD split model. None of these permissions result in BloodHound edges, but some of them are still quite juicy.

Write Personal-Information Property Set

The Exchange Trusted Subsystem group has permission to write to the Personal-Information property set on AdminSDHolder and on the domain object with ACL inheritance enabled:

ObjectDN              : DC=external,DC=local
InheritedObject       : 
Object                : Personal-Information
ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : 77b5b886-944a-11d1-aebd-0000f80367c1
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXTERNAL\Exchange Trusted Subsystem
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

ObjectDN              : CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject       : 
Object                : Personal-Information
ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : 77b5b886-944a-11d1-aebd-0000f80367c1
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : EXTERNAL\Exchange Trusted Subsystem
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

That means the group can write to the attributes of this property set on all AD objects the property set applies to. Microsoft’s documentation for the Personal-Information property set defines the attributes that are part of the property set for different Windows versions. The msDS-AllowedToActOnBehalfOfOtherIdentity attribute is part of the property set for the latest Windows version in the documentation. AD security enthusiasts (like me) will know that write access to this attribute on a computer enables an attacker to compromise the host of the computer with an RBCD attack. So it looks like Exchange Trusted Subsystem can compromise any host in the AD environment. I tested the attack, but when attempting to write to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, I got an “access denied” error.

The wiser AD security enthusiasts (in other words, not me) will know that the msDS-AllowedToActOnBehalfOfOtherIdentity attribute has moved to the User-Account-Restrictions property set as explained by Dirk-jan Mollema in his Abusing forgotten permissions on computer objects in Active Directory blog post. The Microsoft documentation only goes up to Windows Server 2012 and msDS-AllowedToActOnBehalfOfOtherIdentity moved after, which is why you cannot see the current property set of the attribute.

To save others from the same disappointing feeling, I made a PowerShell script to print out all property sets of an AD environment named Get-PropertySets.ps1. The script also includes the output from my lab environment as a comment block, so you do not necessarily have to run it.

Write Public-Information Property Set

The Exchange Trusted Subsystem group has the permission to write to the Public-Information property set on AdminSDHolder and on the domain object with ACL inheritance enabled, just like for the Personal-Information property set. The Public-Information property set contains the following attributes:

Additional-Information (notes)
Allowed-Attributes (allowedAttributes)
Allowed-Attributes-Effective (allowedAttributesEffective)
Allowed-Child-Classes (allowedChildClasses)
Allowed-Child-Classes-Effective (allowedChildClassesEffective)
Alt-Security-Identities (altSecurityIdentities)
Common-Name (cn)
Company (company)
Department (department)
Description (description)
Display-Name-Printable (displayNamePrintable)
Division (division)
E-mail-Addresses (mail)
Given-Name (givenName)
Initials (initials)
Legacy-Exchange-DN (legacyExchangeDN)
Manager (manager)
ms-DS-Allowed-To-Delegate-To (msDS-AllowedToDelegateTo)
ms-DS-Auxiliary-Classes (msDS-Auxiliary-Classes)
ms-DS-Approx-Immed-Subordinates (msDS-Approx-Immed-Subordinates)
ms-DS-Phonetic-First-Name (msDS-PhoneticFirstName)
ms-DS-Phonetic-Last-Name (msDS-PhoneticLastName)
ms-DS-Phonetic-Department (msDS-PhoneticDepartment)
ms-DS-Phonetic-Company-Name (msDS-PhoneticCompanyName)
ms-DS-Phonetic-Display-Name (msDS-PhoneticDisplayName)
ms-DS-HAB-Seniority-Index (msDS-HABSeniorityIndex)
ms-DS-Source-Object-DN (msDS-SourceObjectDN)
Obj-Dist-Name (distinguishedName)
Object-Category (objectCategory)
Object-Class (objectClass)
Object-Guid (objectGUID)
Organization-Name (o)
Organizational-Unit-Name (ou)
Other-Mailbox (otherMailbox)
Proxy-Addresses (proxyAddresses)
RDN (name)
Reports (directReports)
Service-Principal-Name (servicePrincipalName)
Show-In-Address-Book (showInAddressBook)
Surname (sn)
System-Flags (systemFlags)
Text-Country (co)
Text-Encoded-OR-Address (textEncodedORAddress)
User-Principal-Name (userPrincipalName)

We will explore the ones that seemed interesting to me.

Write Service-Principal-Name

Out of the list in the previous section, the Service-Principal-Name (SPN) attribute stands out. Write access to this attribute allows you to perform targeted Kerberoasting. Géraud de Drouas has described this attack here: Write Public-Information ACE leads to Kerberoasting from Exchange security groups.

However, as Géraud’s article explains, Microsoft has added specific deny ACEs to block write access to the SPN attribute specifically:

ObjectDN              : DC=external,DC=local
InheritedObject       : 
Object                : Service-Principal-Name
ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : f3a64788-5306-11d1-a9c5-0000f80367c1
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Deny
IdentityReference     : EXTERNAL\Exchange Trusted Subsystem
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

ObjectDN              : CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject       : 
Object                : Service-Principal-Name
ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : f3a64788-5306-11d1-a9c5-0000f80367c1
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Deny
IdentityReference     : EXTERNAL\Exchange Trusted Subsystem
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

The deny ACEs mean the attack is prevented.

Write User-Principal-Name

The User-Principal-Name (UPN) attribute is more interesting. Oliver Lyak demonstrated in the ESC9 and ESC10 blog post how an attacker can abuse write access to this attribute of a controlled user or computer to compromise any user or computer in the AD forest. The ESC9 and ESC10 attacks with UPN abuse go like this:

1. Overwrite the UPN of an attacker-controlled principal (i.e., victim) to be either the SAM-Account-Name attribute of a targeted user or [email protected] of a targeted computer
2. Enroll for a certificate that allows for (client) authentication as the victim
3. Change the UPN of the victim to something else, such that it does not match the UPN in the certificate
4. Authenticate as the targeted principal

Check out Oliver Lyak’s blog post to see a demonstration of the attack.

The key requirements for the attack depend on whether the attacker chooses Kerberos (PKINIT) or Schannel authentication. Kerberos authentication requirements:

• A Domain Controller (DC) allows weak certificate mapping for Kerberos, meaning that the StrongCertificateBindingEnforcement DC registry key value is set to 0 or 1 (not 2)
  – The default value is 1
  – The 0 value has been interpreted as 1 (i.e., compatibility mode) since April 2023, as documented here
  – Strong certificate mapping will be enforced by February 11, 2025
• The certificate does not include the SID extension, which requires the certificate template to contain the CT_FLAG_NO_SECURITY_EXTENSION flag in the msPKI-Enrollment-Flag attribute (not present by default)

Schannel authentication requirements:

• A DC allows UPN (weak) certificate mapping for Schannel, meaning that the CertificateMappingMethods DC registry key value contains the UPN flag (i.e., 0x04) (not present by default)

Members of the Exchange Trusted Permissions group can abuse the write Public-Information permission to overwrite the UPN of their account and compromise any user or computer in the AD forest if the ESC9/ESC10 requirements are met, even if you have configured Exchange in the AD split permission model; however, it does require that the AD environment has specific non-default and insecure AD Certificate Services (ADCS) configurations enabled.

Write Alt-Security-Identities

The Public-Information property set also includes Alt-Security-Identities, with the following Microsoft description: “Contains mappings for X.509 certificates or external Kerberos user accounts to this user for the purpose of authentication”. There is a more detailed description at User Security Attributes and KB5014754 — Certificate-based authentication changes on Windows domain controllers.

The “mappings” you can add in the attribute are strings that follow a defined pattern. To map an external Kerberos user with the UPN [email protected] to a given user, you would have to add this mapping string: Kerberos:[email protected]. The X.509 certificate mapping gives you options to use different property values of a certificate:

These X.509 certificate mappings are known as explicit certificate mappings, as you explicitly define mapping instead of letting the DC implicitly find the matching principal based on UPN or the SAM-Account-Name value.

Before you get too excited, there are two deny write access to Alt-Security-Identities ACEs in place on the domain object and AdminSDHolder, targeting Exchange Trusted Subsystem:

ObjectDN              : DC=external,DC=local
InheritedObject       : Computer
Object                : Alt-Security-Identities
ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType   : bf967a86-0de6-11d0-a285-00aa003049e2
ObjectFlags           : ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType     : Deny
IdentityReference     : EXTERNAL\Exchange Trusted Subsystem
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

ObjectDN              : CN=AdminSDHolder,CN=System,DC=external,DC=local
InheritedObject       : Computer
Object                : Alt-Security-Identities
ActiveDirectoryRights : WriteProperty
InheritanceType       : All
ObjectType            : 00fbf30c-91fe-11d1-aebc-0000f80367c1
InheritedObjectType   : bf967a86-0de6-11d0-a285-00aa003049e2
ObjectFlags           : ObjectAceTypePresent, InheritedObjectAceTypePresent
AccessControlType     : Deny
IdentityReference     : EXTERNAL\Exchange Trusted Subsystem
IsInherited           : False
InheritanceFlags      : ContainerInherit
PropagationFlags      : None

What is interesting, though, is that they apply to the current object and descendant computer objects only. That means that Exchange Trusted Subsystems can still write to Alt-Security-Identities of all users with ACL inheritance enabled (e.g., not AdminSDHolder protected). Let us see what that allows us to do.

Kerberos Explicit Mapping
It seems like it was possible to abuse the Kerberos explicit mapping before the No PAC patch. Charlie Clark demonstrates in his CVE-2021–42287/CVE-2021–42278 Weaponisation blog post how an attacker in one domain with write permission on Alt-Security-Identities of a target user in another domain allows the attacker to compromise the target user with the following steps:

1. Add the “Kerberos:[email protected]” mapping string to the Alt-Security-Identities attribute of the target user with the UPN of the attacker user
2. Request a Kerberos Ticket-Granting Ticket (TGT) with no Privilege Attribute Certificate (PAC) as the attacker user from its local domain
3. Use the TGT to request an inter-realm TGT to the domain of the targeted user
4. Use the inter-realm TGT to request a service ticket for the domain of the targeted user

The service ticket received in the last step contains the PAC of the targeted user and enables the attacker to impersonate the targeted user.

The “No PAC” patch made it impossible to get a TGT without a PAC from an AD Kerberos Key Distribution Center (KDC). I attempted to execute the attack in a patched environment where the TGT had a PAC and it did not work, however, I assume that it is possible to pull off the attack from a non-Windows KDC realm with inbound trust from the AD domain of the target user, as it should be possible to obtain a TGT with no PAC from there.

X.509 Certificate Explicit Mapping
An explicit certificate mapping is a reference to a certificate. Anyone with a certificate matching the reference of a principal’s explicit certificate mapping can use their certificate to authenticate as the principal. An attacker can therefore abuse write access to the Alt-Security-Identities attribute of an AD user to add an explicit certificate mapping referring to a certificate in the attacker’s possession, and then use this certificate to authenticate as that user.

This abuse technique was first documented in 2019, where Géraud de Drouas described how an attacker that has compromised on-premises Exchange can perform the attack, on this GitHub page: Public-Information property set includes Alt-Security-Identities, allows x509 certificate mapping to privileged users. Additionally, Jean Marsault has demonstrated the attack in the Microsoft ADCS — Abusing PKI in Active Directory Environment blog post under the section named “ACL exploit on user objects (1)”. I have recently also looked into the abuse technique and published a blog post about it here: ADCS ESC14 Abuse Technique.

An attacker can execute the attack with the following steps:

1. Enroll a certificate in a certificate template that allows for (client) authentication
2. Add a (strong) explicit certificate mapping based on the certificate in the Alt-Security-Identities attribute of the target principal
3. Authenticate as the target principal using the certificate

The ADCS ESC14 Abuse Technique blog post describes the details of the requirements and includes a demonstration of the attack. An attacker can even abuse certificate templates configured for computer enrollment to compromise users. In a default environment, the attack is therefore possible using the Computer (Machine) certificate template, which grants “Enroll” permission to the Domain Computers group.

This means that an attacker with control over an Exchange admin or Exchange server can compromise any AD user with ACL inheritance enabled, even if you have configured Exchange in the AD split permission model.

An attacker who cannot enroll any certificates in the environment may even still be able to execute the attack. Hans-Joachim Knobloch explained in a LinkedIn thread that the KDC does not require that the DC trusts the issuer of a certificate for NT authentication when performing X509IssuerSubject, X509IssuerSerialNumber, X509SKI, or X509SHA1PublicKey explicit certificate mapping. Microsoft has visualized this behavior in a flow chart in the Certificate processing logic documentation and Hans has discussed it in a very interesting blog post here: Nilpferde, NDES und goldene Zertifikate als Schlüssel zum AD. It means that an attacker can potentially use a certificate of one of the many public root CAs that DCs trust by default in an attack, eliminating the need for enrollment rights in the AD environment.

Reduce Exchange’s Permissions in AD

If you (as an organization) are not using Exchange on-premises anymore (e.g. you are only using Exchange Online — not hybrid), then you should get rid of Exchange on-premises. Microsoft has provided some guidance on decommissioning Exchange servers: How and when to decommission your on-premises Exchange servers in a hybrid deployment. After you have decommissioned the Exchange servers, then you need to clean up the AD Exchange groups manually. There is a detailed guide provided by Ali Tajran here: How to remove Exchange from Active Directory.

If you do need Exchange on-premises, you can instead limit the AD permissions of Exchange. It is difficult to come up with a generic minimal set of AD permissions for the Exchange AD groups, as the usage of Exchange varies across organizations; however, it should be possible to identify what users and groups Exchange does not need any permissions on at all. Exchange should not need permissions on most if not all service accounts, admin users, and admin groups. Admin users do have mailboxes in some organizations. You should avoid that by implementing separate accounts for admins, to avoid exposing admin users to email attacks like phishing. An employee with a role that requires privileged (admin) access should get a separate admin account without a mailbox for their privileged access in addition to their regular work account with a mailbox.

There are multiple ways to prevent the Exchange AD permissions of the domain object from being applied to a given set of objects:

1. Move Exchange ACEs to the right OUs (recommended)
   You can move all the AD permissions the Exchange groups have on the AD domain object to the OUs where you have the groups and users relevant to Exchange. Practically, you have to add the ACEs on the OUs and then delete them from the domain object. You should confirm on the child users and computers that their ACLs are the same, and that ACL precedence (documented here) has not caused a change.
2. Block ACL inheritance on admin OUs
   It is common practice when implementing AD tiering to create a Tier Zero OU with inheritance disabled, such that permissions configured on the AD domain object will not apply to Tier Zero objects. This concept works as well for protecting AD objects against Exchange permissions. The disadvantage of blocking inheritance is that it becomes more complex to figure out where permissions apply in the environment.
3. Implement deny ACEs (not recommended)
   You could implement deny ACEs on admin OUs to block the permissions granted to the Exchange groups. ACL precedence is tricky, especially because explicit allow ACEs take precedence over inherited deny. To keep ACLs as simple as possible, I recommend avoiding deny ACEs.

The above recommendations are valid for Exchange configured in any permission model.

If you configure Exchange to the AD split model, Exchange will not have the same compromising permissions as the two other permission models. I therefore highly recommend considering the AD split model. I have limited knowledge about Exchange admin work and I do not know how big of a challenge it is for Exchange admins to adapt to the AD split model, but I have heard that it requires an effort. I recommend checking out Switch to Active Directory split permissions by Microsoft and this TEAL blog post that explains how to configure some of the permissions you might need to configure: Exchange Split Permission — AD Permissions and Processes.

If you choose to not go for the AD split model, then consider if you can reduce any of the three compromising permissions described in the What Can Exchange Do Today, BloodHound? section. For example, it might not be necessary for Exchange to be able to reset the password of regular users, even if they have a mailbox.

Reducing the Exchange Trusted Subsystems group’s write permission to the Alt-Security-Identities attribute on users is tricky, as the permission is granted through write access to the Public-Information property set. To avoid deny ACEs, you could replace write access to the property set with write access to the individual attributes in the property set; however, that will increase the number of ACEs significantly for a large property set like Public-Information. Attributes can only belong to a single property set, so creating a custom property set containing a subset of an original property set is not an option unless you remove the attributes from the original one. The best solution, as I see it, is therefore modifying the existing deny write to Alt-Security-Identities ACE for Exchange Trusted Subsystem on the domain object to hit objects of all classes instead of only computers. You can use this PowerShell script to check what users have the attribute set to get an idea of the usage of the attribute in the organization before you implement changes: Get-AltSecIDMapping.ps1.

Lastly, you should also check what non-default AD permissions Exchange has gained over the years. Exchange typically has compromising permissions configured directly on the users, computers, and groups Exchange has created in AD. You can use this Cypher query in BloodHound to find outbound ACL edges made from non-inherited ACEs from Exchange groups to AD objects outside the Exchange OUs and containers:

MATCH p = (g:Group)-[r]->(x)
WHERE g.distinguishedname CONTAINS "MICROSOFT EXCHANGE"
  AND NOT x.distinguishedname CONTAINS "MICROSOFT EXCHANGE"
  AND r.isinherited = FALSE
RETURN p LIMIT 100

Do involve your Exchange admins in the process of reducing the AD permissions of Exchange, as they can help you determine what permissions are necessary and check that things are working as expected after you apply changes. I also recommend that you document permissions before and after the change and prepare a way to restore removed permissions in case something breaks (e.g., using a script).

If you do not feel like reducing the AD permissions of Exchange at all, then you should consider the Exchange AD groups Exchange Windows Permissions and Exchange Trusted Subsystem as Tier Zero; however, I do advise against that. Exchange servers in Tier Zero increase the attack surface of Tier Zero and that means that you should restrict access to the Exchange servers in the same way you do DCs.

Conclusion

This blog post has explored the compromising AD permissions of Microsoft Exchange and we have assessed the Exchange permission models (i.e., shared, RBAC split, and AD split). We have found that the shared model and the RBAC split model allow an attacker who has compromised an Exchange admin or Exchange server to add themself to any AD group and compromise (takeover) any AD user unless disabled ACL inheritance protects the targeted group or user. Furthermore, we have found that an Exchange admin can compromise the same users using explicit certificate mapping abuse (ESC14) and that this attack is even possible in the more strict AD split model.

It is possible to limit the AD permissions of Exchange. You can change Exchange to use the AD split model and thereby resolve the compromising AD Exchange permissions except the one allowing ESC14, which you can remediate as a separate effort. AD split model or not, you can also limit the scope of users and groups Exchange has permissions over; for example, by moving the permission from the domain object to the OUs containing users and groups where Exchange actually needs permissions.

Pwned by the Mail Carrier was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from Posts By SpecterOps Team Members - Medium authored by Jonas Bülow Knudsen. Read the original post at: https://posts.specterops.io/pwned-by-the-mail-carrier-0750edfad43b?source=rss----f05f8696e3cc---4