Loading story…
Huntress detailed how on-premises Microsoft Active Directory Rights Management Services (AD RMS) relies on the cluster’s Server Licensor Certificate (SLC) private key to protect encrypted documents. Standard domain users can identify AD RMS clusters and protected files, retrieve public certificate data, and enumerate rights-policy templates, while the administrative SOAP interface is limited to members of the local AD RMS Service Group.
A member of that Service Group can potentially extract a software-protected SLC private key from the AD RMS configuration database and decrypt protected content offline. Because SLC keys cannot practically be rotated for documents already protected by a deployment, compromise may expose all data encrypted under that key even after wider Active Directory remediation; the risk principally affects on-premises AD RMS, rather than cloud-held Azure Information Protection or Microsoft Purview tenant keys unless organizations retain those keys on-premises.
Get the actors, campaigns, and ATT&CK mapping behind it.
2 events from the most recent confirmed update back to the earliest known activity.
Huntress demonstrated that compromise of a software-keyed on-premises AD RMS Service Group member can enable extraction of the Server Licensor Certificate private key, allowing offline decryption of protected documents without RMS access, rights, or victim credentials. The research also showed that the stolen key can sign forged Rights Account Certificates that impersonate authorized identities and obtain use licenses from the live RMS service.
Huntress documented that authenticated domain users can discover on-premises AD RMS clusters, obtain public certificate data, enumerate rights-policy templates, and identify protected files. The research reported that compromise of the deployment Server Licensor Certificate private key could permit offline decryption of content protected under that key, with prior content remaining tied to the old key if a new key is generated.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
2 references tracked. Mallory keeps watching after this page renders.
huntress.com
Open sourcehuntress.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Incident response findings and large-scale Active Directory assessments show that attackers can often escalate from a low-privileged account to **full domain compromise** by chaining common identity weaknesses. Microsoft reported repeated cases of "total identity compromise" tied to excessive privilege, weak password policies, poor credential hygiene, insecure delegation, ACL abuse, Group Policy abuse, trust relationship weaknesses, and exposure of other Tier 0 assets. Separate analysis of 250 PingCastle reports found the same patterns at scale, including delegable administrator accounts, Kerberoast exposure, weak Kerberos encryption, dangerous Group Policy assignments, and exploitable Print Spooler configurations on domain controllers. The assessments also highlighted persistent weaknesses in **Active Directory Certificate Services (AD CS)** and service account management. Research on **Certified Pre-Owned** and AD CS hardening showed that certificate template and enrollment misconfigurations can let attackers impersonate privileged users and gain durable access, while DFIR reporting found widespread service accounts with non-expiring passwords, excessive privileges, and Kerberoastable administrator accounts. Microsoft guidance points defenders toward continuous AD auditing with tools such as Defender for Identity, BloodHound, and PingCastle, along with privilege reduction, stronger authentication, hardened delegation and trust settings, and tighter governance of managed and legacy service accounts to close common escalation paths.
Aug 1, 2026
Google Cloud's Mandiant reported that active **Active Directory Federation Services (ADFS)** token-signing private keys may be recoverable from machine-scoped cryptographic storage protected by **Machine DPAPI**, even when traditional extraction methods fail. The write-up describes environments where ADFS stores the active signing key in the system RSA key store rather than in a user-scoped DPAPI context tied to the ADFS service account, allowing attackers or responders with sufficient **SYSTEM-level** access to recover the key material without directly accessing **LSASS** memory or the live ADFS process. The report says this issue becomes especially relevant in environments with configuration drift, such as when `AutoCertificateRollover` is disabled and administrators rotate certificates manually. In those cases, the ADFS **WID** database can retain stale certificate metadata while the service continues using a newer certificate at the operating-system level, causing extraction methods that rely only on the WID database and **DKM** material to recover outdated certificates that produce rejected federation assertions. Mandiant said defenders should account for machine-level key storage when validating ADFS signing key recovery and investigating federation compromise.
Jul 7, 2026
Huntress disclosed **"dMSA Ouroboros,"** a technique that abuses delegated Managed Service Accounts (dMSAs) in fully patched **Windows Server 2025** to create self-sustaining persistence and repeatedly extract credentials. The method chains delegated `CreateChild` and `WriteProperty` permissions with object ownership, **Shadow Credentials** stored in `msDS-KeyCredentialLink`, and self-referential `msDS-GroupMSAMembership` entries so a rogue dMSA can authenticate and authorize itself to recover the superseded account's **NT hash**. The researchers said the approach builds on Akamai's **BadSuccessor** work and differs from Semperis's **Golden dMSA** research by focusing on post-creation abuse paths. According to the report, the attack survives password rotation, can persist even after the original attacker account is deleted, and may prevent **Domain Admins** from fully remediating the compromise unless the malicious dMSA object itself is removed. Huntress said Microsoft's patch for **`CVE-2025-53779`** did not address this abuse path and that Microsoft classified the issue as a persistence mechanism rather than an elevation-of-privilege flaw, declining to issue a further fix. The firm urged defenders to audit delegated `CreateChild` rights, monitor dMSA creation by non-admin users, and hunt for suspicious `msDS-KeyCredentialLink` values and self-SID entries in `msDS-GroupMSAMembership` on dMSA objects.
Jun 29, 2026