The AD FS Master Key Behind Every Signed Token Was Readable Through a Loose ACL, and the July Patch Only Watches by Default

Where the AD FS Distributed Key Manager container carries an overly permissive ACL, an authenticated principal with less privilege than that object should ever grant can read the DKM key material — the symmetric master key that protects, but does not itself sign with, your token-signing certificate’s private key — then combine it with the encrypted token-signing certificate and configuration data from the AD FS configuration database to reconstruct the signing key and forge SAML tokens. That is CVE-2026-56155, an elevation-of-privilege bug reported by Microsoft’s DART incident-response team; Microsoft separately flags it as exploited in the wild before the July 14 patch. CVSS 7.8 (AV:L/PR:L — local, low-privilege), rated Important, which undersells the impact. CISA put it on the KEV catalog the same day and set a July 28 remediation due date for Federal Civilian Executive Branch agencies.

TL;DR

• Where the AD FS DKM container’s ACL is overly permissive, an authenticated principal with effective read access can pull DKM key material from the thumbnailPhoto attribute of a child contact object beneath the container, combine it with the encrypted configuration data to recover the token-signing private key, and forge Golden SAML tokens — a local, low-privilege (AV:L/PR:L) EoP, exploited in the wild and now on CISA’s KEV list.
• The July 14 patch ships in audit mode: Event ID 1132 flags an ACL that differs from Microsoft’s expected secure state, 1133 confirms a compliant one, and 1134 reports an evaluation error — but the update removes nothing until you enable remediation or October enforcement arrives (automatic remediation on Oct 13 is Server 2016+ only; Server 2012 / 2012 R2 get no automatic October remediation and need manual opt-in after a permission change). A patched farm whose ACL is already compliant isn’t exposed; one with a noncompliant ACL stays exposed until you set RemediateDkmAcl to 1 on any one patched server in the farm — export the current ACL yourself first, because the Event ID 1135 that records the prior ACL (SDDL, for rollback) is written only after remediation succeeds.
• The read is detected on the domain controller, not the AD FS host — Event ID 4662 fires only with Directory Service Access auditing and an effective SACL (applied to the key-bearing contact object or inherited from its parent container); match the thumbnailPhoto schema GUID (8d3bca50-1d7e-11d0-a081-00aa006c33ed) in the Properties field, handle ObjectName as either an object GUID or a distinguished name, then allowlist the AD FS service account SID and alert on any other reader.
• The forged token is minted offline and never touches AD FS, so that token leaves no matching 1200/1202 issuance event — correlating service-provider sign-ins against absent AD FS issuance is one useful detection (hard across skewed clocks, and it needs AD FS auditing already on via the Application Generated subcategory), alongside DKM-object 4662 auditing, LDAP/Defender alerts, and certificate-extraction signals.
• Scope caveat: shops fully migrated to Entra ID are outside the active Golden SAML path for that former federation — but uninstalling the AD FS servers doesn’t prove the DKM and certificate-sharing objects were removed from AD, so verify the directory cleanup. Forgotten legacy farms — the kind that linger under regulatory, legacy-app, or hybrid-identity constraints — still hold a key that can impersonate federated users across the apps trusting its signing certificate.

Here’s the part that will bite people: installing the patch does not, by itself, close the hole in July. It ships the ACL fix in audit mode. Install it and nothing on the container actually changes — Windows just logs whether the ACL matches the secure baseline (1132 vs 1133, or 1134 on error) and waits until October to enforce, unless you opt in early. So if your ACL is noncompliant, the same insecure-ACL weakness this CVE addresses is still sitting there on a freshly patched box — and the org that treats “patched” as “done,” without reading 1132, is exactly the org that gets caught. (Microsoft has confirmed exploitation and credited DART, but hasn’t publicly named the exact ACE, the compromised principal, or the full post-access sequence from the observed incidents — so read your own 1132 payload rather than assuming a specific attacker path. A farm already at the secure baseline — 1133 — isn’t exposed just because remediation mode is off.)

The key behind the key

AD FS signs the tokens every federated application trusts. The token-signing certificate’s private key is the crown jewel. Microsoft doesn’t leave that private key naked in AD — it’s protected by a symmetric master key, and that key lives in a DKM container in Active Directory, stored as the value of the thumbnailPhoto attribute on a child contact object beneath the container (not on the container object itself — the distinction matters when you write the SACL and the 4662 filter). That container commonly sits under CN=ADFS,CN=Microsoft,CN=Program Data, but the farm-specific group/container component varies — pull the authoritative distinguished name from the AD FS configuration rather than hard-coding the parent path. The DKM key doesn’t sign anything on its own: reach it, then use it to decrypt the token-signing certificate’s private key out of the AD FS configuration data, and an attacker can forge tokens that any relying party trusting that signing certificate may accept — subject to each application’s audience, claims, authorization, and token-validation rules, but in practice that reaches most of the federation.

