Security researchers have unveiled two distinct but equally alarming identity-based attack paths that strike at the heart of enterprise Windows environments: a design flaw in Windows Server 2025’s delegated Managed Service Accounts (dMSAs) enabling forest-wide credential compromise, and a chained abuse of first-party Microsoft applications in Entra ID that can escalate privileges to Global Administrator—sometimes while multi-factor authentication appears satisfied. Together, these findings expose dangerous assumptions about “modernized” identity security across on-premises Active Directory and the cloud.

Golden dMSA: When Service Account Innovation Becomes a Backdoor

Windows Server 2025 introduced delegated Managed Service Accounts as a security leap forward. Unlike traditional service accounts with static passwords susceptible to Kerberoasting, dMSAs bind authentication to authorized machines, theoretically making stolen credentials useless on any other system. But Semperis security researcher Adi Malyanker discovered that the cryptographic foundation underpinning dMSAs—and their group MSA (gMSA) predecessors—contains a predictable structure that reduces brute-force password guessing to just 1,024 attempts.

The attack, dubbed Golden dMSA, hinges on obtaining the Key Distribution Services (KDS) root key, a forest-level secret that acts as the master key for generating all gMSA and dMSA passwords. The KDS root key is stored in the configuration naming context and access is restricted to Domain Admins, Enterprise Admins, and SYSTEM. However, once an attacker compromises a single domain controller with those privileges, they can extract the key and use it offline to derive passwords for every managed service account across the entire forest.

Why is this so trivial? Malyanker’s analysis of the ManagedPasswordId attribute—the metadata needed to compute a service account’s password—revealed that the time-based L1Index and L2Index fields are each limited to values between 0 and 31, yielding only 1,024 possible combinations. Crucially, the L0Index field is ignored during password derivation. An attacker can simply enumerate all dMSA accounts (using SID brute-forcing or LDAP tricks), construct a wordlist of 1,024 candidate ManagedPasswordId vectors, and generate the corresponding NTLM or AES256 hashes for each KDS root key pairing. Testing those hashes via Pass-the-Hash or Overpass-the-Hash attacks yields valid credentials.

The impact is forest-wide. A single extracted KDS root key—which has no expiration date—lets an adversary persistently access every dMSA- and gMSA-protected service across all domains, bypassing protections like Credential Guard. Microsoft acknowledged the research but responded that “if you have the secrets used to derive the key, you can authenticate as that user,” noting that these features were never designed to withstand a domain controller compromise. Semperis rates the risk as moderate due to the high barrier of entry, but warns that the impact is severe once that barrier is crossed.

Compounding the problem: by default, read access to the KDS root key is not logged. Defenders must manually add a System Access Control List (SACL) on the msKds-RootKeyData attribute to detect unauthorized access, a step many organizations neglect.

Beyond Golden dMSA: The BadSuccessor Lateral Movement Technique

Separate research from Akamai and others has shown that weak Organizational Unit (OU) access control lists combined with the msDS-ManagedAccountPrecededByLink attribute can let low-privileged users create or modify dMSAs to inherit high-privilege contexts, including Domain Admin, without touching group membership. This “BadSuccessor” technique adds another layer of risk for organizations that have not tightly locked down dMSA creation and OU permissions.

Entra ID: From Application Administrator to Global Admin via First-Party Apps

On the cloud side, Datadog Security Labs documented a privilege escalation chain that starts with the Application Administrator role in Microsoft Entra ID (formerly Azure AD). Researchers found that the Office 365 Exchange Online service principal, a first-party Microsoft app, holds the Domain.ReadWrite.All Graph permission—a highly impactful scope that allows managing domain configurations, including federation settings.

An attacker with Application Administrator rights (or equivalent permissions to manage app credentials) can hijack this service principal by adding a new certificate or secret. They then use that credential to add a malicious federated domain under their control. By forging SAML tokens that include a fabricated MFA claim, they can log in as any synced hybrid user—including a Global Administrator—without actually satisfying MFA requirements. The technique effectively creates a golden ticket for the cloud, granting persistent, high-privilege access that appears legitimate in sign-in logs.

Datadog reported the issue to Microsoft, which stated that this is “expected behavior” given the combination of a powerful role and app-only scopes. The responsibility falls on identity governance: tightly controlling which service principals hold high-impact permissions, who can add credentials to them, and how federation is managed.

This echoes earlier Semperis research on “UnOAuthorized,” where certain Microsoft application service principals could perform privileged actions not clearly reflected in their advertised scopes. Microsoft subsequently tightened some controls, but the underlying risk remains: first-party apps with app-only Graph permissions can act as hidden escalation paths if left unchecked.

