Executive Summary

BadSuccessor is a critical attack vector that emerged following the release of Windows Server 2025. Under certain conditions, this server version enables users to leverage delegated Managed Service Accounts (dMSAs) to elevate privileges within Active Directory environments running Windows Server 2025. At the time of writing this article, no patch exists for this issue.

By analyzing the core mechanics of this technique and offering practical detection strategies, we help security professionals and system administrators understand dMSAs and how attackers can misuse them to elevate privileges. We also provide advice on how to implement effective detection and mitigation strategies.

Palo Alto Networks customers are better protected against the BadSuccessor technique through Cortex XDR and XSIAM. These products already have the ability to detect the attack. Performing auditing on the delegated Managed Service Account is a required action that we describe in this article.

The Unit 42 Managed Detection and Response Service can assist with threat detection, investigation and response/remediation.

The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Related Unit 42 Topics	Microsoft, Active Directory

BadSuccessor Overview

BadSuccessor is a novel technique that enables a threat actor with sufficient privileges to compromise an Active Directory (AD) domain by misusing controlled delegated Managed Service Account (dMSA) objects.

Originally detailed in research published by Akamai, this technique demonstrates how modifying a small set of attributes on a dMSA object under the attacker’s control can lead to privilege escalation within the environment. Publicly available tools have already been released to automate various steps involved in leveraging this technique, potentially lowering the barrier for its adoption.

We provide a comprehensive breakdown of the attack methodology, along with guidance on detection strategies and potential mitigations.

Understanding dMSAs

The Evolution of MSAs

Windows has two basic types of accounts:

• Machine accounts
• User accounts

In an AD environment, machine accounts represent hosts (servers or clients) that belong to a domain, while user accounts represent the users who log into and access the environment.

Service accounts are user accounts or machine accounts that provide a security context for services running on a Windows Server. In other words, Windows services authenticate with service accounts. Windows relies on service accounts to run its various features.

With the release of Windows Server 2008 R2, Microsoft introduced Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs) to simplify and enhance AD service account management.

MSAs and gMSAs are specialized service accounts designed to securely run services within an AD environment without the need for manual password handling. An MSA account is linked to a single computer, allowing only that machine to retrieve and use the account. Conversely, a gMSA account can be used by multiple computers, like clusters or server farms.

A key benefit of MSAs and gMSAs is that AD automatically manages their passwords. This involves generating strong, unique passwords and rotating them regularly, eliminating the need for human administrators to manage credentials. For example, when a service needs to access a domain resource, the Local Security Authority Subsystem Service (LSASS) uses the machine account to securely request the MSA or gMSA’s password. In this way, the password is handled in the AD and not directly by a user or an administrator.

Delegated Managed Service Accounts

The dMSA is a new account type introduced in Windows Server 2025 to facilitate the migration of traditional service accounts to Managed Service Accounts. This process is as follows:

• An administrator creates a new dMSA object, which is intended to supersede the existing service account.
• The administrator then initiates the migration, which sets the dMSA msDS-ManagedAccountPrecededByLink attribute to reference the original service account.
• When the original service authenticates as the original service account, it triggers a Lightweight Directory Access Protocol (LDAP) modify request. This adds the machine account to the list of principals that are allowed to retrieve the dMSA password.
• In the final step, the administrator completes the migration, which disables the original service account. The service continues to operate seamlessly using the dMSA.
• Once a dMSA supersedes an existing account, any attempts to authenticate as that existing account using its password will be blocked. These authentication requests are redirected to the Local Security Authority (LSA) to authenticate using the dMSA. By then, the request has been granted all permissions that the original account had in the Active Directory, by the Key Distribution Center (KDC).

While dMSAs are intended to prevent credential harvesting, dMSAs also create a privilege escalation path that attackers can exploit through the BadSuccessor technique.

dMSA Migration Flow

The migration process of a traditional service account to a dMSA is triggered by an administrator using the Start-ADServiceAccountMigration PowerShell AD module command. The administrator passes the following values to the command:

• The Distinguished Name (DN) of the intended dMSA account
• The DN of the superseded account

As the migration continues, it changes several attributes of the normal service account as it transitions to a dSMA account, including:

• The msDS-DelegatedMSAState attribute is set to 1 in the newly created dMSA.

This attribute indicates the current state of the dMSA. Microsoft's documentation shows that 1 means the account migration has begun.

• The dMSA’s msDS-ManagedAccountPrecededByLink attribute is set to reference the superseded account.

Next, the administrator initiates the Complete-ADServiceAccountMigration command. This command disables the superseded account, and it changes the msDS-DelegatedMSAState and msDS-SupersededServiceAccountState attribute values of the dMSA object to 2, indicating that the migration is complete.

Following this migration, any service that relies on the superseded account will use the dMSA instead, which now has all the permissions that the superseded account had.

Technical Analysis: Bad Successor Technique and Tools

This section demonstrates how attackers can use dMSAs to impersonate any domain user account, including the domain administrator, using the BadSuccessor technique.

dMSA Misuse