This is the well-worn Golden SAML path. It’s how UNC2452 forged tokens after compromising AD FS in the SolarWinds intrusion back in 2020; the tradecraft is documented down to the exact LDAP query in Azure’s SimuLand lab. What CVE-2026-56155 changes is the entry requirement. The old assumption was that you needed AD FS service-account context or Domain Admin to get at the DKM material. The finding here is that overly permissive ACLs on the container let principals who should never have been in scope read it. So the barrier drops from “you already control the AD FS host” to “you control any principal the loose ACL wrongly lets read the object” — still a local, authenticated foothold, per Microsoft’s AV:L/PR:L scoring, but a far lower one. Read access to the DKM key still isn’t the whole chain: public tooling like Mandiant’s ADFSpoof needs both the DKM key and the encrypted token-signing PFX plus configuration from the AD FS database, and Microsoft hasn’t described how the observed attackers obtained that second input. So the loose ACL materially lowers the barrier — it doesn’t prove every DKM-readable principal can independently reconstruct the signing key. That’s the whole game — a Golden SAML forge is minted offline, so it produces no AD FS issuance event and direct attribution is hard, though it still leaves indirect traces (relying-party and Entra sign-in telemetry, anomalous claims and assertion lifetimes, assertion reuse — MITRE’s forged-SAML technique catalogs the downstream signals). The DKM read is the last high-fidelity event tied to the key itself that you get to catch.

Why installing the July patch alone doesn’t close the exposure

Microsoft’s own advisory spells out a two-phase rollout, and if you skim it you’ll misread the timeline.

July 2026 — audit only. The update adds detection logic that inspects the DKM container ACL and writes Event ID 1132 (Warning) to the AD FS Admin log when the ACL sits outside the approved principal set, 1133 (Information) when it matches the secure baseline, and 1134 (Error) when the check itself fails. No ACE is removed. The container is exactly as accessible as it was on July 13.

October 2026 — enforcement. Automatic remediation kicks in by default on Windows Server 2016 and later. The hardened ACL keeps Full Control for Domain Admins, Enterprise Admins, and SYSTEM, grants the AD FS service account a scoped Read/Write/Create-Child/Write-Owner/Delete-Tree set, disables inheritance, and strips every other explicit Allow ACE. Server 2012 and 2012 R2 — still running AD FS in more shops than anyone likes to admit — get nothing automatic; they can still remediate manually, but only after you first grant the AD FS service account WriteOwner and WriteDacl on the DKM object (the update ships PowerShell to do it), and they never receive October’s automatic transition.

If you want the fix now, patch every federation server first, then set the RemediateDkmAcl registry value to 1 on any one server in the farm — the DKM object is shared in Active Directory, so a single server’s remediation hardens the ACL for the whole farm (you don’t set it everywhere). Before you do, export the current container ACL yourself and stash it somewhere, because if a custom claims-provider trust or a third-party MFA adapter was relying on an explicit ACE you’re about to delete, you want the rollback in hand. Don’t count on Event ID 1135 as that snapshot: the update writes 1135 (the prior ACL in SDDL) only after remediation succeeds, so it’s your after-the-fact rollback copy, not a pre-change one — grab your own first, then retain 1135 as the confirmed record. That’s the realistic failure mode here — not the enforcement breaking AD FS in the common case, but the one environment with a bolted-on integration that quietly depended on the loose ACL. Read Event 1132’s payload before you flip enforcement and you’ll know which bucket you’re in.

Don’t wait for October to look, though. Patch, then go read the ACL events on every AD FS box this week. If 1132 is firing, the container ACL doesn’t match Microsoft’s expected secure state — that’s the fact 1132 asserts, not automatic exploitability (1133 means you’re already at the secure baseline and there’s nothing to do). Inspect the unexpected ACEs and effective permissions right away: the extra access might land on a broad low-privileged group, a narrowly scoped admin identity, or a stale service account. If an untrusted or broadly populated principal had read access, treat DKM-key exposure as a credible compromise scenario for however long the ACL has been wrong — which, on a forest that’s been carrying AD FS since 2016, could be years.

And draw the line between “noncompliant ACL” and “actually read.” If your investigation establishes — or can’t reasonably exclude — that an untrusted principal read the DKM material and could reach the encrypted signing-certificate data, tightening the ACL is not the end of the response. It stops the next read; it does nothing to a signing key already copied. Treat the token-signing certificate as compromised and rotate it: Microsoft’s emergency AD FS certificate rotation procedure revokes the old certificate immediately and expels it from the AD FS and Microsoft Entra trust — a normal single rollover leaves the previous certificate trusted (which is exactly why the emergency path, and the common “rotate twice” guidance, exist). Rotate the token-signing and token-decryption certificates, push the new trust to every federation partner, remove the old certificate from AD FS and Entra, and revoke the refresh tokens and sessions minted against the old key. ACL remediation prevents another read; it doesn’t invalidate a key an attacker already holds.

