Kerberos Delegation Abuse
Also calledUnconstrained delegation, Constrained delegation, RBCD, S4U
Uses a server trusted for delegation to reach other services in users' names.
- Technique
- MITRE ATT&CK T1550.003: Use Alternate Authentication Material: Pass the Ticket (opens in a new tab)MITRE ATT&CK T1484: Domain or Tenant Policy Modification (opens in a new tab)
- Hooks Into
- Kerberos TGS RequestKerberos AP Request
- Needs
- Delegation ServerorDirectory Write
- Gives
- TGTandService TicketandDC Account
How the Attack Works
When a user who is not protected from delegation signs in with Kerberos to a server trusted for unconstrained delegation, the client also sends a forwarded copy of the user's TGT and its session key, and the server keeps both in LSASS. Whoever controls that server can use those TGTs anywhere, as those users, until they expire. Constrained and resource-based delegation forward no TGT, but let a server ask for tickets in a user's name to the services allowed (S4U2self and S4U2proxy). Control of such a server, or the right to write a computer's resource-based delegation attribute, therefore reaches those services as users not protected from delegation.
Read first Authentication and Authorisation, AP Exchange: Using the Ticket, The PAC and Its Signatures, Kerberos Delegation
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
ws-017 Client
- dana's key
- TGT
- TGT session key
- service ticket
- service session key
srv-app-01 Web app server
dc-01 Domain controller
- dana's key
- krbtgt key
- srv-fin-01 key
Step 1 of 4: AP Request and TGT
ws-017 Client to srv-app-01 Web app server
Ticket shown, with a copy of her TGT
KRB_AP_REQKerberos over HTTP, port 443dana opens the web app, and because srv-app-01 is trusted for unconstrained delegation, ws-017 sends a forwarded copy of her TGT too.
What Travels in This Step
An authenticator
KRB-CREDdana's name, the time, and a KRB-CRED holding a forwarded copy of her TGT and its session key
Encrypted with the service session key Only ws-017 and srv-app-01 can open it.
Keys and Tickets
- srv-app-01 now holds TGT (new at this step) TGT session key (new at this step) service session key (new at this step)
Logged
4624 An account was successfully logged on
On srv-app-01, in the Security log
Impersonation Level Delegation, so the server may use her identity on other machines
Reading Logon Events explains how to read it.
What Defenders See
The Security log on srv-app-01 shows event 4624 for dana with Impersonation Level Delegation. Nothing in the log marks the TGT inside her request.
Hooks into Kerberos AP Request
Step 2 of 4: TGTs Kept in Memory
On srv-app-01 Web app server
srv-app-01 keeps the forwarded TGT and session key in LSASS. Whoever controls it can take every one it holds.
What Defenders See
If the TGTs are copied out, srv-app-01 shows the signs of LSASS access, such as Sysmon event 10 in its Microsoft-Windows-Sysmon/Operational log. Used in place, they show only in the Security logs on dc-01 and the services they reach.
Step 3 of 4: TGS Request as dana
srv-app-01 Web app server to dc-01 Domain controller
Request for a ticket in dana's name
KRB_TGS_REQKerberos, port 88With her TGT, srv-app-01 asks dc-01 for a ticket in her name to srv-fin-01, a service the web app never uses.
What Travels in This Step
dana's forwarded TGT
Her name and groups, as the DC issued them
Encrypted with the krbtgt AES key Only dc-01 can open it.
An authenticator
dana's name and the time
Encrypted with the TGT session key Only ws-017, srv-app-01 and dc-01 can open it.
Logged
4769 A Kerberos service ticket was requested
On dc-01, in the Security log
Account Name dana@CORP.EXAMPLE, Service Name srv-fin-01$, Client Address ::ffff:192.0.2.25
TGS Reply: The Service Ticket explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4769 for dana from srv-app-01's address with Transited Services empty, so it looks like her own request.
Hooks into Kerberos TGS Request
Step 4 of 4: Ticket in dana's Name
dc-01 Domain controller to srv-app-01 Web app server
Reply with a ticket in dana's name
KRB_TGS_REPKerberos, port 88dc-01 issues the ticket as it would to dana herself, since nothing tells it who holds her TGT.
What Travels in This Step
The service ticket
dana's name and groups, for srv-fin-01
Encrypted with srv-fin-01's AES key Only dc-01 can open it.
Keys and Tickets
- srv-app-01 now holds service ticket (new at this step)
What Defenders See
Nothing more shows, because the reply writes no event of its own to the logs on dc-01.
Needs First
What the attacker must already hold for this attack to be possible.
- A Server Trusted for Delegation or Write Access to a Directory ObjectControl of a server trusted for delegation, or the right to change a computer's resource-based delegation.
Comes From
- Directory Write: DCShadow
Gives the Attacker
What running it hands the attacker to use next.
- A TGTThe TGTs of users who sign in to an unconstrained delegation server, usable anywhere.
- A Service TicketService tickets in the name of any user not protected from delegation, to the services it reaches.
- A DC's Computer AccountA DC's own TGT, when a forced callback makes a DC sign in to an unconstrained delegation server.
Leads To
- TGT: Pass-the-Ticket
- Service Ticket: Pass-the-Ticket
- DC Account: DCSync
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 4769 A Kerberos service ticket was requested (opens in a new tab) Security log | Domain controllers | A user's tickets asked for from a delegation server's address to services it never uses, with Transited Services filled for constrained delegation.TGS Reply: The Service Ticket explains how to read it. | Audit Kerberos Service Ticket Operations |
| 4742 A computer account was changed (opens in a new tab) Security log | Domain controllers | 'Trusted For Delegation' or 'Trusted To Authenticate For Delegation' enabled, or AllowedToDelegateTo changed, on a computer. | Audit Computer Account Management |
| 4738 A user account was changed (opens in a new tab) Security log | Domain controllers for domain accounts, the computer itself for local ones | The same delegation settings changed on a user account, such as a service account. | Audit User Account Management |
| 5136 A directory service object was modified (opens in a new tab) Security log | Domain controllers, for objects with a matching audit entry | msDS-AllowedToActOnBehalfOfOtherIdentity written on a computer, which grants resource-based delegation and is seen only with an audit entry. | Audit Directory Service Changes, and an audit entry (SACL) on the object |
| 4741 A computer account was created (opens in a new tab) Security log | Domain controllers | A computer account created by an ordinary user, which resource-based delegation abuse can then use. | Audit Computer Account Management |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
4769 A Kerberos service ticket was requested
In the Security log on dc-01,
A ticket to srv-fin-01 in dana's name, asked for by srv-app-01 with her forwarded TGT.
The ticket is in dana's name, though dana did not ask for it.
As Windows writes it:
Account Namedana@CORP.EXAMPLEThe file server. Delegation exists so the web app can reach its own back end for users. A service it never uses is the lead.
As Windows writes it:
Service Namesrv-fin-01$srv-app-01, not ws-017, because her forwarded TGT is being used by the server that holds it.
As Windows writes it:
Client Address::ffff:192.0.2.25Empty, because with unconstrained delegation the server presents dana's own TGT, so this reads like a request she made herself.
As Windows writes it:
Transited Services-
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Suspicious resource-based constrained delegation (RBCD) attribute change (opens in a new tab)
- Suspicious resource-based constrained delegation (RBCD) authentication (opens in a new tab)
- Suspicious Kerberos delegation attempt by a newly created computer (opens in a new tab)
- Suspicious modification of the Resource Based Constrained Delegation attribute by a machine account (opens in a new tab)
- Suspicious Kerberos delegation attempt using BronzeBit method (CVE-2020-17049 exploitation) (opens in a new tab)A 2020 flaw in constrained delegation, fixed by the updates KB4598347 describes and enforced since July 2021.
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- Unconstrained delegation is quiet in use, because the forwarded TGT rides inside an ordinary sign-in, so know which servers hold the setting rather than wait for its use.
- 4742 does not show resource-based delegation, and only 5136, with an audit entry on the attribute, records that change. Defender for Identity alerts on suspicious ones.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs Defender for Identity sensors on every DC. An attribute change alert shows the setup, not an impersonation. To see which servers hold unconstrained delegation, use the Unsecure Kerberos delegation assessment.
// Defender for Identity alerts on Kerberos delegation, with the accounts and devices in themAlertEvidence| where Timestamp > ago(How to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
No unconstrained delegation (opens in a new tab)
Replace unconstrained delegation with constrained or resource-based delegation, so no server collects TGTs.
Sensitive accounts not delegated (opens in a new tab)
Mark admin accounts as sensitive, so no server can act in their name.
Protected Users group (opens in a new tab)
Add privileged accounts to Protected Users, so they are never delegated, by unconstrained or constrained delegation.
Credential Guard (opens in a new tab)
Turn on Credential Guard on clients, so they block unconstrained delegation and never forward a TGT.
Check it on a machine: Credential Guard (LsaCfgFlags)MachineAccountQuota at zero (opens in a new tab)
Set MachineAccountQuota to 0, so ordinary users cannot create a computer account to use in resource-based abuse.
Print Spooler off on domain controllers (opens in a new tab)
Stop the Print Spooler on DCs, closing one forced callback that hands a DC's TGT to an unconstrained delegation server.
Sources
- MITRE ATT&CK T1550.003: Use Alternate Authentication Material: Pass the Ticket (opens in a new tab)
- MITRE ATT&CK T1484: Domain or Tenant Policy Modification (opens in a new tab)
- Microsoft Learn: Kerberos constrained delegation overview (opens in a new tab)
- RFC 4121 section 4.1.1: Authenticator checksum (the forwarded TGT) (opens in a new tab)
- [MS-SFU] 1.3.2: S4U2proxy (opens in a new tab)
- [MS-SFU]: resource-based constrained delegation (opens in a new tab)
- Microsoft Learn: Unsecure Kerberos delegation (posture assessment) (opens in a new tab)
- Microsoft Learn: Credential Guard, delegation considerations (opens in a new tab)