If an attacker or low-privileged user attempts to initiate the migration process for an existing service account, the operation will fail, because only administrative users can initiate migration. Instead of initiating the migration process, a potential attacker would create a dMSA and then change the same dMSA attributes that the valid migration process changes. This mimics a migration and has the same effect on the migrated account.

By default, only high-privileged users can create dMSAs under the default Managed Service Accounts container. However, other users can create dMSAs in other containers. This ultimately means that any domain user who has Create all child objects or msDS-DelegatedManagedServiceAccount permissions on an organizational unit (OU) could potentially compromise the entire domain.

The following steps detail how an attacker could simulate the migration:

• Set the msDS-ManagedAccountPrecededByLink attribute to contain the DN of the account the attacker wants to impersonate.
• Set msDS-DelegatedMSAState to 2, to indicate that the migration process is complete.

After changing these attributes and authenticating as the dMSA, the attacker obtains the full permissions of the superseded account.

Any user with sufficient permissions can execute this method in any AD environment managed by a Windows Server 2025 domain controller (DC).

BadSuccessor Simulation

Before performing the actual attack, an attacker must ensure the compromised user has sufficient permissions to create all child objects or dMSAs. Akamai released a PowerShell script named Get-BadSuccessorOUPermissions.ps1 that finds domain accounts that have the appropriate permissions on an OU to perform the BadSuccessor technique.

Figure 1 shows an example of Akamai's tool in action in a test AD environment. The output provides details of the objects in the domain that can be leveraged for BadSuccessor.

In the example from Figure 1, the results indicate that an account named test_weak has the correct permissions to create a dMSA object under the OU DelegatedOU.

The enumeration tool performs the command shown in Figure 2 to retrieve OU DNs and their security descriptors.

After the tool retrieves the OU DNs and their security descriptors, it reviews the output to find the following rights:

• Create Child: msDS-DelegatedManagedServiceAccount
• Create Child: All Objects

The tool’s output reveals all users and OU pairs that can potentially be leveraged for the BadSuccessor technique.

Using a newly found account with the required permissions, an adversary can potentially perform the BadSuccessor technique using PowerShell's Active Directory Module and LDAP, as described in the Akamai article.

• First, the attacker creates a dMSA under the found OU. We demonstrate this in Figure 3 by creating a dMSA object named attacker_dMSA.

• Next, the attacker changes the attributes of the dMSA object to simulate the migration process. We demonstrated this in our test environment by setting the following values:
  • msDS-ManagedAccountPrecededByLink attribute to contain the DN of the superseded account
  • msDS-DelegatedMSAState to 2, to indicate that the migration process is complete

Now that we know how the BadSuccessor technique works, let’s explore how different tools can automate an attack.

SharpSuccessor

SharpSuccessor is a proof of concept (PoC) hosted on a GitHub repository that automates the BadSuccessor technique. Figure 5 simulates an attack using a user account named test_weak in our test environment. This account has permissions to create a dMSA object under the DelegatedOU.

Figure 6 shows that the attacker_dMSA account is subsequently created in the OU.

Figure 7 shows how test_weak changed the msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState attributes of attacker_dMSA. This simulates the completion of the migration.

Pentest-Tools-Collection BadSuccessor Module

The Pentest-Tools-Collection recently added a BadSuccessor module as one of its AD tools. This module has two modes:

• Check mode
• Exploit mode

Like the enumeration tool we previously discussed, this module’s check mode enumerates an AD environment. This enumeration indicates whether the environment can be exploited using the BadSuccessor technique and what OU can be used for a successful attack.

Figure 8 shows the results of this module after we ran it in check mode in our test environment.

This module’s exploit mode creates a dMSA object and sets its attributes to falsely indicate that a migration process is complete. Figure 9 shows the use of this module in exploit mode automating the same BadSuccessor process previously shown in Figures 3 and 4.

Domain Compromise

After successfully executing the BadSuccessor technique, potential attackers can further exploit the domain using Rubeus, which supports dMSA authentication. Figure 10 illustrates some Rubeus commands using the attacker_dMSA object in our test environment to gain access to privileged services in the domain.

Figure 11 shows that after executing these Rubeus commands, test_weak can now access the network share C$ drive on the DC, which requires Domain Admin privileges.

Detecting BadSuccessor Activity

As presented in the Akamai article, the operations involved in BadSuccessor can be monitored via the following event IDs:

• Event ID 5137 — Tracks the creation of dMSA objects
• Event ID 5136 — Tracks the modification of the msDS-ManagedAccountPrecededByLink attribute
• Event ID 2946 — Tracks the Ticket Granting Ticket (TGT) that is generated for a dMSA

But we propose an alternative way to track BadSuccessor activity and the footprints that it leaves behind; by leveraging Event ID 4662.

When a user creates a dMSA object, the initiating user or process requires and uses the CreateChild access rights on the OU. Figure 12 shows how dMSA object creation using the CreateChild access rights is reflected in Event ID 4662 (An operation was performed on an object).

The same Event ID is generated when a user with sufficient access rights modifies the following two attributes in the properties of the dMSA object.