Where the detection actually lives

The read you care about does not happen on the AD FS server. It happens against Active Directory, so the event fires on a domain controller, and if your monitoring stops at the AD FS hosts you will never see it. It’s an easy gap to leave open, and a consequential one — DC-side object auditing is exactly where this class of read gets caught or missed.

The signal is Event ID 4662 (Directory Service Access) on the DC, generated when something reads the DKM contact object’s thumbnailPhoto attribute. Two catches make it annoying in practice. First, 4662 doesn’t fire at all unless a SACL actually audits that read — Audit Directory Service Access in policy plus an audit ACE that covers the key-bearing DKM contact object, whether applied to the object directly or inherited from its parent container, requesting GenericRead/Success. Scope it tightly to the DKM objects. If you turn on directory-access auditing broadly across a busy DC you’ll bury the SIEM; Microsoft classes this subcategory as high-volume and recommends scoping SACLs to specific important objects, so scope the audit ACE to the DKM objects and baseline expected volume in your own environment rather than assuming a number. Second, per the Threat Hunter Playbook, the event logs the attribute as its schema GUID, not its name — thumbnailPhoto shows up as 8d3bca50-1d7e-11d0-a081-00aa006c33ed in the Properties field, and Windows will not translate it for you. And normalize ObjectName handling: some telemetry (as SimuLand observed) surfaces it as the object’s GUID, while Microsoft’s generic 4662 documentation describes a distinguished name — a production analytic should tolerate either representation rather than key on one. Build your Splunk search (or the Elastic equivalent, where the property lands in winlog.event_data.Properties and the parsing is messier) to match the raw GUID string, and enrich it to a human name in a lookup so the analyst who catches the alert at 0300 doesn’t have to reverse a schema GUID.

Volume, once scoped to the object, is typically low — but baseline it in your own environment before you set thresholds rather than assuming a number. The legitimate reads are mostly the AD FS service account pulling the master key at service start and during certificate rollover — so your first real tuning pass is: allowlist the AD FS service account SID and alert on everything else touching that GUID. ObjectName is the DKM contact, SubjectUserSid is anything other than the service account, and you have a lead. Keep the service-account reads visible in a lower-severity lane anyway, because a sudden off-schedule read by the service account is its own tell that someone’s running in its context.

On the endpoint side, Defender for Endpoint ships an ADFS private key extraction attempt alert — Netwrix and the Hunters writeup both cover its behavior. Don’t assume it only fires when thumbnailPhoto appears in the LDAP filter: Microsoft’s SimuLand testing documents this MDE alert triggering both for the explicit filter and for indirect access to the key-bearing contact object without naming the attribute — the narrower filter-only behavior is closer to the Defender for Identity LDAP-reconnaissance alert. Still, don’t lean on any one product alone. Endpoint and identity-product coverage varies by sensor placement, product version, protocol, and collection path, so the DC-side 4662 stays your backstop for a direct read — the signal that survives an attacker who knows the EDR rule exists.

One important limit on that backstop: an object-scoped 4662 catches the LDAP read the loose ACL enables, but it does not catch an attacker who already holds directory-replication rights and pulls the DKM contact object over DRS/DCSync. Microsoft’s SimuLand shows the replication path retrieving the key without tripping the direct object-access audit on the container. That’s a higher-privilege acquisition route, but it’s a real bypass of the object SACL — so monitor replication/DCSync separately: the tell is a 4662 carrying the DS-Replication-Get-Changes extended-right GUIDs from a principal that isn’t a domain controller (join it to 4624 on LogonId for the source workstation and IP).

The forged token leaves no fingerprint on AD FS

Once the key is out, the forgery is offline. The attacker mints a SAML token on their own hardware and presents it straight to a service provider. AD FS never processes that token, so it emits no Event 1200 (token issued) or Event 1202 (fresh credentials validated) for it, and presenting an offline-forged SAML token doesn’t itself require a 4769 Kerberos service ticket on the DC. The detection is inferential: a successful federated sign-in with no corresponding AD FS issuance transaction is a forged-token candidate. Splunk’s Golden SAML analysis walks the correlation. Build it around the event sequence each authentication method actually produces — SSO-cookie, Windows Integrated Auth, certificate, and device flows don’t all emit the same 1200/1202 pair — rather than requiring 1200, 1202, and 4769 in every legitimate case. And a missing 4769 isn’t a clean Golden SAML discriminator on its own: the attacker’s preceding activity — the initial domain logon, the LDAP read of the DKM object, lateral movement, or a hit on some other Kerberos-backed resource — can still throw 4769s and other Kerberos telemetry. Absent AD FS issuance is the tell for the forged token, not for the whole intrusion.

