The New Ouroboros Technique and How It Fits in dMSA’s Security Model

What Happened

Microsoft recently introduced Delegated Managed Service Accounts (dMSAs) to make service accounts more secure by changing how they authenticate. However, researchers have detailed a technique called Ouroboros that exploits how these new accounts link to older, legacy accounts. Organizations using Microsoft Active Directory and dMSAs are potentially affected. If an attacker gains control over a dMSA, they can use Ouroboros to inherit the high-level permissions of the old account it replaced, allowing them to maintain hidden access to the network. IT teams should review the permissions assigned to dMSA objects and closely monitor the authorization paths that link them to older accounts.

Key Takeaways

• dMSAs shift from LDAP-based password retrieval to a Kerberos-based credential issuance flow, improving security over traditional gMSAs.
• The Ouroboros technique allows attackers with sufficient dMSA permissions to inherit the privileges of the superseded legacy account.
• LDAP reads of the msDS-ManagedPassword attribute for dMSAs are explicitly blocked by the ntdsai.dll module on Domain Controllers.
• Monitoring dMSA security requires analyzing internal authorization paths and successor status, not just password retrieval events.

Affected Systems

• Microsoft Active Directory
• Windows Server (Domain Controllers)

Attack Chain

An attacker first gains sufficient permissions over a Delegated Managed Service Account (dMSA) object in Active Directory. Using the Ouroboros technique, the attacker manipulates the dMSA's successor logic to link it to a highly privileged superseded legacy account. The attacker then authenticates via the Kerberos-based dMSA flow, receiving a KERB-DMSA-KEY-PACKAGE attached to their TGT. This allows the attacker to operate as the dMSA while inheriting the effective authorization context and privileges of the legacy account, establishing persistence and escalating privileges.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article does not provide specific detection rules but highlights native Windows event logs related to dMSA password fetches that can be used for monitoring.

Detection Engineering Assessment

EDR Visibility: Low — The technique exploits Active Directory logic and Kerberos ticket issuance at the Domain Controller level, which is typically monitored via Windows Event Logs rather than endpoint EDR telemetry. Network Visibility: Low — The Kerberos key package (KERB-DMSA-KEY-PACKAGE) is encrypted within the TGT, making network-level inspection difficult. Detection Difficulty: Hard — Distinguishing legitimate dMSA authentication from Ouroboros abuse requires correlating dMSA usage with the authorization context of superseded accounts. Native fetch events do not confirm if the requester was ultimately authorized.

Required Log Sources

• Windows Security Event Logs (Domain Controller)

Hunting Hypotheses

Hypothesis	Telemetry	ATT&CK Stage	FP Risk
Look for anomalous dMSA password fetch events originating from unexpected sources or associated with the ANONYMOUS LOGON SID (S-1-5-7).	Windows Security Event Logs (Domain Controller)	Credential Access	Medium
Monitor for unexpected modifications to dMSA object permissions or attributes that define successor status to legacy accounts.	Windows Security Event Logs (Domain Controller)	Privilege Escalation	Low

Control Gaps

• LDAP monitoring (bypassed by the Kerberos flow)
• Standard gMSA monitoring rules (which do not account for dMSA successor logic)

Key Behavioral Indicators

• dMSA-specific fetch events ('The KDC successfully fetched the password of a delegated managed service account')
• Modifications to dMSA permissions or successor links

False Positive Assessment

• High

Recommendations

Immediate Mitigation

• Review permissions and ACLs on all Delegated Managed Service Account (dMSA) objects to ensure least privilege.

Infrastructure Hardening

• Monitor and restrict the internal authorization paths that define successor status for dMSAs.
• Ensure Credential Guard is enabled on hosts utilizing dMSAs to protect TGTs and Kerberos material.

User Protection

• Limit the number of administrators who can modify dMSA configurations and superseded account links.

Security Awareness

• Educate identity and access management (IAM) teams on the security model differences between gMSAs and dMSAs, specifically regarding successor inheritance.

MITRE ATT&CK Mapping

• T1098 - Account Manipulation
• T1078.002 - Valid Accounts: Domain Accounts
• T1550.003 - Use Alternate Authentication Material: Pass the Ticket

Additional IOCs

• File Paths:
  • ntdsai.dll - Domain Controller module that enforces LDAP read protections for dMSA attributes and contains internal password-related paths.
• Other:
  • S-1-5-7 - ANONYMOUS LOGON SID observed in older dMSA password retrieval events.
  • msDS-ManagedPassword - Active Directory attribute used for managed passwords; LDAP reads are blocked for dMSAs.
  • msDS-GroupMSAMembership - Active Directory attribute tied to the dMSA Kerberos authentication flow.
  • KERB-DMSA-KEY-PACKAGE - Kerberos key package attached to the Ticket Granting Ticket (TGT) issued for the dMSA.