From d52f45f33f1f274980c4209343413543de91849e Mon Sep 17 00:00:00 2001 From: chryzsh Date: Mon, 21 Sep 2026 09:34:16 +0200 Subject: [PATCH 1/8] Add AD FS server and configuration database server as Tier Zero Addresses #4 Microsoft's AD DS tier model lists AD FS by name under Tier 0, the identity control plane, the same list that already justifies the existing Entra Connect entry. Admin on the AD FS server lets an attacker decrypt the token-signing key (from process memory, or via the AD FS service account's access to the Distributed Key Manager key in AD plus the encrypted key in the configuration database) and mint Golden SAML tokens for any user against any relying party AD FS trusts, including Entra ID Global Administrator when federated. The backing configuration database is scoped IT DEPENDS rather than YES by default: most farms run on WID, local to the AD FS server and readable only by its service account, so the database server asset doesn't exist in most deployments. It only appears once a farm is large enough to need a full SQL Server backend, and even then DB access alone can't forge tokens without the DKM key from AD, but it exposes the encrypted key blob to a separate, often broader admin population. --- TierZeroTable.json | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index e8c1b4d..22ceeea 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -878,5 +878,37 @@ "AdminSDHolder Protected": "NO", "Episode": "Community contribution", "References": "https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vsphere-active-directory-integration-risks\r\nhttps://knowledge.broadcom.com/external/article/314324/removal-of-integrated-windows-authentica.html\r\nhttps://knowledge.broadcom.com/external/article/433065" - } + }, + { + "Asset": "AD FS Server", + "Category": "Computer host", + "Platform": "Active Directory", + "Identification": "Not applicable - Not represented as an object. Identify by locating hosts running the Active Directory Federation Services role.", + "Description": "AD FS issues SAML/WS-Fed/OAuth tokens so users can authenticate to federated relying parties, commonly including Microsoft Entra ID when an org federates instead of using password hash sync. The token-signing private key is decrypted at runtime in the AD FS process and, in the default configuration (WID), the configuration database that stores it encrypted is otherwise readable only in the AD FS service account's own context.", + "Tier Zero Default Risk": "YES - Takeover", + "Tier Zero Config Risk": "N/A - Compromise by default", + "Tier Zero": "YES", + "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, the identity control plane, alongside domain controllers and Entra Connect. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts, including Entra ID Global Administrator when Entra ID is federated through it. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. This is equivalent to Domain Admin over everything AD FS federates, not a direct DCSync path against the AD domain.", + "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role.", + "Microsoft PAS Role": "NO", + "AdminSDHolder Protected": "N/A", + "Episode": "Community contribution", + "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml" + }, + { + "Asset": "AD FS Configuration Database Server (SQL Server)", + "Category": "Computer host", + "Platform": "Active Directory", + "Identification": "Not applicable - Not represented as an object. Identify by locating the SQL Server instance hosting an AD FS farm's configuration database. Only present when a farm uses a full SQL Server backend instead of the default Windows Internal Database (WID).", + "Description": "Larger AD FS farms (over 100 relying party trusts or 30 farm nodes) use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID. The database stores the AD FS token-signing key encrypted with a key from the Distributed Key Manager container in Active Directory.", + "Tier Zero Default Risk": "NO", + "Tier Zero Config Risk": "YES - Takeover", + "Tier Zero": "IT DEPENDS", + "Rationale": "Most AD FS farms run on WID, which is local to the AD FS server and readable only in the AD FS service account's own context, so this asset does not exist in most deployments. Where a farm uses a full SQL Server backend instead, sysadmin or db_owner access exposes the encrypted token-signing key blob to the SQL Server's own admin population, typically broader than the AD FS host's local admins. That access alone cannot forge tokens, since the Distributed Key Manager key from AD is also required to decrypt the blob, but it is one half of the Golden SAML chain described in the AD FS Server entry and should be scoped and monitored the same way. The server is Tier Zero whenever it is in use.", + "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference AD FS farm configuration against the SQL Server instance hosting its configuration database.", + "Microsoft PAS Role": "NO", + "AdminSDHolder Protected": "N/A", + "Episode": "Community contribution", + "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-ad-fs-configuration-database\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-fs/design/federation-server-farm-using-sql-server\r\nhttps://github.com/mandiant/ADFSDump" + } ] \ No newline at end of file From a449122d2842453285c0028a3a7ebb5ee0fbe50d Mon Sep 17 00:00:00 2001 From: chryzsh Date: Mon, 21 Sep 2026 09:50:06 +0200 Subject: [PATCH 2/8] Describe AD FS SQL Server backend as optional at any farm size CodeRabbit correctly flagged that SQL Server isn't only used once a farm exceeds WID's limits. Microsoft's docs also list it as an available choice for smaller farms wanting high availability, SAML artifact resolution, or token replay detection, none of which WID supports. Reworded so the entry doesn't imply small SQL-backed farms should be excluded from inventory. --- TierZeroTable.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index 22ceeea..87137d9 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -899,8 +899,8 @@ "Asset": "AD FS Configuration Database Server (SQL Server)", "Category": "Computer host", "Platform": "Active Directory", - "Identification": "Not applicable - Not represented as an object. Identify by locating the SQL Server instance hosting an AD FS farm's configuration database. Only present when a farm uses a full SQL Server backend instead of the default Windows Internal Database (WID).", - "Description": "Larger AD FS farms (over 100 relying party trusts or 30 farm nodes) use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID. The database stores the AD FS token-signing key encrypted with a key from the Distributed Key Manager container in Active Directory.", + "Identification": "Not applicable - Not represented as an object. Identify by locating the SQL Server instance hosting an AD FS farm's configuration database. Only present when a farm uses a SQL Server backend instead of the default Windows Internal Database (WID); optional at any farm size, but required once a farm exceeds WID's limits (100 relying party trusts or 30 nodes).", + "Description": "AD FS farms can use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID, for high availability, SAML artifact resolution, or token replay detection, none of which WID supports. Farms over 100 relying party trusts or 30 nodes require SQL Server, since WID cannot support them at that scale. The database stores the AD FS token-signing key encrypted with a key from the Distributed Key Manager container in Active Directory.", "Tier Zero Default Risk": "NO", "Tier Zero Config Risk": "YES - Takeover", "Tier Zero": "IT DEPENDS", From 95029ef258a239d7d494ba4ec01d1701a730e1fd Mon Sep 17 00:00:00 2001 From: chryzsh Date: Tue, 22 Sep 2026 16:11:35 +0200 Subject: [PATCH 3/8] Scope AD FS signing-key claims to managed certificates CodeRabbit correctly flagged that the WID/DKM decryption path only applies to AD FS's default, automatically generated token-signing certificate. A custom certificate keeps its private key in the local certificate store or an HSM instead, which doesn't follow that path. Qualified both entries accordingly. --- TierZeroTable.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index 3a4191e..10e0b96 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -932,7 +932,7 @@ "Category": "Computer host", "Platform": "Active Directory", "Identification": "Not applicable - Not represented as an object. Identify by locating hosts running the Active Directory Federation Services role.", - "Description": "AD FS issues SAML/WS-Fed/OAuth tokens so users can authenticate to federated relying parties, commonly including Microsoft Entra ID when an org federates instead of using password hash sync. The token-signing private key is decrypted at runtime in the AD FS process and, in the default configuration (WID), the configuration database that stores it encrypted is otherwise readable only in the AD FS service account's own context.", + "Description": "AD FS issues SAML/WS-Fed/OAuth tokens so users can authenticate to federated relying parties, commonly including Microsoft Entra ID when an org federates instead of using password hash sync. For the automatically generated, AD FS-managed token-signing certificate, the private key is decrypted at runtime in the AD FS process and, in the default configuration (WID), the configuration database that stores it encrypted is otherwise readable only in the AD FS service account's own context. A custom certificate instead stores its private key through the certificate store or an HSM, which does not follow this path.", "Tier Zero Default Risk": "YES - Takeover", "Tier Zero Config Risk": "N/A - Compromise by default", "Tier Zero": "YES", @@ -948,7 +948,7 @@ "Category": "Computer host", "Platform": "Active Directory", "Identification": "Not applicable - Not represented as an object. Identify by locating the SQL Server instance hosting an AD FS farm's configuration database. Only present when a farm uses a SQL Server backend instead of the default Windows Internal Database (WID); optional at any farm size, but required once a farm exceeds WID's limits (100 relying party trusts or 30 nodes).", - "Description": "AD FS farms can use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID, for high availability, SAML artifact resolution, or token replay detection, none of which WID supports. Farms over 100 relying party trusts or 30 nodes require SQL Server, since WID cannot support them at that scale. The database stores the AD FS token-signing key encrypted with a key from the Distributed Key Manager container in Active Directory.", + "Description": "AD FS farms can use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID, for high availability, SAML artifact resolution, or token replay detection, none of which WID supports. Farms over 100 relying party trusts or 30 nodes require SQL Server, since WID cannot support them at that scale. For the automatically generated, AD FS-managed certificate, the database stores its token-signing private key encrypted with a key from the Distributed Key Manager container in Active Directory; a custom certificate's private key lives in the certificate store or an HSM instead.", "Tier Zero Default Risk": "NO", "Tier Zero Config Risk": "YES - Takeover", "Tier Zero": "IT DEPENDS", From 51249f7b5f2b6a03b1ff88b5db4cbf95a63ab841 Mon Sep 17 00:00:00 2001 From: chryzsh Date: Fri, 25 Sep 2026 15:27:50 +0200 Subject: [PATCH 4/8] Scope AD FS Server to IT DEPENDS, add Key Admins path JonasBK pointed out AD FS's Tier Zero reach depends on what trusts it, unlike a domain controller or Entra Connect, so a config with no Entra federation and no privileged relying party wouldn't reach Tier Zero. Changed to IT DEPENDS with three conditions: Entra ID federated through it, a relying party trust granting Tier Zero-equivalent access, or the AD FS service account being a member of Key Admins/Enterprise Key Admins, which on-premises WHFB Key Trust deployments require and which gives a Shadow Credentials path independent of federation scope. --- TierZeroTable.json | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index 10e0b96..8eca7bd 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -933,15 +933,15 @@ "Platform": "Active Directory", "Identification": "Not applicable - Not represented as an object. Identify by locating hosts running the Active Directory Federation Services role.", "Description": "AD FS issues SAML/WS-Fed/OAuth tokens so users can authenticate to federated relying parties, commonly including Microsoft Entra ID when an org federates instead of using password hash sync. For the automatically generated, AD FS-managed token-signing certificate, the private key is decrypted at runtime in the AD FS process and, in the default configuration (WID), the configuration database that stores it encrypted is otherwise readable only in the AD FS service account's own context. A custom certificate instead stores its private key through the certificate store or an HSM, which does not follow this path.", - "Tier Zero Default Risk": "YES - Takeover", - "Tier Zero Config Risk": "N/A - Compromise by default", - "Tier Zero": "YES", - "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, the identity control plane, alongside domain controllers and Entra Connect. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts, including Entra ID Global Administrator when Entra ID is federated through it. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. This is equivalent to Domain Admin over everything AD FS federates, not a direct DCSync path against the AD domain.", - "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role.", + "Tier Zero Default Risk": "NO", + "Tier Zero Config Risk": "YES - Takeover", + "Tier Zero": "IT DEPENDS", + "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, but its reach depends on what trusts it, unlike a domain controller or Entra Connect, which are security dependencies for Tier Zero no matter how they're configured. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts. This is Tier Zero when Entra ID is federated through it, when any relying party trust grants access equivalent to a Tier Zero principal, or when the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require, since that alone gives a Shadow Credentials path (write access to msDS-KeyCredentialLink) to any user in the domain regardless of what AD FS otherwise federates. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. Absent all three, AD FS is not a Tier Zero security dependency.", + "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.", "Microsoft PAS Role": "NO", "AdminSDHolder Protected": "N/A", "Episode": "Community contribution", - "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml" + "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml\r\nhttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs#add-the-ad-fs-service-account-to-the-key-admins-group\r\nhttps://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab" }, { "Asset": "AD FS Configuration Database Server (SQL Server)", From 562d71a75b05faed4512396a1b5cd5a34d11fb54 Mon Sep 17 00:00:00 2001 From: chryzsh Date: Fri, 25 Sep 2026 15:57:04 +0200 Subject: [PATCH 5/8] Make AD FS Server rationale's DC comparison concrete Say plainly what depends on what: relying parties and Entra federation for AD FS, versus a domain controller holding every credential in the domain regardless of configuration. --- TierZeroTable.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index 8eca7bd..e80b4e3 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -936,7 +936,7 @@ "Tier Zero Default Risk": "NO", "Tier Zero Config Risk": "YES - Takeover", "Tier Zero": "IT DEPENDS", - "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, but its reach depends on what trusts it, unlike a domain controller or Entra Connect, which are security dependencies for Tier Zero no matter how they're configured. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts. This is Tier Zero when Entra ID is federated through it, when any relying party trust grants access equivalent to a Tier Zero principal, or when the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require, since that alone gives a Shadow Credentials path (write access to msDS-KeyCredentialLink) to any user in the domain regardless of what AD FS otherwise federates. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. Absent all three, AD FS is not a Tier Zero security dependency.", + "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, but its reach depends on which relying parties trust it and whether Entra ID is federated through it, unlike a domain controller, which holds every credential in the domain no matter how it's configured. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts. This is Tier Zero when Entra ID is federated through it, when any relying party trust grants access equivalent to a Tier Zero principal, or when the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require, since that alone gives a Shadow Credentials path (write access to msDS-KeyCredentialLink) to any user in the domain regardless of what AD FS otherwise federates. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. Absent all three, AD FS is not a Tier Zero security dependency.", "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.", "Microsoft PAS Role": "NO", "AdminSDHolder Protected": "N/A", From d939df69e0a3e1a7357f778e65c8ffd3e9108712 Mon Sep 17 00:00:00 2001 From: chryzsh Date: Fri, 25 Sep 2026 16:00:52 +0200 Subject: [PATCH 6/8] Replace "absent all three" with plain wording State the condition directly instead of the formal legalistic phrasing. --- TierZeroTable.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index e80b4e3..81881ed 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -936,7 +936,7 @@ "Tier Zero Default Risk": "NO", "Tier Zero Config Risk": "YES - Takeover", "Tier Zero": "IT DEPENDS", - "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, but its reach depends on which relying parties trust it and whether Entra ID is federated through it, unlike a domain controller, which holds every credential in the domain no matter how it's configured. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts. This is Tier Zero when Entra ID is federated through it, when any relying party trust grants access equivalent to a Tier Zero principal, or when the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require, since that alone gives a Shadow Credentials path (write access to msDS-KeyCredentialLink) to any user in the domain regardless of what AD FS otherwise federates. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. Absent all three, AD FS is not a Tier Zero security dependency.", + "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, but its reach depends on which relying parties trust it and whether Entra ID is federated through it, unlike a domain controller, which holds every credential in the domain no matter how it's configured. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts. This is Tier Zero when Entra ID is federated through it, when any relying party trust grants access equivalent to a Tier Zero principal, or when the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require, since that alone gives a Shadow Credentials path (write access to msDS-KeyCredentialLink) to any user in the domain regardless of what AD FS otherwise federates. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. If none of these three conditions apply, AD FS is not a Tier Zero security dependency.", "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.", "Microsoft PAS Role": "NO", "AdminSDHolder Protected": "N/A", From 13e042ff89d680b4b451cbbf9198fc5b810c1f0c Mon Sep 17 00:00:00 2001 From: chryzsh Date: Fri, 25 Sep 2026 16:03:11 +0200 Subject: [PATCH 7/8] Rewrite AD FS Server rationale in plain, direct language Drop the "but its reach depends on" staging and state the three Tier Zero conditions and the domain controller comparison as plain facts, split into short paragraphs by topic (classification, Golden SAML mechanism, Key Admins path). --- TierZeroTable.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index 81881ed..66d60ff 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -936,7 +936,7 @@ "Tier Zero Default Risk": "NO", "Tier Zero Config Risk": "YES - Takeover", "Tier Zero": "IT DEPENDS", - "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0, but its reach depends on which relying parties trust it and whether Entra ID is federated through it, unlike a domain controller, which holds every credential in the domain no matter how it's configured. An attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database, then mint a Golden SAML token impersonating any user with any claims against every relying party AD FS trusts. This is Tier Zero when Entra ID is federated through it, when any relying party trust grants access equivalent to a Tier Zero principal, or when the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require, since that alone gives a Shadow Credentials path (write access to msDS-KeyCredentialLink) to any user in the domain regardless of what AD FS otherwise federates. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs. If none of these three conditions apply, AD FS is not a Tier Zero security dependency.", + "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0. A domain controller holds every credential in the domain no matter how you configure it, so it is always Tier Zero. An AD FS server is Tier Zero only if Entra ID is federated through it, if a relying party trust grants access equivalent to a Tier Zero principal, or if the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require.\r\n\r\nAn attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database. With that key, the attacker can mint a Golden SAML token and impersonate any user with any claims against every relying party AD FS trusts. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs.\r\n\r\nMembership in Key Admins gives a second, independent path: write access to msDS-KeyCredentialLink lets you add credentials to any user in the domain, a Shadow Credentials attack, regardless of what AD FS otherwise federates. If none of the three conditions above apply, AD FS is not a Tier Zero security dependency.", "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.", "Microsoft PAS Role": "NO", "AdminSDHolder Protected": "N/A", From a6e0de020a2c716cda5556a9c1c272fe106ff61f Mon Sep 17 00:00:00 2001 From: chryzsh Date: Fri, 25 Sep 2026 17:58:36 +0200 Subject: [PATCH 8/8] Justify the Key Admins condition by protected-group status CodeRabbit correctly noted the Shadow Credentials write only reaches unprotected users, since AdminSDHolder-protected accounts have inheritance disabled and their ACLs reset hourly by SDProp. Key Admins and Enterprise Key Admins are themselves on Microsoft's protected accounts and groups list, the same list every other AdminSDHolder- protected group in this table is on, so that's the actual basis for treating AD FS service account membership in them as Tier Zero, not what the group's ACE can reach. Swapped the shadow-credentials reference for Microsoft's protected accounts and groups appendix. --- TierZeroTable.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/TierZeroTable.json b/TierZeroTable.json index 66d60ff..438b513 100644 --- a/TierZeroTable.json +++ b/TierZeroTable.json @@ -936,12 +936,12 @@ "Tier Zero Default Risk": "NO", "Tier Zero Config Risk": "YES - Takeover", "Tier Zero": "IT DEPENDS", - "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0. A domain controller holds every credential in the domain no matter how you configure it, so it is always Tier Zero. An AD FS server is Tier Zero only if Entra ID is federated through it, if a relying party trust grants access equivalent to a Tier Zero principal, or if the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require.\r\n\r\nAn attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database. With that key, the attacker can mint a Golden SAML token and impersonate any user with any claims against every relying party AD FS trusts. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs.\r\n\r\nMembership in Key Admins gives a second, independent path: write access to msDS-KeyCredentialLink lets you add credentials to any user in the domain, a Shadow Credentials attack, regardless of what AD FS otherwise federates. If none of the three conditions above apply, AD FS is not a Tier Zero security dependency.", + "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0. A domain controller holds every credential in the domain no matter how you configure it, so it is always Tier Zero. An AD FS server is Tier Zero only if Entra ID is federated through it, if a relying party trust grants access equivalent to a Tier Zero principal, or if the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require.\r\n\r\nAn attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database. With that key, the attacker can mint a Golden SAML token and impersonate any user with any claims against every relying party AD FS trusts. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs.\r\n\r\nKey Admins and Enterprise Key Admins are themselves on Microsoft's protected accounts and groups list, the same list Domain Admins, Account Operators, and every other AdminSDHolder-protected group in this table is on. Membership in Key Admins gives a second, independent Tier Zero condition for that same reason, not because of what it can reach: it is a protected group, and control over the AD FS service account means control over a member of one. If none of the three conditions above apply, AD FS is not a Tier Zero security dependency.", "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.", "Microsoft PAS Role": "NO", "AdminSDHolder Protected": "N/A", "Episode": "Community contribution", - "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml\r\nhttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs#add-the-ad-fs-service-account-to-the-key-admins-group\r\nhttps://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab" + "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml\r\nhttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs#add-the-ad-fs-service-account-to-the-key-admins-group\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory" }, { "Asset": "AD FS Configuration Database Server (SQL Server)",