A security analysis published on October 28, 2025, details a systemic weakness in Microsoft Active Directory environments related to the use of domain-join accounts. These accounts, designed to automate the process of joining computers to a domain at scale, are frequently over-privileged by default. Even when following official guidance, these accounts inherit powerful permissions that threat actors can abuse for privilege escalation and full domain compromise. The risk is twofold: the credentials for these accounts are often exposed in plaintext during deployment processes, and their default rights allow for the takeover of the computer objects they create, creating a reliable vector for attackers to expand their foothold within a network.
The issue is not a single CVE but a systemic configuration weakness in how Active Directory handles permissions for accounts delegated the right to join computers to the domain.
Credential Exposure: During automated OS deployments using tools like Microsoft Configuration Manager (MCM) or PXE boot processes, the credentials for the domain-join account are often stored in plaintext within configuration files like unattend.xml or in deployment scripts. An attacker with initial access to the network can often easily recover these credentials.
Excessive Inherited Privileges: Once an attacker has the credentials, they can abuse the permissions the domain-join account holds over the computer objects it creates:
Read access to all attributes, which can expose sensitive information like the LAPS password (ms-Mcs-AdmPwd).Write permission to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the computer object. This allows an attacker to configure RBCD, effectively granting them the ability to impersonate any user and authenticate to that computer, leading to a full takeover of the machine (T1558.003 - Kerberoasting).This creates a repeatable attack path: obtain domain-join credentials -> use them to create a new computer object -> abuse ownership and RBCD rights to take over that computer -> escalate privileges further.
This is a configuration and architectural weakness affecting virtually all Active Directory Domain Services environments that use dedicated accounts for automated domain joins, a common practice in medium to large enterprises.
This attack path has been known in the security community for some time, with initial reports dating back to 2021. It is a well-documented technique used by penetration testers and likely by advanced threat actors. Microsoft acknowledged the complexity and risks in official guidance published in August 2025.
The impact of this misconfiguration is severe, as it provides a direct and often easy path to privilege escalation.
SYSTEM privileges on any machine they are able to create.47415136msDS-AllowedToActOnBehalfOfOtherIdentity attribute.PowerView.ps1, Add-DomainComputerunattend.xml, cct-provisioning-data.xmlBloodHound or PowerShell scripts to identify accounts with excessive rights.msDS-AllowedToActOnBehalfOfOtherIdentity attribute (Event ID 5136), especially when performed by a service account or outside of expected administrative activity.D3-DAM: Domain Account Monitoring is key to detecting abuse of these accounts.D3-AZET: Authorization Event Thresholding can help detect when an account performs an unusual number of privileged actions.Microsoft and security researchers recommend a layered defense to mitigate this risk.
msDS-AllowedToActOnBehalfOfOtherIdentity attribute for the domain-join account on the OU where computer objects are created. This directly blocks the RBCD attack vector.D3-UAP: User Account Permissions is the core principle for hardening these accounts.D3-ACH: Application Configuration Hardening applies to securing the deployment tools that use these credentials.Properly configuring permissions, such as reassigning object ownership and using Deny ACEs, is the core mitigation strategy.
Mapped D3FEND Techniques:
Treating the domain-join account as a privileged account and securing its credentials is a key part of the solution.
Mapped D3FEND Techniques:
To break the attack chain involving domain-join accounts, administrators must proactively harden their permissions in Active Directory. The most effective step is to apply an explicit 'Deny' Access Control Entry (ACE) for the 'Write to msDS-AllowedToActOnBehalfOfOtherIdentity' permission for the domain-join account. This ACE should be set on the Organizational Unit (OU) where new computer objects are created. This single change directly blocks the Resource-Based Constrained Delegation (RBCD) abuse vector. Additionally, an automated process should be created to run after a machine is provisioned; this process should change the owner of the new computer object from the domain-join account to a protected group like 'Domain Admins'. These two permission changes remove the excessive inherited privileges and neutralize this well-known privilege escalation path.
For detection, robust Domain Account Monitoring is essential. Security teams must configure detailed auditing on their Domain Controllers to log directory service changes (Event ID 5136). Create a high-priority alert in your SIEM that triggers whenever the msDS-AllowedToActOnBehalfOfOtherIdentity attribute is modified by any account other than a highly privileged, designated administrator. Since this attribute is the cornerstone of the RBCD attack, monitoring its modification is a high-fidelity way to detect an attack in progress. Correlate this alert with the account that performed the change; if it's a service account or a standard user, it is a major red flag that requires immediate investigation.
Initial security research on the risks of domain-join accounts begins to be published.
Microsoft publishes official guidance acknowledging the complexity of securing these accounts.

Cybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Help others stay informed about cybersecurity threats
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.