That’s a real detection and also a genuinely hard one. It requires you to be ingesting the service provider’s sign-in logs — Entra ID sign-ins, the SaaS app’s own auth logs — and joining them against AD FS issuance events across systems whose clocks don’t agree. Time skew between the DC, the AD FS farm, and a cloud SP’s log timestamps turns a clean join into a fuzzy window match, and you’ll widen the correlation interval to avoid dropping real pairs, which softens the signal. Get your AD FS auditing on first — and it’s a separate configuration from the DC-side 4662 track, so don’t conflate the two. Event 4662 rides on Audit Directory Service Access (the DS Access subcategory) plus the object SACL, on the domain controller. The AD FS issuance events are a different pipeline entirely: grant the AD FS service account the Generate security audits user right, enable the Application Generated audit subcategory (auditpol /set /subcategory:"Application Generated" /success:enable /failure:enable), turn on Success and Failure audits in the AD FS Management console’s Events tab, and set an AD FS audit level that emits 1200/1202 — so those events are actually in the Security log and forwarded to be the negative half of the correlation. If they aren’t being collected, the whole “login with no issuance” logic silently returns nothing and looks like all-clear. One version caveat: the streamlined 1200/1202 pipeline is an auditing enhancement introduced with AD FS on Windows Server 2016, so it’s a 2016-and-later assumption. On Server 2012 / 2012 R2 (AD FS 3.0) the audit trail is older and more fragmented — issuance activity may be absent or spread across many events — so build those farms’ detection from their available legacy events plus service-provider authentication telemetry rather than expecting a clean 1200/1202.

Also keep the certificate-theft signals lit, because not every operator goes the DKM route. Event 1007 from the certificate lifecycle log flags a cert export off the AD FS box, and PowerShell logging can expose Export-PfxCertificate or a scripted certutil -exportPFX — Event 4104 is the script-block record, 4103 is module logging (they’re not the same thing), and Sygnia’s hunt guidance leans on these. But a certutil.exe -exportPFX launched directly from cmd or another process won’t necessarily land in PowerShell logs at all — catch that through process-creation telemetry (Security Event 4688, Sysmon Event 1, or equivalent EDR). Cheaper to collect than the cross-system SAML correlation, and it catches the smash-and-grab variant.

Control mapping

One scoping note that changes the whole answer: if you finished migrating to Entra ID and your applications no longer trust AD FS, you’re outside the active Golden SAML path for that former federation. But don’t assume “we retired the servers” means the directory is clean — uninstalling the AD FS role doesn’t by itself delete the DKM and certificate-sharing objects from Active Directory, and a stale, unowned key object left behind is exactly the kind of forgotten liability worth confirming was explicitly removed. Plenty of shops haven’t migrated at all, and the AD FS farm is often the forgotten pet server that still federates a handful of legacy SaaS apps nobody wants to re-plumb. Organizations carrying regulatory, sovereignty, legacy-application, or hybrid-identity constraints are among the more likely to keep one running — but treat that as a prompt to go check for an active or forgotten farm and its DKM container, not a claim about any one sector. Where a farm is still live, that box holds a key that can impersonate users across the apps trusting its signing certificate. Patch it, read Event 1132, and if you can take the change, set RemediateDkmAcl to 1 rather than trusting that October arrives before an operator does.

Sources

• Microsoft’s July 2026 Patch Tuesday addresses 569 CVEs (CVE-2026-56155, CVE-2026-56164) (Tenable)
• CVE-2026-56155: AD FS DKM container ACL hardening (Microsoft Support)
• Known Exploited Vulnerabilities Catalog (CISA)
• Active Directory Federation Services (AD FS) Distributed Key Manager (DKM) Keys (Threat Hunter Playbook)
• Export AD FS DKM Master Key via LDAP Queries (Azure SimuLand)
• Export AD FS DKM Master Key via Directory Replication Services / DCSync (Azure SimuLand)
• Emergency rotation of the AD FS certificates (Microsoft Learn)
• Golden SAML attack: Forged access to hybrid environments (Netwrix)
• AD FS Threat Hunting, Part 2: Golden SAML (Hunters)
• A Golden SAML Journey: SolarWinds Continued (Splunk)
• Detection and Hunting of Golden SAML Attack (Sygnia)
• Troubleshoot AD FS with events and logging — enabling security auditing (Microsoft Learn)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.