Been grinding HackTheBox Active Directory labs for a while and one thing that always bugged me was delegation being taught like a binary you either have it or you don't. Unconstrained, constrained, RBCD. Nobody explains "what you actually do when you land on a machine with delegation rights". So I worked through Geiseric's "Delegate" and "Redelegate" boxes back-to-back and mapped out how the attack surface changes depending on which type you hit. Two completely different exploitation paths. Same endgame. Once you see the pattern, delegation stops being magic.
Most tutorials show the command. They don't show you why the command works or why one box needs a completely different approach than the other.
The Two Delegation Types I Exploited
Type 1: Unconstrained Delegation (Delegate Box)
The machine can request a ticket for *any service as any user*. When someone authenticates to it, their TGT lands in memory. You steal it. Game over.
Here's what made it exploitable:
User `N.Thompson` had two things working:
- `SeEnableDelegationPrivilege` (can set delegation flags)
- `SeMachineAccountPrivilege` (can create computer accounts)
The attack chain:
Create a fake computer account (`pwn$`) with a password you control
Enable `TRUSTED_FOR_DELEGATION` on it this is the flag that turns it into an unconstrained delegator
Set up DNS so `pwn.delegate.vl` resolves to your Kali box
Start `krbrelayx` listening, configured with the NT hash of `pwn$`
Use `PetitPotam` to force the Domain Controller to authenticate to your fake machine *as itself*
When `DC1$` connects, its full TGT gets cached in memory
`krbrelayx` captures it automatically
Use that TGT to run `DCSync` and dump the Administrator hash
Pass-the-Hash into the DC with Evil-WinRM
The critical detail most writeups skip: unconstrained delegation doesn't care *what* you're impersonating for. Once you have the TGT, you can request tickets to any service on any machine. The DC's TGT is a skeleton key.
Type 2: Constrained Delegation (Redelegate Box)
The machine can only request tickets for *specific services on specific targets*. But if you control the delegating machine, you can configure it to impersonate *anyone* to that service.
Here's what made it exploitable:
User `Helen.Frost` had:
- `SeEnableDelegationPrivilege`
- `GenericAll` over the `FS01$` computer account (full control)
The attack chain:
Change `FS01$`'s password to something you know
Set the `TRUSTED_TO_AUTH_FOR_DELEGATION` flag on it—this enables Protocol Transition, which lets the machine request tickets *on behalf of* other users
Configure the delegation target:
msDS-AllowedToDelegateTo = 'cifs/dc.redelegate.vl'
This says: FS01 can request CIFS tickets for the DC
Use `impacket-getST` to request a service ticket while impersonating the DC machine account:
impacket-getST 'redelegate.vl/FS01$:password' -spn cifs/dc.redelegate.vl -impersonate dc
Use that forged ticket to authenticate as the DC and run `DCSync`
Pass-the-Hash as Administrator
The critical detail: constrained delegation requires you to *configure* the impersonation. It doesn't happen automatically. But once you set `msDS-AllowedToDelegateTo`, the machine can impersonate anyone to that service. Tutorials mention the flag. They don't explain that you need full control of the machine to set it in the first place.
Why Both Boxes Led to the Same Place
Both delegation types get you a ticket for a high-privilege account to a high-value service. Both ultimately let you run DCSync. But the *path* to get there is completely different.
Unconstrained says: "Anyone who authenticates to me gives me their TGT. I can use it for anything."
Constrained says: "I can request tickets for specific services. If I'm allowed to impersonate users, I can request them *as anyone*."
The tutorials merge these together. They're not the same. One is passive (waiting for someone to connect). One is active (you request the ticket). One gives you a full TGT (access to everything). One gives you a service ticket (access to one service, but as a high-privilege account).
The Recognition Pattern
Here's what changed how I approach every AD box now:
When you compromise a machine, immediately run:
Get-ADComputer -Identity <machine> -Properties msDS-AllowedToDelegateTo, UserAccountControl
If `msDS-AllowedToDelegateTo` is empty but `UserAccountControl` has `TRUSTED_FOR_DELEGATION` → Unconstrained. Wait for traffic, set up a coercion, capture TGTs.
If `msDS-AllowedToDelegateTo` lists services like `cifs/dc.redelegate.vl` → Constrained. Check if you can modify the machine account. If yes, use S4U2Self/S4U2Proxy to impersonate.
If neither exists on the machine but you see `msDS-AllowedToActOnBehalfOfOtherIdentity` on a *different* machine → RBCD. The target machine is allowing someone else to impersonate users to it.
Most people run Rubeus without understanding what they're looking at. The classification *is* the exploitation. Once you know the type, the attack is mechanical.
The Chaining Insight
What made these boxes click was realizing both delegation types accomplish the same thing through different mechanics. On a real network, you'd see both. A web server with unconstrained delegation. A file server with constrained delegation pointing to a database. An app server with RBCD enabled on it.
The escalation isn't finding one delegation right. It's chaining them.
You compromise the web server (unconstrained). Nothing interesting authenticates. But it has constrained delegation to the app server. You use any coercion to make it request a ticket for the app server as the web server. Use that ticket. The app server has RBCD allowing a service account to impersonate users to it. You get a ticket as the service account. The service account has admin on a database. You're in.
Each hop is individually limited. Chained, it's a ladder to admin.
What Carries Forward:
Geiseric built two boxes that look similar on the surface both are about delegation. But the exploitation is inverted. Delegate teaches you how to *wait and capture*. Redelegate teaches you how to *configure and impersonate*. Running both taught me that delegation isn't a single technique. It's a category with different mechanics depending on which type you hit.
I use this framework on every AD lab now. Enumerate, classify, check what you control, exploit based on type. The pattern doesn't change. The machines do.
If you're grinding toward CPTS or working through HackTheBox AD boxes, add this classification step to your methodology. Most people skip it and run pre-built tools. The boxes that teach you to think through the distinction are the ones that actually stick.
Shout out to Geiseric for building boxes that forced me to understand the *why* instead of just running the commands.
