Port 88, the KDC, and the world's most bureaucratic ticket-issuing system, explained before we start breaking it.
"Every Active Directory box eventually makes you say the word 'TGT' out loud to an empty room like it's a normal thing to do."
Okay so here's the thing nobody tells you before you start messing with Active Directory: half the attacks aren't really hacking, they're just understanding a 30 year old ticketing system well enough to abuse its own rules. Before Kerberoasting, before AS-REP Roasting, before you get to feel like a hacker in a movie, you gotta sit through the boring part. So let's get the boring part out of the way, but make it fun. Deal? Deal.
me trying to keep track of AS, TGS, and AP in my head during the exam
Imagine every single service on the network needed to personally know your username and password. Change your password? Now fifteen services are mad at you. Get your account disabled? Now fourteen of those fifteen services didn't get the memo and still let you in. Total chaos, nobody's happy, IT quits.
So instead, Windows domains do the sensible thing and appoint ONE authority everybody trusts: the KDC, the Key Distribution Center. Every user, every computer, every service trusts the KDC and only the KDC. Nobody else ever sees your actual password. They just see tickets the KDC has vouched for, like a bouncer checking a wristband instead of asking for your ID every five minutes.
Kerberos, aka Cerberus, is the three headed dog guarding the gates of the underworld in Greek myth. Souls get in, but nothing sketchy gets back out unchecked. Microsoft looked at that and said "yeah that's basically our auth protocol" and named it accordingly. Three heads, three ticket exchanges. It checks out disturbingly well.
The TGT (Ticket Granting Ticket) is basically your ID card for the domain. Username, account creation date, security info, group memberships, all of it lives in there. By default it's only good for a few hours, and you have to show it literally every time you want to talk to the KDC again. No TGT, no service, simple as that.
Here's the part that actually matters: every account has a secret key derived from its password, and the KDC knows every single one of them. That's the whole trust model in one sentence. Two things get built from this:
the TGT getting sealed so hard even the user who owns it can't peek inside
And tucked inside all of this is a little thing called the session key, which basically exists in two copies at once: one sealed inside the TGT where only the KDC can see it, and one sealed separately with the user's own key so the user can actually use it too. Same key, two locks, nobody can cheat.
The whole dance, start to finish, looks like this:
User authenticates → KDC
KDC issues → TGT (to the user)
User presents TGT → KDC
KDC issues → TGS ticket (to the user)
User presents TGS ticket → Service
Service says → "alright, come in"Every single thing Kerberos does boils down to one of three message exchanges. Learn these three and you basically understand the whole protocol, no cap.
the user and the KDC, forever passing tickets back and forth like it's a relationship
First move: the user asks for a TGT. To prove they actually know their password without ever sending the password itself, they send an authenticator, just the current timestamp, encrypted with their own key. Username rides along in cleartext so the KDC knows whose lock to try.
If the KDC decrypts it fine, meaning the user really does hold the right key, it fires back AS-REP with two things: the TGT itself, and a copy of the session key sealed just for the user.
Pro tip that becomes very relevant later: if pre-authentication is disabled on an account, the KDC skips checking the authenticator entirely and just hands the TGT over to whoever asked. That one setting is the entire premise of AS-REP Roasting. Filing that away for future us.
Now the user wants an actual service, so they send TGS-REQ carrying three things: the service's name (its SPN, written like SERVICE/HOST), the TGT from gate one, and a fresh authenticator encrypted with the session key this time.
Kerberos is stateless, the KDC has zero memory of anything that happened five seconds ago, so it decrypts the TGT fresh, re-verifies everything, and issues a service ticket containing the service name, a copy of the user's info, and a copy of the session key sealed with the service's own key.
Last step, and the easy one: the user hands that service ticket directly to the service. The service decrypts it with its own key, reads who's asking, and decides whether to let them in. No KDC involved at this point, the ticket already did all the talking.
Because every juicy AD attack you'll run into is just one of these three gates being abused instead of used properly:
Same three gates. Same three exchanges. The only thing that changes is intent. That's basically the whole plot twist of Active Directory security: the attacks aren't some separate exotic thing bolted on top, they're just the protocol being used exactly as designed, by someone the design didn't account for.
that's the whole ticketing system, no skips, no "part two" cliffhanger, all in one sitting.
go forth and roast responsibly.