Listen to this Post
Introduction:
The recent disclosure of the BadSuccessor technique highlights a critical lesson in cybersecurity: patching a specific exploit does not necessarily eliminate the underlying threat vector. While Microsoft addressed the initial privilege escalation method documented by researcher Yuval Gordon, the core vulnerability related to Dynamic Master Subordinate Account (dMSA) abuse remains a potent attack avenue for adversaries. This ongoing risk underscores the necessity for defenders to shift from a purely patch-focused mindset to one centered on continuous monitoring and hardening of identity and access management systems.
Learning Objectives:
- Understand the fundamental security risks associated with Dynamic Master Subordinate Account (dMSA) objects in Active Directory.
- Learn to utilize new offensive security tools like BadTakeover (BOF) and SharpSuccessor to test environmental resilience.
- Implement defensive monitoring and detection strategies for dMSA abuse attempts.
You Should Know:
1. Enumerating Vulnerable dMSA Objects
The first step for an attacker is to identify dMSA accounts that are susceptible to takeover. PowerView, a part of the PowerSploit toolkit, is commonly used for this reconnaissance.
Get-DomainUser -Identity "msdns" -Properties samaccountname,msds-hostserviceaccount,msds-groupmsamembership
Step-by-step guide:
This PowerShell command, executed via PowerView, queries the domain for user objects that have a `samaccountname` starting with “msdns”. The `-Properties` parameter specifies additional attributes to display, focusing on those critical to the dMSA structure: `msds-hostserviceaccount` and msds-groupmsamembership. The output will list potential dMSA accounts and their associated management information, allowing an attacker to pinpoint targets that may have weak permissions or inherited rights that can be abused for privilege escalation.
2. Exploiting with BadTakeover (Beacon Object File)
For operators using Cobalt Strike, the BadTakeover Beacon Object File (BOF) provides a lean, in-memory method to execute the attack.
badtakeover $target.dMSA.samaccountname
Step-by-step guide:
After compiling the target dMSA’s samaccountname, the attacker simply runs the `badtakeover` command within their Beacon console. This BOF is executed directly in the beacon’s memory, making it very stealthy. It works by manipulating the service principal names (SPNs) and Kerberos delegation settings of the vulnerable dMSA object, effectively allowing the attacker to impersonate the account and request service tickets (TGS) for privileged services.
3. Leveraging SharpSuccessor for .NET Operations
SharpSuccessor is the .NET counterpart to BadTakeover, useful for operators in a non-Cobalt Strike context or for those who prefer a managed code payload.
SharpSuccessor.exe --dmsa "target_dMSA" --command "whoami /groups"
Step-by-step guide:
This command-line invocation of SharpSuccessor targets a specific dMSA account (--dmsa). The `–command` argument specifies a command to execute in the context of the compromised identity. The tool automates the process of taking control of the dMSA’s group membership and executing the specified command, demonstrating immediate privilege escalation. It’s particularly effective for executing payloads or enumerating further access from the newly acquired security context.
4. Forging Silver Tickets with the Compromised dMSA
Once control over a dMSA associated with a machine account is achieved, an attacker can forge Kerberos Silver Tickets, granting them persistent access to specific services.
mimikatz kerberos::golden /sid:S-1-5-21-... /domain:corp.local /target:SQLSVC.corp.local /service:MSSQLSvc /rc4:dMSA_NTLM_hash /user:FAKEUSER /ptt
Step-by-step guide:
Using Mimikatz, the attacker uses the `kerberos::golden` command to create a Silver Ticket. The `/sid` is the domain SID, `/domain` is the FQDN, and `/target` is the server hosting the service. The `/service` specifies the service type (e.g., MSSQLSvc), and the critical `/rc4` parameter uses the NTLM hash of the compromised dMSA account. The `/ptt` flag injects the resulting ticket directly into the current session’s Kerberos ticket cache, granting immediate access to the specified service without needing further authentication.
5. Defensive Monitoring with Windows Security Event IDs
Proactive detection is key to mitigating this threat. Security teams should alert on specific Event IDs that signal dMSA object manipulation.
Sigma Rule for dMSA SPN Modification title: Suspicious dMSA ServicePrincipalName Modification description: Detects potential abuse of a dMSA account by monitoring for SPN changes. logsource: product: windows service: security detection: selection: EventID: 4738 TargetUserName: "msdns" condition: selection
Step-by-step guide:
This Sigma rule provides a template for a detection alert. It triggers on Windows Security Event ID 4738 (A user account was changed) where the target username matches the dMSA naming pattern (“msdns”). Security teams can implement this rule in their SIEM (e.g., Splunk, Elasticsearch) to generate alerts whenever an attacker attempts to modify the SPNs of a dMSA account as part of the BadSuccessor or similar techniques. Correlating this with other events like 4769 (A Kerberos service ticket was requested) for the same account can increase confidence in a true positive.
6. Hardening dMSA Permissions with Active Directory PowerShell
Prevention involves tightening the permissions on dMSA objects to prevent unauthorized users from modifying critical attributes.
Get-ADUser "target_dMSA" -Properties | Set-ADObject -Replace @{msDS-AllowedToActOnBehalfOfOtherIdentity=$null}
Step-by-step guide:
This PowerShell command, run from a domain administrator context, removes the `msDS-AllowedToActOnBehalfOfOtherIdentity` attribute from a specified dMSA account. This attribute, if set inappropriately, can allow other accounts to delegate to the dMSA, a key part of the exploitation chain. Regularly auditing and removing this attribute—or more broadly, implementing and enforcing least-privilege access models for all dMSA objects—significantly reduces the attack surface.
7. Leveraging BloodHound for Path of Least Resistance
Defenders should use attack path management tools to identify if any dMSA accounts provide a privileged pathway to sensitive targets.
MATCH p=(d:Computer)-[r:MemberOf|AdminTo|AllExtendedRights|AddMember1..5]->(g:Group {name:"DOMAIN [email protected]"}) RETURN p
Step-by-step guide:
This Cypher query for BloodHound searches for any path from a Computer node (which could be hosting a dMSA) to the high-value “DOMAIN ADMINS” group. The relationships searched include MemberOf, AdminTo, AllExtendedRights, and AddMember, traversing up to 5 steps (1..5). By running such queries, blue teams can proactively discover if a compromisable dMSA account has any inbound privileges that could be chained into a full domain compromise, allowing them to sever these dangerous links before they are exploited.
What Undercode Say:
- Patching is Not a Panacea: The BadSuccessor case is a textbook example of treating a symptom rather than the disease. The underlying architectural permission issues with dMSAs mean that as long as these accounts exist with excessive rights, new techniques will be discovered to abuse them.
- The Tooling Ecosystem is Accelerating Attack Evolution: The rapid development and release of operational tools like BadTakeover BOF and updated SharpSuccessor demonstrate how quickly academic research is weaponized. This shortens the window for defenders to implement detections after a patch is released, emphasizing the need for proactive hunting based on an understanding of the core technique, not just a specific CVE.
The primary analysis suggests that the security community’s reliance on vendor patches creates a false sense of resolution for complex identity-based attacks. The persistence of the dMSA abuse vector post-patch indicates a deeper, systemic issue in how privileged access is managed and monitored within modern enterprises. Defenders must invest in capabilities that allow them to understand and monitor the fundamental security primitives of their identity fabric, rather than waiting for a specific exploit to be documented and patched.
Prediction:
The failure to fully remediate the dMSA abuse vector will lead to a surge in identity-centric attacks that bypass traditional vulnerability management programs. As offensive security researchers continue to explore the complex, often poorly documented permission inheritance chains in Active Directory and Azure AD, we predict a wave of “technique successors” that leverage similar underlying flaws in managed service and system identities. This will force a paradigm shift in enterprise security, moving from CVSS-based prioritization towards continuous attack path modeling and identity threat detection and response (ITDR) as a core security control.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Specterops The – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
