Exchange Privilege Escalation WriteDacl Domain Active Directory: How a Decade-Old Install Still Hands Out Domain Admin

What Is Exchange Privilege Escalation WriteDacl Domain Active Directory

Exchange privilege escalation WriteDacl domain Active Directory misconfigurations rank among the most consequential defaults still sitting untouched in environments that installed on-premises Exchange Server at any point in the last decade. When Exchange Server 2013, 2016, or 2019 is set up with Microsoft's default shared permissions model, the Exchange Windows Permissions security group is granted WriteDacl — the right to modify the discretionary access control list (DACL) — directly on the domain object at the root of Active Directory. That single access control entry (ACE), a few links down a short chain, is enough to hand an attacker Domain Admin-equivalent access across the entire forest, not just the Exchange organization.

The Exchange Trusted Subsystem group — the service identity every Exchange server uses to act in AD on behalf of end users through Exchange's Role Based Access Control (RBAC) model — is itself nested inside Exchange Windows Permissions by default (Microsoft Learn, "Split permissions in Exchange Server"). Anyone who can add an account to Exchange Trusted Subsystem, or who compromises an Exchange server outright, inherits the WriteDacl right on the domain object.

Why this isn't "just" CVE-2019-1166

This is not a single patchable CVE: Microsoft's own split-permissions documentation frames it as an architectural default of the shared permissions model, not a vulnerability with a fix release. That distinction matters, because catalogue text on this finding is sometimes cross-referenced against CVE-2019-1166 — a real CVE, but one that covers an unrelated NTLM Message Integrity Check (MIC) bypass ("Drop the MIC 2," discovered by the Preempt Research Team and patched by Microsoft in the October 2019 Patch Tuesday, per Praetorian's advisory). That patch, and its June 2019 sibling CVE-2019-1040, hardened NTLM relay defenses generally; neither one touched the WriteDacl ACE Exchange leaves on the domain object. Organizations that installed both without ever adopting split permissions remain exposed today, and a fully patched domain controller tells you nothing about whether this ACE is still there — see our broader breakdown of ACL abuse and DCSync paths to Domain Admin for how these access grants compound with other Active Directory misconfigurations.

How It Works: From Exchange Windows Permissions to DCSync

The default privilege chain

The chain from an over-privileged (or simply compromised) Exchange identity to full domain compromise is short:

1. Exchange Windows Permissions holds a WriteDacl ACE on the domain object.
2. Exchange Trusted Subsystem is a member of Exchange Windows Permissions by default.
3. Members of the Organization Management RBAC role group can modify the membership of other Exchange security groups, including Exchange Trusted Subsystem (ADSecurity.org, "Mitigating Exchange Permission Paths to Domain Admins in Active Directory"; Trimarc Security).
4. Anyone in that chain — or anyone who compromises an Exchange server's machine account directly — can use the WriteDacl right to write a new ACE onto the domain object granting DS-Replication-Get-Changes and DS-Replication-Get-Changes-All, the two extended rights DCSync depends on.
5. From there, a replication request pulls every password hash in the domain, krbtgt included. This is the same replication-rights abuse we cover in our audit guide to ACL, DPAPI, tombstone, and schema permissions — Exchange is simply the most common source of the grant, not the only one.

# Read-only enumeration: does Exchange Windows Permissions (or a nested group)
# still hold WriteDacl on the domain object?
dsacls "DC=corp,DC=local" | Select-String "Exchange Windows Permissions|WRITE DAC"

The 2019 PrivExchange amplification

In January 2019, researcher Dirk-jan Mollema showed the default didn't even require an existing foothold in an Exchange group. Exchange's PushSubscription feature could be abused to force an Exchange server's own machine account to authenticate, over HTTP, to an attacker-controlled endpoint. Because NTLM over HTTP does not set the signing-required flag by default, that authentication could be relayed to LDAP and combined with the server's WriteDacl right to grant the attacker DCSync privileges — triggerable by any mailbox user (dirkjanm.io, "Abusing Exchange: one API call away from Domain Admin"). Microsoft's February 2019 Exchange cumulative updates addressed this from two directions: KB4490060 changed the Exchange Web Services Push Notification authentication contract so subscriptions no longer stream credentials that could be coerced into an outbound authentication, and KB4490059 documented how to reduce Exchange's default Active Directory permissions going forward — but neither fix, nor the later NTLM MIC-bypass patches, strips an ACE that was already written to a domain object years earlier.

