Detecting Kerberos Delegation Abuse: Unconstrained, Constrained, and RBCD Attack Paths (T1558)

Kerberos delegation is a legitimate Active Directory feature that allows a service to authenticate to another service on behalf of a user — enabling three-tier application architectures where a front-end web server needs to access a database with the user’s identity. It is also one of the most reliable privilege escalation paths in Active Directory environments, because misconfigurations in delegation settings are common and often go undetected for years.

Understanding and detecting delegation abuse requires clarity on three distinct delegation types, each with different attack paths and detection characteristics.

Understanding the Three Delegation Types

Unconstrained Delegation

A computer or service account configured for unconstrained delegation receives a copy of the Kerberos Ticket Granting Ticket (TGT) of every user who authenticates to it. The account stores these TGTs in memory (LSASS) and can use them to authenticate anywhere in the domain on the user’s behalf.

Why this is dangerous: If an attacker compromises a host with unconstrained delegation configured, they can extract any TGT stored in LSASS from users who have authenticated to that host — including domain administrators. Combined with coercion attacks (PrinterBug, PetitPotam, DFSCoerce), an attacker who controls a machine can force domain controllers to authenticate to the unconstrained delegation host, capturing the DC’s TGT and achieving domain compromise.

Unconstrained delegation is configured on computer and service accounts. Domain controllers themselves have unconstrained delegation, which is required for their function. The dangerous configurations are non-DC servers — IIS application servers, file servers, print servers — that have been configured with unconstrained delegation, often as a legacy workaround.

Active Directory attribute: TRUSTED_FOR_DELEGATION flag set in the userAccountControl attribute (value: 0x80000 = 524288 decimal).

Constrained Delegation

Constrained delegation limits which services the delegating account can authenticate to on behalf of users. The msDS-AllowedToDelegateTo attribute lists the specific SPNs (service principal names) the account can delegate to.

The S4U2Proxy extension: Constrained delegation uses the S4U2Proxy Kerberos extension — Service-for-User-to-Proxy — to request a service ticket on behalf of another user. However, the attacker does not need the user’s TGT. They can use S4U2Self (Service-for-User-to-Self) to obtain a forwardable service ticket for any user to themselves, then use S4U2Proxy to convert it to a service ticket for the target service. This means an attacker controlling a constrained delegation account can impersonate any domain user (including domain administrators) to any service listed in msDS-AllowedToDelegateTo.

Why this matters: If the service listed in msDS-AllowedToDelegateTo is cifs/DC01.domain.com (file sharing on a domain controller), an attacker with control over the constrained delegation account can authenticate as any domain admin to the DC and achieve DCSYNC.

Resource-Based Constrained Delegation (RBCD)

RBCD is a newer variant (Windows Server 2012+) that inverts the control model: instead of the delegating account specifying where it can delegate, the target resource specifies which accounts it trusts to delegate to it. This is controlled by the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer object.

The key attack path: If an attacker can write to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a target computer, they can configure an attacker-controlled account as trusted for delegation to that computer. They then use S4U2Self + S4U2Proxy to impersonate any domain user (including domain admins) to that computer.

The critical permissions that enable this attack:

• GenericWrite on a computer object
• GenericAll on a computer object
• WriteProperty targeting msDS-AllowedToActOnBehalfOfOtherIdentity

These permissions appear in AD environments more often than expected, particularly on workstations and servers where helpdesk accounts or service accounts have been granted broad write access.

Detection Approach

Detecting Unconstrained Delegation Abuse

Stage 1: Identifying unconstrained delegation hosts

Enumerate computers with unconstrained delegation as a baseline. Any new entry to this list is an immediate alert.

title: Computer Account Configured with Unconstrained Delegation
id: a2f3b891-c7d4-4e6a-9f2b-1d5c3e7a8912
status: stable
description: Detects when a computer account has the TRUSTED_FOR_DELEGATION flag set, indicating unconstrained Kerberos delegation configuration.
author: SOC Analyst Hub
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4742  # Computer account changed
  filter_dc:
    SubjectUserName|contains:
      - 'DC'
  filter_normal:
    # Baseline: existing unconstrained delegation hosts
    TargetUserName: []  # Populate with known unconstrained delegation hosts
  condition: selection and not filter_dc and not filter_normal
  # The actual check for TRUSTED_FOR_DELEGATION requires parsing UserAccountControl change events
  # Look for UserAccountControl delta with bit 0x80000 set
fields:
  - EventID
  - TargetUserName
  - SubjectUserName
  - UserAccountControl
falsepositives:
  - Legitimate new service accounts configured with unconstrained delegation (requires justification and review)
