# Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

{{#include ../../../banners/hacktricks-training.md}}

## Basic Information

In legacy Exchange Hybrid designs, the on-prem Exchange deployment could authenticate as the same Entra application identity used by Exchange Online. If an attacker compromised the Exchange server, extracted the hybrid certificate private key, and performed an OAuth client-credentials flow, they could obtain first-party tokens with Exchange Online privilege context.

The practical risk was not limited to mailbox access. Because Exchange Online had broad back-end trust relationships, this identity could interact with additional Microsoft 365 services and, in older behavior, could be leveraged for deeper tenant compromise.

## Attack Paths and Technical Flow

### Modify Federation Configuration via Exchange

Exchange tokens historically had permissions to write domain/federation settings. From an attacker perspective, this enabled direct manipulation of federated domain trust data, including token-signing certificate lists and configuration flags that controlled MFA-claim acceptance from on-prem federation infrastructure.

That means a compromised Exchange Hybrid server could be used to stage or reinforce ADFS-style impersonation by changing federation config from the cloud side, even when the attacker started only from on-prem Exchange compromise.

### ACS Actor Tokens and Service-to-Service Impersonation

Exchange's hybrid auth path used Access Control Service (ACS) actor tokens with `trustedfordelegation=true`. Those actor tokens were then embedded into a second, unsigned service token that carried the target user identity in an attacker-controlled section. Because the outer token was unsigned and the actor token delegated broadly, the caller could swap target users without re-authenticating.

In practice, once the actor token was obtained, the attacker had a long-lived impersonation primitive (typically around 24 hours) that was difficult to revoke mid-lifetime. This enabled user impersonation across Exchange Online and SharePoint/OneDrive APIs, including high-value data exfiltration.

Historically, the same pattern also worked against `graph.windows.net` by building an impersonation token with the victim's `netId` value. That provided direct Entra administrative action as arbitrary users and enabled full-tenant takeover workflows (for example, creating a new Global Administrator account).

## What No Longer Works

The `graph.windows.net` impersonation path via Exchange Hybrid actor tokens has been fixed. The old "Exchange to arbitrary Entra admin over Graph" chain should be considered removed for this specific token route.

This is the most important correction when documenting the attack: keep the Exchange/SharePoint impersonation risk separate from the now-patched Graph impersonation escalation.

## What Can Still Matter in Practice

If an organization still runs an old or incomplete hybrid configuration with shared trust and exposed certificate material, Exchange/SharePoint impersonation impact can remain severe. The federation-configuration abuse angle can also remain relevant depending on tenant setup and migration state.

Microsoft's long-term mitigation is splitting the on-prem and Exchange Online identities so the shared-service-principal trust path no longer exists. Environments that completed that migration materially reduce this attack surface.

## Detection Notes

When this technique is abused, audit events can show identity mismatches where the user principal name corresponds to an impersonated user while the display/source context points to Exchange Online activity. That mixed identity pattern is a high-value hunting signal, though defenders should baseline legitimate Exchange-admin workflows to reduce false positives.

## References

- [https://www.youtube.com/watch?v=rzfAutv6sB8](https://www.youtube.com/watch?v=rzfAutv6sB8)

{{#include ../../../banners/hacktricks-training.md}}