A common real-world variant compounds this further: organizations that migrated mailboxes to Exchange Online frequently keep one on-premises Exchange server around purely for AD attribute management, because Microsoft's hybrid guidance has historically discouraged fully removing the last on-prem server. That retained server, and the AD groups behind it, keep carrying the same WriteDacl grant indefinitely — which is exactly how a decade-old install ends up handing out Domain Admin in an environment where nobody thinks of Exchange as "in scope" anymore, long after the mailboxes themselves moved to the cloud.

Detection

Directory Service Access and Directory Service Changes auditing are not enabled by default on domain controllers, and even when they are, Event ID 4662 only fires for objects that carry a matching SACL. Both gaps need to be closed before any of the following indicators will actually appear in your logs (Altered Security, "A primer on DCSync attack and detection"). Our Active Directory monitoring guide to the event IDs that matter covers the audit-policy prerequisites for all of these in more depth.

Log-based detection

Proactive enumeration

Because the ACE itself can be years old and silent — it doesn't generate a fresh event just by existing — event-log monitoring should be paired with periodic proactive enumeration: dsacls or Get-Acl "AD:\<domain DN>" against the domain object, or a BloodHound collection specifically checked for a WriteDacl edge landing on the domain node. Treat this the same way you'd treat privileged access drift: a point-in-time audit only proves the ACE wasn't there on the day you checked, not that it stays gone afterward.

Remediation

Immediate compensating controls

1. Enumerate. Run dsacls or Get-Acl against the domain object and check for Exchange Windows Permissions / Exchange Trusted Subsystem holding WriteDACL; cross-check against a BloodHound collection for the same edge.
2. Reduce the immediate blast radius if a full split-permissions migration isn't feasible yet: remove Exchange Trusted Subsystem from Exchange Windows Permissions, and require a change-controlled, logged process for any future addition to Organization Management, Exchange Windows Permissions, or Exchange Trusted Subsystem (Trimarc Security).

The permanent fix

3. Adopt Microsoft's split-permissions model. RBAC split permissions is Microsoft's recommended default; Active Directory split permissions gives full separation between Exchange and AD administration. Both require rerunning Setup with /PrepareAD /ActiveDirectorySplitPermissions:true, plus /PrepareAllDomains (or a per-domain /PrepareDomain) in multi-domain forests (Microsoft Learn, "Split permissions in Exchange Server"). This is what actually strips the Exchange Windows Permissions ACEs from the domain object — not a Windows or Exchange security patch.
4. Decommission cleanly. If Exchange has already been migrated off-prem or retired, confirm the domain object ACE was removed as part of that process. Exchange deprovisioning does not automatically retroactively strip a prior WriteDacl grant, which is exactly how a decade-old install keeps handing out Domain Admin long after the last Exchange server was turned off.
5. Verify. Re-run the enumeration from step 1 after remediation and confirm DS-Replication-Get-Changes(-All) rights on the domain object are limited to domain controllers and explicitly authorized replication accounts only. Fold this check into a recurring audit workflow rather than a one-time cleanup, since re-enabling shared permissions or re-adding Exchange Trusted Subsystem to Exchange Windows Permissions silently restores the ACE without any obvious warning sign.

How EtcSec Detects This

EtcSec's Active Directory audit flags this pattern directly through the Exchange Privilege Escalation Risk check (EXCHANGE_PRIV_ESC_PATH), which inspects the domain object's ACL for the Exchange Windows Permissions WriteDacl grant and traces group nesting back to it. It's correlated against the broader ACL WriteDACL (ACL_WRITEDACL) and DS-Replication-Get-Changes Rights (DCSync) (ACL_DS_REPLICATION_GET_CHANGES) checks, plus the general DCSync Capable (DCSYNC_CAPABLE) rollup, so a full Exchange-to-DCSync attack path surfaces as one prioritized finding instead of four disconnected ACL entries, whether it originated from a live Exchange server or a decade-old leftover nobody remembered to decommission.