• 2f5c138a-bd38-4016-88b4-0ec87cbb4919 represents msDS-DelegatedMSAState
• a0945b2b-57a2-43bd-b327-4d112a4e8bd1 represents msDS-ManagedAccountPrecededByLink

Changing the above dMSA attributes triggers the event shown in Figure 13.

Legitimate dMSA Migration Process Footprints

To better detect BadSuccessor, we must also know the differences between the footprints of malicious dMSA activity and legitimate dMSA migration. Only Administrative users can legitimately migrate service accounts to dMSA objects. To detect BadSuccessor activity, we must search for unprivileged users who have created a dMSA and then accessed the object’s specific attributes with the Access Mask value of 0x20 as shown in Figure 13.

A slightly different footprint is created when a privileged user creates a dMSA legitimately and then migrates a service account. According to Microsoft's guide, only a privileged user can create a dMSA under the OU Managed Service Account. The Event 4662 log entry in Figure 14 shows an Administrator user creating a child object (the dMSA) in the Managed Service Account OU.

A legitimate migration uses an initial msDS-DelegatedMSAState attribute with a value of 1. Figure 15 shows that the msDS-DelegatedMSAState attribute was changed in the first step of the migration process, while Figure 16 shows it was changed to 1.

Figure 17 shows the last step that consists of changing the msDS-DelegatedMSAState attribute to 2, and changing the msDS-ManagedAccountPrecededByLink attribute to the superseded account.

Enabling Auditing

To identify the attack footprint and conduct detection activities, auditing must be enabled. Figure 18 shows an example of a relevant auditing interface.

Conclusion

We examined the BadSuccessor technique and explored how, under certain conditions, adversaries can exploit the newly introduced dMSAs in a Windows Server 2025 DC to compromise the domain. We also analyzed the operational footprints left by this activity and proposed a novel detection strategy to identify such attacks.

Given how effective this attack can be, we strongly recommend closely monitoring Microsoft’s updates to understand available mitigation strategies and to properly configure all permissions — particularly those related to the BadSuccessor attack.

Palo Alto Networks Protections

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

One such product is Palo Alto Networks XSIAM, which can detect BadSuccessor activity if Windows security auditing is enabled on the dMSA. Our security auditing guide for Microsoft Windows systems provides information on how to configure the required auditing on Windows Server 2025.

Figure 19 shows an example of a “Possible Privilege Escalation using delegated MSA account attempt” in XSIAM.

Cortex XDR and XSIAM detect user and credential-based threats by analyzing user activity from multiple data sources including endpoints, network firewalls, AD, identity and access management solutions, and cloud workloads. Cortex builds behavioral profiles of user activity over time with machine learning. By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex detects anomalous activity indicative of credential-based attacks.

Unit 42 Managed Detection and Response Service delivers continuous 24/7 threat detection, investigation and response/remediation to customers of all sizes globally.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

BadSuccessor

• BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory — Akamai
• Setting up delegated Managed Service Accounts — Microsoft
• Account attributes for dMSA — Microsoft

Enabling Auditing

• Enable auditing access to AD domain objects — 4662 — Palo Alto Networks

Tools

• Get-BadSuccessorOUPermissions.ps1 — GitHub
• SharpSuccessor — GitHub
• NetExec BadSuccessor module — GitHub

Appendix

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team has created queries that can help defenders identify potential signs of dMSA misuse and use of SharpSuccessor.

Assuming that all auditing has been enabled and event logs are being properly ingested, the query provided below can be used to identify potential signs of SharpSuccessor execution.

As SharpSuccessor creates a computer account, hunters can correlate SubjectLogonIDs to identify relevant events. Event ID 4741 indicates that a computer account was created, and Event ID 4662 shows that an operation was performed — in this case, dMSA creation. Then, hunters can enrich the details of the user account that performed the action, by correlating Event ID 4624 to pull in information such as:

• Workstation name
• IP address
• Logon type

We recommend running this query on smaller time frames, given the multiple joins and alter commands leveraged.

For customers who have enabled auditing and are ingesting Event ID 5136, the following query can be used to identify creation of dMSAs.

Additionally, the following query can be used to identify which gMSA or standalone Managed Service Account (sMSA) account the new dMSA should supersede:

The following queries can be used independently. Alternatively, they can be combined in a single query that will show details of the new dMSA, the new account name and the superseded accounts.

XDR Alerts and MITRE Techniques

Table 1 lists the Cortex XDR alerts and the associated MITRE ATT&CK techniques these alerts detect.

Alert Name	Alert Source	ATT&CK Technique
Possible Privilege Escalation using Delegated MSA account	XDR Analytics, Identity Analytics	Account Manipulation (T1098)
Rare machine account creation	XDR Analytics BIOC, Identity Analytics	Create Account (T1136)

Table 1. Relevant alerts and MITRE techniques.

Related Articles

• Project AK47: Uncovering a Link to the SharePoint Vulnerability Attacks
• Active Exploitation of Microsoft SharePoint Vulnerabilities: Threat Brief (Updated July 31)
• Behind the Clouds: Attackers Targeting Governments in Southeast Asia Implement Novel Covert C2 Communication