The Bigger Picture: Why These Threats Demand a Unified Response

These two attack paths illustrate a fundamental truth: hybrid identity ties on-premises Active Directory and Entra ID into a single security fabric. A foothold in AD via Golden dMSA can pivot to Entra-connected services, while a federated domain compromise in Entra ID can project power back onto on-premises resources through synced identities. “Privilege by design” is the new battleground—roles like Application Administrator and high-impact app-only scopes behave as standing keys to the kingdom if not governed with Tier-0 discipline.

Detection still lags behind. As noted, KDS root key reads aren’t logged natively. Federation changes can blend with legitimate business collaborations. SAML token forgeries can satisfy MFA in sign-in logs, making investigations harder. The onus is on administrators to proactively close these gaps.

Practical Hardening Steps for Active Directory and Windows Server 2025

Protect Tier-0 Cryptographic Material
- Treat the KDS root key with the same paranoia as the KRBTGT account. Restrict access to Domain Admins/Enterprise Admins only, store it on hardened domain controllers, and add SACLs to audit read attempts.
- Back up KDS objects securely and practice restoring them to validate incident response playbooks.

Restrict dMSA and gMSA Creation and Changes
- Review and remove unnecessary Write or Control permissions on OUs that allow creating or modifying dMSAs. Favor change-controlled windows for service account lifecycle work.
- Monitor AD event IDs 5137 (object create) and 5136 (attribute changes) for dMSA-related operations, along with authentication anomalies for service accounts.

Assume Persistence After a Domain Controller Breach
- If a DC compromise is suspected, plan for KDS root key regeneration and a staged service account password roll coordinated with application owners. Do not rely solely on Credential Guard.

Practical Hardening Steps for Microsoft Entra ID

Re-baseline Privileged Roles and App-Only Permissions
- Elevate Application Administrator and Cloud Application Administrator to Tier-0 status. Enforce Privileged Identity Management (PIM), Just-In-Time elevation, and phishing-resistant MFA. Control who can add credentials to service principals.
- Inventory service principals with high-impact Graph scopes (Domain.ReadWrite.All, RoleManagement.ReadWrite.Directory) and decouple these permissions from broadly managed apps.

Detect Federation and Service Principal Abuse
- Alert on new federated domains, federation configuration changes, and certificate updates on domains. These are precursors to SAML token forging.
- Monitor Core Directory logs for “Add service principal credentials” and “Certificates and secrets management” events; investigate any anomalous app-only token usage.

Reduce Cross-Tenant Lateral Movement
- If cross-tenant sync is in use, enforce least privilege on sync apps, continuously validate inbound and outbound policies, and disable unnecessary connections to shrink the blast radius.

A 10-Step Checklist to Start This Week

  1. Classify Application Administrator, Cloud Application Administrator, and Domain Name Administrator as Tier-0; enforce PIM.
  2. Inventory all service principals with app-only scopes; remove or constrain Domain.ReadWrite.All and similar high-impact permissions.
  3. Require approvals and change control for adding credentials to any service principal; alert on new app credentials.
  4. Audit and prune OU ACLs that allow dMSA creation or modification outside Tier-0.
  5. Add SACLs to KDS root key objects; continuously monitor for read and replicate accesses.
  6. Baseline and alert on new federated domains, certificate changes, and federation configuration updates.
  7. Centralize logging for AD event IDs 5136/5137 and watch for TGT/TGS anomalies tied to dMSA/gMSA accounts.
  8. Restrict who can grant app-only Graph scopes; require least-privilege app registrations and consent workflows.
  9. Validate cross-tenant sync policies and disable unnecessary connections.
  10. Rehearse DC-level compromise response, including KDS regeneration and service account secret rotation.

What’s Signal, What’s Noise

The Golden dMSA flaw is real and high-impact but gated by a Tier-0 compromise. That barrier should not be a comfort; it simply means that once an attacker is on a domain controller, forest-wide service account exposure must be assumed. The Entra ID escalation is less a software bug than an identity governance failure. Microsoft’s “expected behavior” stance shifts the burden to administrators to lock down app-only scopes, federation, and credential management.

These attacks are not esoteric edge cases. They leverage intended functionality twisted by weak governance. The fix isn’t a single patch—it’s rigorous Tier-0 hygiene, least privilege for apps and roles, and proactive detection for the subtle signals these techniques leave behind. Organizations that treat identity as the new security perimeter will be best positioned to defend against the next wave of attacks that inevitably target the intersection of on-premises and cloud trust.