level: high
tags:
  - attack.privilege_escalation
  - attack.t1558

Stage 2: TGT coercion via SpoolSample / PrinterBug

Attackers force DC-to-unconstrained-delegation-host authentication using coercion primitives. The MS-RPRN interface (SpoolSample) is the most common.

title: Suspicious Print Spooler Remote Authentication - Potential PrinterBug Coercion
id: b3e4a912-d8f5-4c7b-ae34-2f6d1c8b5029
status: experimental
description: Detects use of the MS-RPRN printer protocol to trigger outbound authentication from a domain controller, a technique used to coerce DC TGT capture via unconstrained delegation.
author: SOC Analyst Hub
logsource:
  product: windows
  service: system
detection:
  selection:
    EventID: 5145  # Network share object access
    ShareName: "\\\\*\\IPC$"
    RelativeTargetName: "spoolss"
  filter_legitimate:
    IpAddress: "::1"  # Local loopback
  condition: selection and not filter_legitimate
fields:
  - IpAddress
  - SubjectUserName
  - ShareName
  - RelativeTargetName
falsepositives:
  - Legitimate print spooler management traffic (uncommon for DC-to-server flows)
level: high
tags:
  - attack.privilege_escalation
  - attack.t1558

KQL for TGT captured from a known unconstrained delegation host:

// Detect Kerberos TGT requests originating from unconstrained delegation hosts
// Requires list of known unconstrained delegation hosts in watchlist
let UnconstrainedHosts = datatable(ComputerName: string)
[
    // Populate from AD query: Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -ne "516"}
    "APP-SERVER-01",
    "LEGACY-IIS-02"
];
SecurityEvent
| where EventID == 4769 // Service ticket request
| where TicketOptions has "forwardable"
| where AccountName != "$"
| where Computer in (UnconstrainedHosts)
| where AccountName has_any ("admin", "da-", "svc-da")
| project TimeGenerated, Computer, AccountName, ServiceName, TicketOptions, IpAddress
| order by TimeGenerated desc

Detecting Constrained Delegation Abuse (S4U2Self + S4U2Proxy)

The S4U2Self/S4U2Proxy attack chain leaves specific Kerberos ticket request patterns. An attacker requesting a service ticket for a domain admin to themselves (S4U2Self) followed by requesting a ticket to the delegated service (S4U2Proxy) generates characteristic event sequences.

title: S4U2Self Kerberos Ticket Request for Privileged Account
id: c4f5b023-e9a6-5d8c-bf45-3g7e2d9c6130
status: experimental
description: Detects S4U2Self ticket requests where the requested account is a privileged user but the requesting service is not a legitimate delegation service. Indicates potential constrained delegation abuse.
author: SOC Analyst Hub
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769  # Kerberos service ticket operation
    TicketOptions|contains:
      - "forwardable"
  filter_name:
    # S4U2Self produces a service ticket where ServiceName matches the requesting account
    ServiceName: '%ServiceAccount%'  # Update with known legitimate delegation service accounts
  condition: selection and not filter_name
fields:
  - AccountName
  - ServiceName
  - ClientAddress
  - TicketEncryptionType
falsepositives:
  - Legitimate delegation services (filter based on known service accounts)
level: high

KQL for constrained delegation account enumeration activity:

// Detect LDAP queries enumerating constrained delegation configurations
// These queries are characteristic of pre-attack reconnaissance (BloodHound, PowerView)
SecurityEvent
| where EventID == 4662  // Directory service access
| where ObjectType == "Computer" or ObjectType == "User"
| where Properties has "msDS-AllowedToDelegateTo"
| where SubjectUserName !endswith "$"  // Exclude computer accounts doing legitimate replication
| project TimeGenerated, SubjectUserName, SubjectDomainName, ObjectName, Properties
| summarize count() by SubjectUserName, bin(TimeGenerated, 10m)
| where count_ > 10  // Multiple delegation attribute reads in 10 minutes = enumeration
| order by TimeGenerated desc

Detecting RBCD Attacks

RBCD attacks require modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This is the highest-fidelity detection event in the entire delegation abuse chain — it is a discrete, logged Active Directory object modification.

title: RBCD Attack - msDS-AllowedToActOnBehalfOfOtherIdentity Modified
id: d5g6c134-fa70-6e9d-cg56-4h8f3e0d7241
status: stable
description: Detects modification of the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer object — the core AD write operation required for Resource-Based Constrained Delegation attacks. This attribute should almost never be modified outside of deliberate RBCD configuration.
author: SOC Analyst Hub
references:
  - https://eladshamir.com/2019/01/28/Wagging-the-Dog.html
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136  # Directory service object modification
    AttributeLDAPDisplayName: "msDS-AllowedToActOnBehalfOfOtherIdentity"
  condition: selection
