Skills · learning

Kerberos Basics and Unconstrained Delegation

Table of Contents

• Kerberos at a glance
• The three exchanges
• Why the ticket keys matter
• Unconstrained delegation
• CRTO lab: lon-ws-1 and dyork
• Fork and run versus inline BOFs
• Fact-check status
• Review prompts

Kerberos Basics and Unconstrained Delegation

Quick references: task-first command sheet · detailed command reference · exam navigator

Kerberos at a glance

Kerberos is the normal domain authentication path in Active Directory. A principal is an account, such as a user or computer. A domain controller acts as the Key Distribution Center (KDC): it has access to account keys in AD and provides an Authentication Service (AS) and Ticket Granting Service (TGS). The client proves possession of its key to obtain a ticket-granting ticket (TGT), then uses the TGT to request a service ticket for an SPN such as cifs/lon-dc-1.contoso.com. The target service makes the final authorization decision. A valid ticket does not itself grant share or database rights.

The three exchanges

sequenceDiagram
    participant C as Client
    participant K as KDC on domain controller
    participant S as Target service
    C->>K: AS-REQ + pre-authentication proof
    K-->>C: AS-REP: TGT + encrypted client–KDC session key
    C->>K: TGS-REQ: TGT + authenticator + target SPN
    K-->>C: TGS-REP: service ticket + client–service session key
    C->>S: AP-REQ: service ticket + authenticator
    S-->>C: AP-REP when mutual authentication is requested
    Note over S: Authenticate, then authorize the requested action

AS exchange: the client requests a TGT. With common password-based pre-authentication, it proves knowledge of its account key. The KDC returns the TGT and a session key protected for the client. If pre-authentication is disabled, the response material can be an offline guessing target: the AS-REP roasting connection.

TGS exchange: the client presents its TGT and an authenticator encrypted with its client–KDC session key, and names the target SPN. The KDC issues a service ticket protected with the service account key. This is the Kerberoasting connection: a weak service-account secret may be guessed offline from the ticket material. The KDC issuing a ticket does not decide whether the user may access the service.

Application exchange: the client presents the service ticket inside the application protocol, such as SMB session setup. The service decrypts it with its own key and validates the authenticator. An AP-REP can provide mutual authentication. The service then checks the requested operation against its authorization rules.

Why the ticket keys matter

The client can use a TGT without decrypting its KDC-protected contents. It does need the corresponding session key to build authenticators and decrypt its part of KDC replies. The KDC uses the krbtgt account key to protect TGT contents; the service uses its own account key to decrypt its service ticket. Keep ticket, session key, and account key separate when reasoning about attacks. A ticket has a client, service, realm, flags, start/end times, and possibly a PAC; inspect those fields before treating it as reusable.

Windows tickets can carry a Privilege Attribute Certificate (PAC) with identity and authorization data such as group SIDs. PAC signatures help services or the KDC validate that data; the exact validation path depends on service and Windows configuration. The PAC is not a blanket authorization grant: the target service still evaluates the requested operation and its own access rules.

Unconstrained delegation

A front-end service may need to access a back-end service for a user. When a service account is trusted for unconstrained delegation, an eligible Kerberos client can forward a delegated TGT to that front-end host. The host can then request other service tickets as that user. This is why compromising such a host can expose other users' delegated TGTs as well as the host's own machine credentials.

Prerequisites, not guarantees: the account needs the delegation configuration, the user must actually authenticate to the service with delegation allowed, and a usable forwarded TGT must still be present and valid when inspected. An LDAP result alone does not prove a ticket is cached. Protected Users and accounts marked sensitive against delegation are examples where forwarding is restricted. The client, realm, service, flags, and expiration in krb_triage/krb_dump decide whether a captured entry matches the objective.

CRTO lab: lon-ws-1 and dyork

1. Enumerate from a Beacon that can query AD. The filter selects computer accounts (sAMAccountType=805306369) with the TRUSTED_FOR_DELEGATION bit (524288). The lab expects a domain controller and lon-ws-1$. Domain controllers commonly have this flag; the additional workstation is the lab lead. Check the current output rather than memorizing a host name.

ldapsearch (&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288)) --attributes samAccountName

2. Reach the delegating host. Use the prior authorized User Impersonation and Lateral Movement lab steps to authenticate as rsteel and obtain a new Beacon on lon-ws-1. Verify its hostname and that it is SYSTEM before inspecting other users' ticket caches. The rsteel identity is the route into the host; it is not the later ticket target.

3. Triage and verify the candidate. The course Kerberos BOF aliases are optional add-ons; Unknown command means they are not loaded. In the recorded lab, look for dyork@CONTOSO.COM with service krbtgt/CONTOSO.COM. Query memberOf for a Domain Admin lead, but direct memberOf output may miss nested group membership; verify the actual effective membership if the result is unclear.

krb_triage
ldapsearch samAccountName=dyork --attributes memberOf
krb_dump /user:dyork /service:krbtgt

4. Use only the selected TGT. The dump returns a sensitive encoded dyork ticket. Save the complete ticket to a protected dyork.kirbi on the attacker desktop, then follow the netonly make_token → kerberos_ticket_use → run klist pattern in 11. User Impersonation. Use dyork throughout; the older rsteel.kirbi example belongs to a different lab. Test only the authorized \\lon-dc-1\c$ resource. A successful ticket import is not proof of access.

[IO.File]::WriteAllBytes("C:\Users\Attacker\Desktop\dyork.kirbi", [Convert]::FromBase64String("<DYORK_TGT_BASE64>"))

make_token CONTOSO\dyork FakePass
kerberos_ticket_use C:\Users\Attacker\Desktop\dyork.kirbi
run klist
ls \\lon-dc-1\c$
rev2self

The placeholder is intentionally not a real ticket. Remove the exported file and the temporary ticket context after the lab. If no dyork TGT appears, do not claim delegation failed solely from that snapshot: the user may not have authenticated with delegation, the ticket may have expired, or protection may block forwarding. The separate Rubeus monitor /nowrap example observes new TGTs as they arrive; stop its job with jobs and jobkill <JID> when done. These commands and ticket values are lab- and version-dependent.

execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe monitor /nowrap
jobs
jobkill <JID>

Fork and run versus inline BOFs

The instructor's preference for krb_triage and krb_dump is about matching the command's footprint to the task, not a universal rule that inline is safer.

Decision rule: prefer the smallest installed command that answers the current question, confirm its exact implementation and output, and use fork and run when isolation or a different process context is necessary. A BOF is not invisible, and it does not gain permissions merely by being inline. Fortra describes the fork-and-run tradeoffs and BOF footprint and crash considerations.

Fact-check status

• Verified: KDC/TGT/service-ticket roles and the separate service authorization decision against Microsoft Kerberos documentation; fork-and-run and BOF process behavior against Fortra.
• Lab-specific: lon-ws-1$, rsteel, dyork, the expected Domain Admin membership, commands loaded by the course, and the permitted share result. These are expectations until observed in the current lab.
• Corrected: a delegation flag does not mean every past user TGT is cached; the old rsteel.kirbi block is not the dyork lab; the malformed Channels and Windows LDAP line is not valid filter syntax.

Review prompts

1. Which key protects a TGT, and which key lets the client use it?
2. Why can a KDC issue a service ticket even if the service later denies access?
3. Which evidence on lon-ws-1 would prove a usable dyork TGT is present?
4. When would a fork-and-run Rubeus job be preferable to a BOF despite its process footprint?
5. What must match in a ticket before testing \\lon-dc-1\c$?

This is a living study note. Sources and understanding may change as it is reviewed.