Loading story…
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.
See affected versions and whether adversaries are exploiting it.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
1 reference tracked. Mallory keeps watching after this page renders.
Map 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
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.
Sep 10, 2026
Threat researchers and U.S. government defenders warned that attackers who steal an identity provider's token-signing private key can forge **SAML 2.0** assertions and authenticate as arbitrary users to cloud services that trust the compromised provider. The technique, known as **Golden SAML**, lets intruders bypass normal controls including MFA in some scenarios and obtain access to environments such as **AWS**, **Azure**, **Microsoft 365**, and **vSphere**. CyberArk showed the method can be used against **AD FS** federations, including exchanging forged assertions through AWS STS `AssumeRoleWithSAML` to obtain temporary AWS credentials, while noting the abuse stems from compromised trust infrastructure rather than a flaw in SAML itself. Mandiant and **CISA** later tied Golden SAML to broader post-compromise cloud intrusion activity, including operations by **UNC2452**, and said attackers often pivot from on-premises compromise into cloud tenants by stealing AD FS signing certificates, altering federated domains, abusing privileged Azure AD roles, or adding rogue credentials to applications and service principals. Defenders were urged to treat on-premises and cloud investigations as linked, rotate signing certificates and other secrets, revoke refresh tokens, remove cloud persistence, and harden monitoring around AD FS, federation settings, privileged accounts, and application permissions. Detection remains challenging because forged assertions can closely resemble legitimate federated logins; Splunk noted one analytic for suspicious AWS `AssumeRoleWithSAML` activity was ultimately removed because it no longer reliably identified the intended abuse.
Aug 15, 2026