AWS Managed Active Directory machine creation enables RBCD abuse

At a glance

What this is: This is a Permiso Security analysis of how AWS Managed Active Directory default machine-joining behaviour can be abused to create computer accounts and enable RBCD-based escalation.

Why it matters: It matters because IAM teams must treat managed directory defaults, machine-account creation, and delegated access as governance problems, not just Windows configuration details, across NHI, human, and cloud identity programmes.

By the numbers:

• 10.

👉 Read Permiso Security's analysis of AWS Managed Active Directory machine-join abuse

Context

AWS Managed Active Directory inherits core Active Directory behaviour, including machine-account creation paths and delegation controls, but AWS constrains where administrators can intervene. That creates a governance gap: some defaults remain in place even when the managed service changes the operational boundary around them.

The result is an NHI and directory-security issue rather than a purely Windows-admin issue. If non-privileged identities can create computer objects or leverage delegated join permissions, the attack surface shifts from password or MFA failures to standing machine trust and directory object abuse.

Key questions

Q: What breaks when non-privileged users can create machine accounts in managed Active Directory?

A: The trust model breaks because machine creation becomes an escalation path, not a harmless provisioning action. A low-privilege user can create or influence a computer object, then use delegation settings to impersonate a privileged identity. In managed AD, that can lead to service-ticket abuse and administrative access on target machines.

Q: Why do AWS Managed Active Directory defaults increase the risk of delegation abuse?

A: Managed directory defaults can preserve AD behaviours that assume full domain administration, even when the customer only has partial control. If machine-join groups, computer-object permissions, or broad cloud IAM policies remain open, attackers can turn legitimate join workflows into RBCD abuse and privileged impersonation.

Q: How do security teams know whether machine creation is being abused?

A: The clearest signal is unexpected computer-account creation by a non-admin identity, especially where CloudWatch records Event ID 4741 and the creator is not a domain controller or approved administrator. Teams should also correlate machine creation with instance profiles and directory-service API activity to spot delegated abuse.

Q: Who is accountable when a managed directory permits RBCD-style escalation?

A: Accountability is shared across the cloud provider, the platform team, and the identity team, but the customer still owns group membership, workload permissions, and monitoring. A managed service does not remove the need to govern who can join machines, who can create them through APIs, and who can modify delegation paths.

Technical breakdown

Machine account quotas and delegated joins in AWS Managed AD

In Active Directory, ms-ds-MachineAccountQuota controls how many computer objects a non-admin can add. AWS Managed Active Directory complicates this because customers do not get full domain administrative control, yet the default machine-join path still exists through delegated groups and service behaviour. The blog shows that AWS Delegated Add Workstations to the Domain can allow low-privileged users to create machine accounts even when the intended defensive meaning of quota-based control is supposed to be restrictive. In practice, the quota is only one part of the control plane; group membership and cloud service join mechanics can override the intended trust boundary.

Practical implication: review who can join machines to managed directories, not just the quota value.

RBCD abuse through machine object permissions

Resource-Based Constrained Delegation works by letting the target machine decide which principals may act on its behalf. If an attacker can write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, they can add an attacker-controlled computer account and request service tickets as privileged identities. The attack does not require domain admin rights once the machine object can be altered. The relevant risk is object-level write access, especially GenericWrite, WriteDACL, or WriteOwner, because those permissions can become a path into delegation abuse even when higher-privilege account compromise never occurs.

Practical implication: audit machine-object ACLs and delegation settings for write paths that enable RBCD.

AWS API and instance-profile paths to computer creation

The article also shows that machine creation can happen through AWS APIs such as directoryservice:CreateComputer and through instance profiles with managed policies that include ds:CreateComputer. That matters because the creation event may be attributed to service-side identities rather than the human or workload that initiated it, which weakens standard AD monitoring assumptions. If a policy grants broad directory-service privileges on all resources, an attacker who compromises an attached EC2 instance can create a machine account and then pivot into delegation abuse. The control issue is not just identity compromise, but over-broad cloud-to-directory authorization.

Practical implication: constrain ds:CreateComputer paths and alert on non-administrative machine creation events.

Threat narrative

Attacker objective: The attacker aims to turn limited directory or instance access into delegated administrative control over machines in the managed domain.

