Microsoft Exchange has always been one of the services most deeply integrated with Active Directory.
And that’s exactly why it deserves more attention than it usually gets.
When administrators think about Exchange, they think about email.
Attackers think about Active Directory.
Because installing Exchange doesn’t simply deploy a mail server—it permanently changes your identity infrastructure.
It extends the Active Directory schema, creates privileged security groups, adds hundreds of Exchange-specific attributes, and delegates permissions across the domain.
Most of these changes are legitimate.
Very few are ever reviewed again.

Exchange Doesn’t Just Install a Mail Server

During installation, Exchange creates a trust relationship with Active Directory that goes far beyond mailbox management.
Among other things, it grants Exchange permissions to:

• Modify users and group memberships
• Write to sensitive attributes like ServicePrincipalName, msDS-AllowedToActOnBehalfOfOtherIdentity, and SIDHistory
• Delegate permissions across entire OUs
• Manage ACLs on users, computers, and even groups like Domain Admins

None of this is considered suspicious.
It’s simply Exchange doing what it was designed to do.
The problem is that these permissions often remain untouched for years, long after the original deployment—and long after anyone remembers why they were granted.

A Compromised Exchange Server Is a Bridge into Active Directory

Many organizations still keep Exchange on-premises for hybrid deployments or legacy requirements.
There’s nothing inherently wrong with that.
The risk begins when the Exchange server itself is compromised.
Once an attacker gains administrative control of Exchange, they may be able to:

• Modify group memberships, including admins
• Configure Resource-Based Constrained Delegation (RBCD).
• Register malicious Service Principal Names (SPNs) for Kerberoasting or Kerberos abuse.
• Abuse delegated permissions to escalate privileges.
• Reach Domain Admin using nothing more than legitimate Active Directory permissions.

No exploit is required.
No zero-day is required.
The permissions are already there.

The Hidden Risk: Automation

Exchange services themselves don’t run under privileged domain service accounts.
They typically execute as LocalSystem or under the computer account (for example, EXCH01$).
On paper, that’s a secure design.
In production environments, however, Exchange servers rarely remain “clean.”
Over time they accumulate:

• PowerShell automation.
• Scheduled tasks.
• Provisioning scripts.
• Hybrid synchronization tools.
• Reporting utilities.
• Administrative maintenance scripts

Many of these components run using privileged domain credentials.
Others contain cached or hardcoded credentials.
Few organizations review them regularly.
Compromising Exchange often means compromising everything built around Exchange.

Removing Exchange Doesn’t Remove Its Permissions

Now consider the opposite scenario.
You decommission Exchange.
The servers are gone.
The services are gone.
Surely the risk is gone too.
Not quite.
Active Directory rarely cleans itself.
Unless the environment is manually remediated, Exchange leaves behind:

• Configuration objects inside the CN=Configuration partition.
• Legacy groups such as Exchange Trusted Subsystem, Exchange Windows Permissions, and Organization Management.
• Delegated ACLs applied to users, Organizational Units, and domain objects.
• Exchange-specific attributes such as homeMDB, legacyExchangeDN, and numerous msExch* properties.

Even worse, if those privileged groups still exist and someone is accidentally—or intentionally—added to them, they may immediately inherit permissions nobody realizes are still active.
Autodiscover DNS records are another commonly forgotten artifact.
If they remain in place, attackers on the same network may be able to impersonate Exchange services and collect credentials.

The Real Threat: Invisible Privilege

None of this looks malicious.
Nothing generates obvious alerts.
Nothing appears unusual in security logs.
Exchange is simply exercising permissions that administrators intentionally granted years ago.
That’s precisely what makes the attack surface so dangerous.
This isn’t about vulnerabilities.
It isn’t about missing patches.
It isn’t even about Exchange itself.
It’s about legitimate privileges that quietly outlive the systems they were created for.
Invisible privilege is often the most dangerous privilege.

How to Reduce the Risk

Whether Exchange is still deployed or has already been removed, every Active Directory environment should be reviewed periodically.
Recommended actions include:
Audit delegated permissions granted to Exchange groups.
Review ACLs on privileged users, groups, and Organizational Units.
Remove obsolete Exchange security groups where possible.
Clean up Exchange configuration objects after decommissioning.
Review automation scripts for embedded credentials or excessive privileges.
Monitor changes to privileged Active Directory objects.
Apply the principle of least privilege wherever possible.
Identity infrastructure should never be considered “set and forget.”

Final Thoughts

Exchange isn’t the problem.
Unreviewed privilege is.
The greatest risk isn’t the next Exchange vulnerability or the next critical CVE.
It’s the legitimate permissions Exchange received years ago—and never gave back.
If Exchange is still part of your infrastructure, monitor it as carefully as you monitor your Domain Controllers.
If Exchange is gone, make sure it has truly disappeared from Active Directory.
Because attackers don’t care whether the mail server is still running.
They care whether its privileges are.