fields:
  - SubjectUserName
  - ObjectDN
  - AttributeLDAPDisplayName
  - AttributeValue
  - OperationType
falsepositives:
  - Legitimate RBCD configuration for specific service accounts (should be rare and documented)
level: critical
tags:
  - attack.privilege_escalation
  - attack.credential_access
  - attack.t1558

KQL — RBCD attribute modification with enrichment:

// High-fidelity detection of RBCD attack setup
// Event 5136 requires Directory Service Changes auditing enabled
SecurityEvent
| where EventID == 5136
| extend ParsedXml = parse_xml(EventData)
| where ParsedXml.EventData.Data has "msDS-AllowedToActOnBehalfOfOtherIdentity"
| project
    TimeGenerated,
    SubjectUserName = tostring(ParsedXml.EventData.Data[3]),
    SubjectDomainName = tostring(ParsedXml.EventData.Data[4]),
    ObjectDN = tostring(ParsedXml.EventData.Data[7]),
    AttributeValue = tostring(ParsedXml.EventData.Data[13])
| join kind=inner (
    // Correlate with Rubeus or similar tool execution on the same host
    SecurityEvent
    | where EventID in (4688, 4104)
    | where CommandLine has_any ("s4u", "rbcd", "AllowedToActOnBehalfOfOtherIdentity", "Rubeus")
    | project TimeGenerated, Computer, CommandLine
) on $left.TimeGenerated > $right.TimeGenerated - 1h

Threat Hunting Queries

Hunt 1: Enumerate All Delegation Configurations in the Environment

// This query requires Windows Security Events from a Domain Controller
// Identify all accounts with delegation configured by querying event 4742/4738 history
// Better executed via AD PowerShell query and imported as a watchlist:
// Get-ADComputer -Filter {TrustedForDelegation -eq $true} | Select Name, msDS-AllowedToDelegateTo
// Get-ADUser -Filter {TrustedForDelegation -eq $true} | Select SamAccountName

// KQL: hunt for Rubeus delegation commands in process creation
DeviceProcessEvents
| where FileName in~ ("Rubeus.exe", "PowerView.ps1")
    or ProcessCommandLine has_any (
        "s4u",
        "tgtdeleg",
        "asktgt",
        "dump /luid",
        "Get-DomainComputer -TrustedToAuth",
        "msDS-AllowedToDelegateTo"
    )
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, ParentProcessName
| order by TimeGenerated desc

Hunt 2: Coercion Attempts Against Domain Controllers

// Hunt for coercion attempts using MS-RPRN (PrinterBug), MS-EFSRPC (PetitPotam), MS-DFSNM (DFSCoerce)
// Look for authentication events where DC authenticates to non-DC hosts
SecurityEvent
| where EventID == 4624  // Successful logon
| where TargetDomainName contains "DC"
| where LogonType == 3  // Network logon
| where WorkstationName !contains "-DC" and WorkstationName !endswith "DC01" // Adapt to naming convention
| project TimeGenerated, TargetUserName, WorkstationName, IpAddress, LogonType, AuthenticationPackageName
| where TargetUserName endswith "$"  // Computer account authentication
| order by TimeGenerated desc

Operational Configuration Recommendations

Audit settings required

These detections require specific audit policies enabled:

• Audit Directory Service Changes (Success): Required for Event ID 5136 (msDS-AllowedToActOnBehalfOfOtherIdentity modification)
• Audit Kerberos Authentication Service (Success and Failure): Required for Event ID 4768 (TGT requests)
• Audit Kerberos Service Ticket Operations (Success and Failure): Required for Event ID 4769 (service ticket requests)
• Audit Directory Service Access (Success): Required for Event ID 4662

Hardening to reduce attack surface

Beyond detection, the following configurations reduce the exploitation surface:

• Remove unconstrained delegation from all non-DC servers. Most unconstrained delegation configurations are legacy — migrate to constrained or RBCD.
• Enable Protected Users security group for sensitive accounts. Protected Users accounts cannot be delegated — their TGTs cannot be forwarded, making them immune to delegation attacks.
• Disable the Print Spooler service on domain controllers where print functionality is not required. This eliminates the PrinterBug coercion vector against DCs.
• Audit msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity attributes across all computer and service accounts as a periodic baseline review.

Kerberos delegation attacks are consistently present in red team assessments and threat actor post-exploitation toolkits because they reliably convert limited AD access to domain admin privileges. The detection coverage described here should be treated as a minimum baseline for environments with Active Directory.