AD RMS Root-Key Extraction Can Permanently Expose Protected Documents

Sep 10, 2026 · Original article ↗

Summary

The article details how an AD RMS Service Group member can extract a software-held SLC private key, decrypt documents protected by the deployment offline, and forge trusted identities. It explains detection gaps and limits of remediation.

Key points

A member of the AD RMS Service Group can export the SLC private key through the admin SOAP surface; the article assumes the member’s credentials are already compromised.
With the extracted key, an attacker can decrypt any document protected by that deployment offline, without RMS rights or further server access.
The key can also sign forged Rights Account Certificates, allowing an attacker to impersonate an identity and request licenses for documents that identity may access.
The article says TPD exports are not recorded in the AD RMS logging database and have no default Windows event; IIS logs can capture the admin endpoint POST if SOAP bodies are monitored.
The SLC has no rotation mechanism that revokes access to previously protected files; rebuilding a deployment does not make documents sealed to an old key unreadable.
Recommended controls include restricting and auditing Service Group membership, protecting TPD export files, using TLS and Extended Protection for Authentication, and using an HSM-backed key.
The analysis concerns on-premises AD RMS; the article says cloud-only Azure Information Protection or Purview deployments are not affected, while HYOK deployments using on-premises AD RMS share the exposure.

Article Details

Attack Vectors: The demonstrated attack assumes credentials for an AD RMS Service Group member are already compromised. That membership permits a remote Trusted Publishing Domain export through the administrative SOAP surface, using an attacker-chosen export password to recover the deployment's SLC private key.
For software-keyed deployments, the article identifies the configuration database as another location containing encrypted SLC key material. The keyprotection administrative operation reveals the database connection string to a Service Group member.
Stored Trusted Publishing Domain exports contain password-wrapped SLC private key material. Reachable copies protected with weak or guessable passwords can be unwrapped offline; the article describes an unsalted, single-pass SHA-256 password derivation and a hardcoded IV.
The extracted SLC private key allows offline decryption and removal of protection from any available document sealed to that key, without server contact, user credentials, or document access rights.
The demonstrated certificate forgery replaces a genuine Rights Account Certificate's identity, public key, and validity, then signs it with the extracted SLC key. The live cluster accepts the forged identity and issues a use license when that identity has actual rights to the document.
The forged certificate does not supply authorization or group membership. A negative control using an identity without document rights was accepted as an identity but denied a use license.
The article identifies on-premises AD RMS-backed HYOK deployments as within scope, while stating that default Azure Information Protection and Microsoft Purview cloud configurations are not exposed through this administrative SOAP extraction path.
Defensive Notes: Treat AD RMS Service Group membership as highly privileged: use Protected Users, require privileged-access workstations, review membership quarterly, and alert on membership changes.
Treat Trusted Publishing Domain exports as private-key material. Use strong passwords, encrypted storage, access auditing, and restrictive share and NTFS permissions; avoid general-purpose shares.
Monitor IIS W3SVC logs for POST requests to /_wmcs/admin/ and parse SOAP bodies to identify ExportTrustedPublishingDomain. The article reports that these exports do not appear in the RMS application logging database and generate no Windows Event ID by default.
Use TLS to protect SOAP traffic and Extended Protection for Authentication to mitigate NTLM relay against the administrative surface.
Use HSM-backed key storage to prevent direct extraction of usable private-key material from the configuration database. The article's statements about TPD exports from HSM-backed deployments are inconsistent: an earlier section says export may work when administrators allow it, while remediation says exported material cannot be unwrapped without the hardware.
Rebuilding a deployment or introducing a new SLC does not revoke an extracted key's ability to decrypt existing documents protected by that key. The article identifies decommissioning and re-protecting sensitive documents as the way to address that historical exposure.
Changing an export password does not invalidate previously copied exports. Remove exposed files, tighten permissions, and assess whether the underlying key was already recovered.
The demonstrated impact is compromise of RMS-protected content and RMS identity trust, not acquisition of AD credentials or domain compromise.