A 1172-byte file called slc.bin lands on a Windows desktop, and a domain user with no rights to anything opens a board minutes document that was sealed for two named executives. No server contact. No credentials. No permission prompt. The protection is simply not there any more.
That file is the root key of the entire service. It cannot be changed.
Andrew Schwartz, a principal detection engineer at Huntress, published the demonstration on September 10 in the second part of a two-part study of Active Directory Rights Management Services, the on-premises Microsoft product that stops a protected Word document or email being opened, printed or forwarded by anyone outside its rights list. Part one covered how any domain user can find an RMS deployment and pick out which files it protects. Part two is where the key comes out.
The key with no replacement
Every AD RMS deployment has one Server Licensor Certificate, and its private half is the thing everything else hangs from. Each protected document gets a fresh content key sealed to the SLC public key, and the server unseals that content key with the SLC private key every time somebody opens the file. The protected file itself never touches an RMS server, which is the part that matters: the key, not any server-held copy of your data, is the whole game.
Schwartz sets it beside two better-known cluster roots. KRBTGT signs Kerberos tickets, and resetting it twice retires every forged Golden Ticket, because the KDC simply stops trusting the old signature. The DPAPI domain backup key has no supported rotation either, though Microsoft's guidance there is at least explicit about the consequence. The SLC sits in a worse position than both. Issuing a new one changes only what the cluster protects from that moment on. There is no revocation that reaches backwards, so every document sealed to the old key stays readable by the old key, wherever a copy of that document still exists: an archived share, a mailbox export, a laptop decommissioned three years ago.
The certificate's dates make the point in the least subtle way available. Every AD RMS server enrolls as a leaf of a fixed Microsoft certificate chain shipped inside the product, inheriting that enrollment certificate's validity window verbatim: December 5, 2002 to March 3, 2258. Schwartz did not calculate those dates. They sit in the raw XrML of the licensor chain carried inside the publishing license of every document the cluster has protected, and they read back identically from the server endpoint.
What Microsoft's own migration guide asks for
The extraction Schwartz demonstrates uses a documented feature. AD RMS exposes a Trusted Publishing Domain export over its administrative SOAP surface, built so that a second deployment can take over issuing and opening licenses for the first. A Trusted User Domain shares public certificates; a Trusted Publishing Domain shares the private key. That is the entire point of it, and it is why the export doubles as the extraction path.
Microsoft's published guidance for migrating from AD RMS to Azure Information Protection makes administrators run exactly that export, and is candid about what the file holds: the trusted publishing domains "include the Server Licensor Certificate (SLC) keys to decrypt previously protected files", and "however you store these files, use security best practices to protect them because this data includes your private key".
Read the same page for what it asks beyond that one export and the exposure widens. Microsoft instructs administrators to export all trusted publishing domains, not only the active one, and gives the reason: an organization that moved from Cryptographic Mode 1 to Mode 2 holds an archived key that is still the only thing which will open its older content. A migrated estate therefore does not end up with one password-wrapped copy of an unrotatable root key. It ends up with one per publishing domain it ever ran, and the page's worked example for moving them is a USB thumb drive carried to an internet-connected workstation. That instruction has stood since 2020.
None of that is a defect in the migration document. It is the accurate consequence of a key nobody can rotate: carry the old keys forward or lose the old documents. It does mean the files worth hunting for on a file share are probably plural.
A gate with a single lock on it
The prerequisite is real and should not be glossed over. The export is gated on membership of the AD RMS Service Group, an administrative role over the service in its own right, and Schwartz takes that compromise as given rather than showing how to reach it. This is not a domain takeover, and he says so plainly: it is not a DCSync equivalent. It is total and permanent compromise of everything one service protects, for every user who ever used it, which is a narrower claim and a different one.
One check decides whether the paths in the post apply at all. A Service Group member can ask the service whether the SLC private key is held in software rather than in a hardware security module, and the same call hands back the configuration database connection string on its way out, naming the SQL server and database that the alternative extraction path needs. An HSM-backed key never leaves the hardware in usable form, so the routes that read key material directly do not work against one.
Almost nothing writes the export down
This is the part defenders should read twice. The AD RMS logging database records six request types, all of them on the client pipeline: licensor certificate retrieval, certification and pre-certification, both template distribution variants, and group expansion. The administrative SOAP surface where the export lives is not among them. No Windows event ID fires on a Trusted Publishing Domain export by default. What does exist is an IIS log entry for the POST to the admin path, carrying the authenticated user, source address and user agent. The operation name sits inside the SOAP body rather than in the URL, so an organization that does not parse those bodies sees an administrative request and nothing more.
The only durable artifact, in other words, is the exported key file on the attacker's machine.
Minting a user the cluster believes
Decryption is not the whole payoff. Every certificate in the AD RMS trust hierarchy, including the Rights Account Certificates that identify users, is an XrML document signed by the SLC. Holding the private key means producing those signatures at will, so an attacker can mint an identity the server treats as its own and ask it for a license. Schwartz implemented the signing natively and touched Microsoft's own server library exactly once, as a proof step confirming his from-scratch signatures match Microsoft's byte for byte.
Here is what the research does and does not establish. It is a lab demonstration, not a report of anyone doing this in the wild, and Huntress names no victim, campaign or threat actor. Every step starts from an account that already holds a privileged RMS role. What it establishes is a property of the product rather than an event: the consequences of that one role being compromised do not end when the account is disabled, the server is rebuilt, or the deployment is retired, because the material taken from it has no expiry and no replacement.
Lock the export path, then go looking for the files
There is no patch here, because there is no bug in the ordinary sense. Treat AD RMS Service Group membership as a tier-zero role and audit who holds it, on the same footing as the directory groups that domain controller takeover research keeps returning to. Parse IIS logs for administrative SOAP posts instead of merely storing them. Then find every trusted publishing domain export the organization has ever produced and treat each as private key material, not a migration leftover, with the reflex that should meet any product caught leaving secrets in a file on disk: off general-purpose shares, permissions cut to the accounts that genuinely need them. Where the export password was weak or reused, assume the file is readable: Schwartz notes the default wrapping derives its AES key from a single unsalted SHA-256 pass over that password, with an initialization vector identical on every AD RMS install. Where an HSM is an option, it removes the direct key-read paths outright.
The client-side half of this surface, stripping protection as somebody already allowed to read a document, was settled a decade ago in the DisARMS work by Martin Grothe, Christian Mainka, Paul Roesler and Joerg Schwenk, and Schwartz folded their code into the same tool rather than re-covering it. What part two adds is the server side, and with it a harder question than any single finding. A rights management deployment is usually sold internally as the control that keeps the most sensitive documents readable only by the right people. This research does not break that promise for the documents protected today. It points out that the promise was only ever as durable as one key nobody can change, and that the list of people who can export that key is a much shorter document than most organizations expect.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.