1. Entry occurs when an attacker gains access to a low-privileged domain user, an EC2 instance profile, or another identity that can invoke machine-creation paths in AWS Directory Service.
2. Escalation follows when the attacker creates or modifies a computer account, then abuses RBCD by setting msDS-AllowedToActOnBehalfOfOtherIdentity to impersonate a delegated identity.
3. Impact occurs when the attacker requests service tickets as the delegated administrative user and gains access to SMB, RDP, or other services on the target machine.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Default machine-join controls were designed for a world where directory admins control the boundary. That assumption fails in AWS Managed Active Directory because the customer does not control the same objects, the same service paths, or the same enforcement surface as on-prem AD. The implication is that quota-based thinking alone is insufficient for managed directory governance, because the trust boundary has shifted underneath the control.

RBCD is a machine-object privilege problem before it is a ticketing problem. Once write access exists on the computer object, the attacker can redefine who may act on behalf of that machine and then request service access as a privileged user. This is exactly why object ACLs and delegation attributes matter more than generic “least privilege” language. Practitioners should treat writable machine objects as escalation assets, not harmless directory metadata.

Machine creation in cloud directories is a governance event, not just an operational action. When ds:CreateComputer can be invoked by an EC2 instance profile or non-admin identity, the directory no longer has a clean separation between authorised provisioning and attacker-driven enrolment. That creates a named failure mode: delegated machine-join trust leakage. The practical conclusion is that cloud-to-directory authorisation must be reviewed as part of identity governance, not left to infrastructure teams alone.

The AWS Managed AD model exposes a shared-responsibility gap that many teams still misread. The vendor boundary does not remove customer responsibility for group membership, machine join rights, and alerting on computer-account creation. That means the governance problem sits across IAM, directory administration, and cloud workload permissions at once. Security teams should re-evaluate who can create machine trust in managed directories and who can observe it.

This attack pattern confirms that managed services can preserve legacy identity weaknesses while obscuring them operationally. The control is still an AD control, but the evidence moves into CloudWatch and the abuse path may originate from an AWS-managed policy rather than a classic domain admin workflow. Practitioners need to align directory monitoring, cloud IAM review, and delegation governance instead of treating them as separate programmes.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, showing that scope control is a measurable security variable.
• For a broader governance lens, read OWASP NHI Top 10 for the control patterns that keep delegated identities from becoming escalation paths.

What this signals

Delegated machine-join trust leakage: managed directories can preserve legacy AD behaviours while moving the control surface into cloud APIs and managed policies. Teams should expect more abuse paths to originate from provisioning and workload permissions rather than direct domain admin compromise.

With 70% of organisations granting AI systems more access than equivalent human workers, the same pattern of over-trust is already normalising across identity programmes, and that makes delegated machine creation harder to spot unless IAM, directory, and cloud logs are correlated.

Practitioners should prepare for identity governance to cover provisioning rights, not just authentication rights, and map machine creation pathways back to a named owner, a named workload, and a named monitoring control.

For practitioners

• Remove Domain Users from workstation-join groups Restrict AWS Delegated Add Workstations to the Domain so only administrators can join machines, and validate that ordinary domain users cannot create computer objects through the default path.
• Review every policy that grants ds:CreateComputer Inventory EC2 instance profiles and service roles with directory-service privileges, then remove broad create-computer access from workloads that do not explicitly need to provision domain machines.
• Audit machine-object delegation rights Check computer object ACLs for GenericWrite, WriteDACL, WriteOwner, and similar permissions that could let a low-privilege identity modify RBCD settings.
• Alert on non-admin computer creation events Monitor CloudWatch DirectoryService events for Event ID 4741 and investigate any machine account created by an identity that is not a domain controller or approved administrator.

Key takeaways

• AWS Managed Active Directory can expose a machine-join path that low-privileged identities can abuse for delegation-based escalation.
• The meaningful control failure is not just a loose quota value, but writable computer objects and broad directory-service permissions.
• Teams should govern machine creation, delegation rights, and CloudWatch detection together or risk missing the attack chain entirely.

Key terms

• Resource-Based Constrained Delegation: A delegation model in Active Directory where the target resource controls which principals may act on its behalf. It becomes dangerous when attackers can write the delegation attribute on a computer object, because they can impersonate privileged users without owning the target account directly.
• Machine Account Quota: The Active Directory setting that limits how many computer objects a non-admin user can create. In managed directories, the quota may remain in place even when customers cannot fully administer the domain, which makes the surrounding join workflow and group membership just as important as the setting itself.
• Delegated Machine Join: A governance pattern where non-admin identities are allowed to add machines to a directory or domain. In practice, it creates a trust boundary that must be tightly scoped, because machine creation can become the first step in escalation, persistence, or delegation abuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Permiso Security: An Arrow to the Heel: Abusing Default Machine Joining to Domain Permissions to Attack AWS Managed Active Directory. Read the original.