Kerberos Authentication Explained - and Why RC4 Is a Problem

I didn't know Active Directory, so it was obvious Kerberos wasn't going to be my strong point either. Before I could understand Kerberoasting or any attack built on top of it, I had to go deeper into the authentication protocol itself - and that's where I ran into a second problem on top of the first.

I found exactly one explanation online that actually made Kerberos click for me. It's good - genuinely good - but it's also dense enough that I can see it losing someone who isn't already halfway there. That's a pattern I run into a lot with technical topics: the good explanations assume you're already close to understanding the thing they're explaining. I think in logic and real-world examples, not acronyms and protocol diagrams, and when something doesn't map to a concrete scenario in my head, it doesn't actually stick - it just gets memorized until the next time I need it.

So this post is my attempt at the explanation I wish I'd found first. If you already know Kerberos cold, you probably won't need it. If you're where I was, I'm hoping it saves you the few hours I spent being quietly confused by acronyms that all start with the same three letters.

TL;DR for recruiters / hiring managers

• In plain English: Kerberos is how Windows domains prove who you are without ever sending your password across the network - it uses encrypted "tickets" instead.
• Why it matters here: Kerberoasting, the first attack in this series, specifically abuses a weak link in how one type of ticket gets encrypted.
• What I verified: I captured real Kerberos traffic in my own lab to confirm, rather than assume, which encryption types are actually in play - and found the answer wasn't what I expected going in.

The Amusement Park, Not the RFC

Here's the mental model that actually made this click for me: Kerberos authentication is a lot like a day at an amusement park with a wristband system.

You show up at the gate and prove who you are - a ticket purchase, ID checked. In exchange, you get a wristband. The wristband doesn't get you on any ride directly. What it does is prove, instantly and without re-checking your ID every time, that you're a paying guest who's allowed to be in the park.

Later, you walk up to a specific ride - say, the roller coaster - and show your wristband. The ride operator doesn't re-verify your identity from scratch. They trust the wristband, and in exchange, they hand you a ride ticket - something specific to that one ride, for that one visit. You hand the ride ticket to the person running the coaster, and you're on.

That's the whole shape of Kerberos, with the jargon mapped on:

• Proving who you are at the gate → the AS-REQ (Authentication Service Request) - you ask the Domain Controller's Key Distribution Center (KDC) to vouch for you.
• Getting the wristband → the AS-REP (Authentication Service Reply) - the KDC hands you a Ticket Granting Ticket (TGT). This is your wristband: proof you're a legitimate, authenticated user in the domain, good for a while.
• Walking up to a specific ride and showing your wristband → the TGS-REQ (Ticket Granting Service Request) - you present your TGT to ask for access to one specific service, like a file share or a SQL database.
• Getting the ride ticket → the TGS-REP (Ticket Granting Service Reply) - you receive a service ticket, specific to that one service, that you hand over to actually use it.

The reason this matters for security - and the reason Kerberos exists at all instead of "just send the password every time" - is that your password never leaves your machine during any of this. The KDC and your machine prove things to each other using cryptography derived from your password, not the password itself. That's a meaningfully different, much safer design than the password-over-the-wire model it replaced.

In my lab, this whole exchange happens between a workstation like WS-02 and DC-01, the domain controller running the KDC role for CORP.CHAKRAVYUH.LOCAL.

Why the Ticket's Encryption Is the Part That Actually Matters

Here's where the post's title comes in, and where the analogy needs one more detail: the wristband and the ride ticket aren't just pieces of paper - they're encrypted. And how they're encrypted is a choice, negotiated between your machine and the KDC, not a fixed property of Kerberos itself.

Two encryption types matter most in a modern Windows domain:

• RC4 (etype 23, 0x17) - an older algorithm. It's weaker, and critically, the key derived from it is based directly on the account's password hash - which means if an attacker gets hold of an RC4-encrypted ticket, they can attempt to crack it offline, at their own pace, with no further contact with the domain. No lockout policy helps you here, because the cracking attempt never touches the network.
• AES-128 / AES-256 (etype 17 / 18) - the modern standard. Significantly harder to crack offline, and the default preference in any reasonably current Windows domain.

Why does this matter practically? Because a ticket's encryption type is effectively decided per-account, not per-domain. If an account's msDS-SupportedEncryptionTypes attribute allows RC4 - whether because it was deliberately set that way, left unset on an older-style account, or just never touched - any ticket issued for that account can come back RC4-encrypted even in a domain where everything else uses AES.

That's not a hypothetical. I checked it directly in my own lab rather than assuming it from documentation.

What I Actually Found When I Checked

I wanted to see this for myself rather than take documentation at its word, so I captured it directly. A normal user logon's AS-REQ in my domain offers several encryption types, RC4 included - but DC-01 actually selects AES256 for the response. I checked whether that was something I'd configured: it wasn't. The account itself has no explicit encryption-type setting, and my domain's GPO baseline leaves the relevant Kerberos encryption policy at "Not Defined." At Windows2016Domain functional level, AES is simply what a modern domain and a modern client negotiate by default when both support it - RC4 gets offered mainly for backward compatibility, not because anything's forcing it.

That distinction - what's negotiated by default versus what has to be deliberately configured - turned out to matter a lot for one particular account in this lab, the one this series' first attack module is built around. That part of the story belongs in the Kerberoasting post itself, not here.

Why This Matters Beyond One Attack

Understanding this flow isn't just prep for one technique. For a SOC analyst, it reframes what an event like 4768 (AS-REQ/AS-REP) or 4769 (TGS-REQ/TGS-REP) actually represents in a log: not an abstract "authentication happened," but a specific step in a trust chain, with a specific encryption choice attached to it - a choice that's either a safe default or a quiet weakness, depending entirely on that one account's configuration.

That's also why "RC4 is still allowed" is rarely a domain-wide failure in a modern environment. It's almost always an account-by-account gap - a service account created years ago, never revisited, still accepting the weaker option while everything else around it moved on. Finding that gap is less about scanning the whole domain and more about knowing which accounts to actually check.

Next: The Attack Surface Most People Don't Even Think to Look For

Knowing how tickets work is half the picture. The other half is knowing what makes an account a target in the first place - and that comes down to one attribute most people never think to look at: the Service Principal Name.

That's where this series goes next.

Full series index: Series Link