When Entra ID trusts SAML assertions minted on-premises, cloud security depends on the integrity of the local AD FS environment.

Preface

Hybrid identity federates on-premises AD DS with Microsoft Entra ID via AD FS. That creates an explicit cryptographic trust. If the on-premises tier is compromised, the cloud environment falls with it. Entra cannot tell a legitimately issued assertion from a forged one if both carry a valid signature from the trusted certificate.

Problem

Nobelium (Midnight Blizzard) campaigns used two major post-compromise vectors:

  1. Golden SAML: Steal the AD FS token-signing private key and forge SAML assertions for any identity, with arbitrary group and role claims, bypassing password and MFA checks.
  2. MagicWeb: Replace legitimate AD FS security components and inject unauthorized claims during token generation without stealing the signing key.

AD FS servers often sit outside Tier 0 isolation, making them a bridge for on-premises-to-cloud lateral movement.

How the attack works in practice

Golden SAML is a post-compromise technique. The attacker first needs administrative access to the AD FS server or to Active Directory. The token-signing certificate's private key is protected by a key stored in Active Directory (the Distributed Key Manager, or DKM, container), so an attacker with sufficient AD rights can obtain both pieces.

With the key, the attacker can mint assertions offline, from any machine, for any federated user, including claims stating that MFA was performed. Entra validates the signature against the federation trust, accepts the claims, and issues tokens. No password is used, no on-premises authentication event is logged on AD FS, and resetting the user's password does nothing.

MagicWeb takes a different route: a malicious component loaded by the AD FS service alters the claims of legitimately issued tokens. Because the real server signs them, signature validation passes and the key never leaves the server.

A related persistence technique is adding or modifying a federated domain in Entra so that an attacker-controlled identity provider becomes trusted. That requires cloud privileges, but it produces the same outcome.

Why common approaches fail

  • MFA policies trust the federation. If Entra is configured to accept MFA performed by the federated IdP, a forged MFA claim satisfies Conditional Access.
  • AD FS is managed like a web server. It is often patched and administered by the same teams and tools as ordinary member servers.
  • Remediation targets accounts. Password resets and session revocation do not invalidate a stolen signing key.
  • Logs are split. AD FS logs stay on-premises, Entra logs are in the cloud, and the correlation that reveals forgery is rarely built.

Solution

Align with CISA Hybrid Identity guidance and NIST SP 800-207:

  1. Transition to cloud-primary authentication: Migrate from AD FS to PHS or PTA with Seamless SSO.
  2. Isolate remaining AD FS as Tier 0: Same boundaries as domain controllers, host firewalls, no direct internet, PAW-only admin access.
  3. Monitor trust changes: Alert on AD FS Event ID 307 (Federation Service configuration changed), together with Event ID 510, which carries the detail of the change, including trust and certificate modifications.

Design guidance

Remove the dependency where you can

Password hash synchronization (PHS) is the simplest and most resilient choice: authentication happens in Entra, there is no signing key on-premises to steal, and leaked-credential detection works. Pass-through authentication keeps password validation on-premises but still removes the SAML trust. Seamless SSO preserves the single sign-on experience for domain-joined devices. Applications that federate with AD FS directly can usually move to Entra as SAML or OIDC enterprise applications.

If AD FS must remain

  • Treat AD FS servers, their service account, the DKM container, and the Entra Connect server as Tier 0 assets.
  • Restrict read access to the DKM container to the AD FS service account and Tier 0 administrators.
  • Set the domain's federatedIdpMfaBehavior to rejectMfaByFederatedIdp so Entra performs MFA itself rather than trusting an MFA claim.
  • Monitor the integrity of AD FS binaries and loaded assemblies to catch MagicWeb-style tampering.
  • Publish AD FS through Web Application Proxy only; never expose the AD FS servers directly.

Migration steps

  1. Enable PHS in Entra Connect even if you keep federation for now; it provides a fallback and leaked-credential detection.
  2. Inventory relying party trusts and move applications from AD FS to Entra enterprise applications.
  3. Use staged rollout to move pilot groups to cloud authentication before converting the domain.
  4. Convert the domain to managed authentication (below), then monitor sign-in failures.
  5. Remove the relying party trust for Entra, decommission AD FS, and remove its service account and DKM container.

PowerShell: Migrate to Cloud-Managed Authentication

Review the current federation configuration, then convert the domain. Run this only after staged rollout testing, during a change window.

Connect-MgGraph -Scopes "Domain.ReadWrite.All"
Get-MgDomainFederationConfiguration -DomainId "contoso.com"
Update-MgDomain -DomainId "contoso.com" -AuthenticationType "Managed"

Monitoring and detection

In Entra, any change to domain federation is high severity. In Microsoft Sentinel:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Set federation settings on domain", "Set domain authentication",
    "Add unverified domain", "Verify domain")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, Actor, TargetResources, Result

Identity Protection raises a token issuer anomaly when SAML tokens look unusual:

AADUserRiskEvents
| where RiskEventType == "tokenIssuerAnomaly"
| project TimeGenerated, UserPrincipalName, RiskLevel, IpAddress

On-premises, collect AD FS auditing (including token issuance events 1200 and 1202 on AD FS 2016 and later) and look for federated sign-ins in Entra that have no matching AD FS issuance event, which is the signature of forged assertions. Also audit directory access to the DKM container (Event ID 4662 with object access auditing configured) by anything other than the AD FS service account.

Common mistakes

  • Keeping AD FS "temporarily" for years because one legacy application still depends on it.
  • Converting the domain but leaving AD FS servers running and trusted by other relying parties.
  • After a suspected compromise, rotating the token-signing certificate only once, or without first evicting the attacker from AD.
  • Overlooking Entra Connect, which holds equally sensitive credentials and deserves the same Tier 0 treatment.

Where to start

Enable password hash synchronization and the federation-change alert this week. Then set the federated MFA behavior so Entra no longer trusts external MFA claims, and plan a staged migration off AD FS. Until AD FS is gone, manage it, its keys, and Entra Connect exactly as you manage domain controllers.