~/tutorials/038-a-ticket-is-a-bearer-token.md

038: A ticket is a bearer token

The sentence is the whole lesson. In Kerberos, a granted ticket proves nothing about the person presenting it. Whoever holds it, is it. The same is true of a session cookie, an api key, and half the credentials in your lab.

How it got this shape

Kerberos was built so your password never crosses the wire. You prove knowledge of it once, to a trusted server, and receive tickets. Each ticket gets you into a service without the service ever learning your password.

Sound design with one consequence. The service checks the ticket, not the holder. From the service's side, a correct ticket presented by any process is you. The protocol succeeded at its goal, and the goal did not include telling a thief from an owner.

What this means in a domain

Three moves every domain assessment includes, all consequences of the bearer property.

Pass the ticket. Take a ticket from memory on one machine, present it from another. No password, no cracking, no communication with the domain controller. The ticket was valid wherever it came from.

Kerberoasting. Ask the domain controller for service tickets, which any authenticated user may do, and carry home the encrypted secret inside one. Crack it offline at leisure. The request was lawful, the answer was generous.

Golden ticket. With the domain's signing secret, forge anything. This is the end state of a compromise, and it is why that secret is the single most protected item in a healthy domain.

The same shape here, provable tonight

This site knows one session identity, and the shell answers it:

whoami

visitor (for now) is a bearer answer. The shell does not know it is you. It knows the session presented something, and the account page does the same with its cookie. One property, everywhere. The account session is a 256 bit random token in an HttpOnly cookie named l1_session, which is the same construction as a Kerberos ticket wearing web clothes.

The experiment that turns the property from a claim into a receipt needs two seats. Register an account in your browser, then present your cookie from somewhere that is not your browser: a second browser profile with the cookie set by hand from devtools, or one curl command. The account page answers the copy the same way it answers the original, because the page checks the token, not the holder. Ask the same page with no cookie at all and the identity is simply absent. Three answers: owner, thief, anonymous. The middle one is the whole lesson in one row.

Why this lesson is here and not in a tooling chapter

Because the defense follows from the property, not from any tool. Tickets expire: keep lifetimes short. Tickets are bearer: protect the memory they live in, and a reboot or relogon invalidates what a thief took. Service secrets crack offline: make them long enough that offline is not enough. And a password change that leaves old sessions standing has not evicted anyone: this site's own code kills every session an account holds on reset, for the reason in its comment, that keeping an attacker's session alive is not a reset but a second key under the mat.

Every hardening line above is an argument with a design that mostly won. Kerberos is good. Bearer is what it is. Know which parts of your day depend on the second fact.

Try it

1. Run the three seat experiment on this site: register, present your cookie from a second seat, present nothing. Write down which answers differ and why the thief's answer matches the owner's.
2. In your lab, build the smallest domain that runs. The build is the apparatus page the guest and the domain. Two VMs, one controller.
3. Pull a ticket the honest way and look inside it. On the domain member, after login:

$ klist
$ klist -e -f

The flags line is where the bearer property shows its paperwork: forwardable, renewable, forwardable to whom. A ticket you can read is a ticket you can think about stealing.

1. Run one Kerberoast against your own service account with a weak password, then change that password to something a GPU respects, and run it again. The difference in crack time is the entire argument.

$ GetUserSPNs.py -request -dc-ip 192.168.56.10 lab.local/user
$ hashcat -m 13100 ticket.txt wordlist.txt