Generated Wednesday, October 7, 2026 · Depth: deep · RC4 deprecation details checked against Microsoft's KB5073381 support article for CVE-2026-20833.

Kerberos, from the ground up

Plain English first

When you log in to a Windows network in the morning, you type your password once. After that you open file shares, intranet sites and databases all day without typing it again. Kerberos is the system that makes that work.

It works by handing out tickets. You prove who you are once to a trusted server, the KDC, which runs on every DC. It gives you a master ticket, the TGT. Whenever you want to use a specific service, you show the TGT to the KDC and get a ticket just for that service. You then present that service ticket to the service. Your password never travels across the network.

The catch: every ticket is locked with a key made from someone's password. The TGT is locked with a key only the KDC knows. A service ticket is locked with the key of whatever account runs that service. If that account has a weak password, anyone who holds the ticket can try to guess the password offline, as fast as their hardware allows. That is the core of this whole page.

The analogy: a theme park wristband

Why it matters now

If you remember only 5 things

1. Tickets, not passwords, cross the network. But every ticket is encrypted with a key derived from some account's password, so tickets carry crackable material.
2. Any authenticated user can get a service ticket for any SPN. The KDC does not check whether you may use the service. That design choice is what makes Kerberoasting possible.
3. Risk equals crackability times privilege. A weak, human-set password on an account that is a Domain Admin is critical. A random 120-character computer account password is not a realistic target.
4. AES-only is not the fix by itself. It slows cracking by orders of magnitude, but a password like "Summer2024!" still falls. Accounts still explicitly allowed RC4 remain fast targets.
5. Detect on DCs, fix at the account. Watch events 4768, 4769 and 4771 plus honey SPNs. Fix with gMSA or long random passwords, AES, pre-auth on, and least privilege.

Core concepts

Thirteen ideas, each building on the one before. Open "Go deeper" for the expert-level detail.

Visual map

Step through the normal exchange, then watch how each roasting attack bends it. Pick a flow, then use Next.

Kerberos compared with NTLM

Encryption types you will see

Kerberoasting compared with AS-REP roasting

Who owns the SPN decides the risk

TechnicalUnder the hood

Components

• KDC service (kdc, runs inside LSASS on each DC). It contains the AS and the TGS logically, but on Windows they are one service on one port.
• The AD database, which stores each principal's long-term keys. There is one key per supported etype, generated whenever the password is set.
• krbtgt, a disabled user account whose key encrypts and signs every TGT in the domain. It is the most sensitive secret in AD (Part 2).
• Client Kerberos package in LSA on every Windows machine. It requests, caches and presents tickets. You can view the cache with klist.
• Services (SMB, HTTP, SQL Server and others). They decrypt tickets with their own key and read the PAC to decide what you may do.

Message by message: who encrypts what with which key

Notice the pattern. The client never decrypts a ticket. It decrypts the encrypted part addressed to it, which holds the session key, and passes tickets along as sealed blobs.

Keys and salts

• RC4 key = NT hash = MD4 over the UTF-16LE password. No salt and no iterations, so the same password gives the same key in every domain. Cracking is extremely fast on GPUs.
• AES keys are derived with PBKDF2-HMAC-SHA1, 4,096 iterations. The salt is the uppercase realm plus the principal name. For users that is CORP.EXAMPLE.COMsvc_sql; computers use a host-based salt. Each guess costs thousands of hash operations, so cracking is far slower, but it is still feasible against weak passwords.
• Keys are created at password set. An account whose password last changed before the domain supported AES (2008 DFL) has no AES keys at all. Force AES-only on it and authentication breaks until the password is reset.
• KVNO increments on each password change. A ticket encrypted with an old KVNO fails with KRB_AP_ERR_MODIFIED or a related error until the client gets a new ticket.

How the ticket's encryption type is chosen (simplified)

1. The client lists the etypes it supports in the request.
2. The KDC looks at the target account's msDS-SupportedEncryptionTypes. If the attribute is blank, it uses the DC's default (DefaultDomainSupportedEncTypes), which is AES-SHA1 only (0x18) on DCs that have the April 2026 or later updates.
3. It picks the strongest etype that the target supports and for which it holds a key. The session key etype is chosen separately and can differ from the ticket etype.
4. Historically, a tool could advertise only RC4 and get an RC4 ticket for any account without explicit settings. That is the "downgrade" every Kerberoasting tool relied on. After enforcement, it only works where RC4 is explicitly allowed on the target account or in the DC default.

msDS-SupportedEncryptionTypes bit flags

The 2026 RC4 change, precisely

Registry location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Event 205 is logged at each KDC start if the DC default still allows insecure ciphers. Microsoft says explicit admin configuration is always honored, so explicit RC4 exceptions stay roastable with RC4. Check the patch level of every DC; a single unpatched DC keeps the old behavior for requests it serves.

Defaults worth knowing cold

Tradeoffs and limitations

• Strong dependence on time and DNS. Clock skew over 5 minutes, or a name that doesn't map to an SPN, breaks Kerberos. Windows then often falls back silently to NTLM.
• Tickets are bearer tokens for their lifetime. Revoking an account doesn't kill tickets already issued (Part 2).
• The KDC doesn't authorize. It authenticates and attaches group data. Each service decides access, so ticket issuance is not access control.
• Offline exposure is designed in. Every ticket is ciphertext under a password-derived key. The protocol assumes those keys are strong.

Common misconceptions

Troubleshooting quick reference

klist                         # show cached tickets and their etypes
klist get MSSQLSvc/sql01.corp.example.com:1433   # request one ticket
klist purge                   # clear the cache
setspn -L svc_sql             # list SPNs on an account
setspn -Q MSSQLSvc/*          # find who owns matching SPNs
setspn -X                     # find duplicate SPNs

AttackerAttacker's view

These are the attacks that come straight from the protocol design. They are covered at the level needed to test for them on an authorized engagement, explain them, and write them up. Ticket theft and forgery are in Part 2, and delegation abuse is in Part 3.

How these chain on a real internal test

1. Get a foothold: one phished or sprayed user account.
2. Enumerate with LDAP: users with SPNs, accounts without pre-auth, group memberships. BloodHound shows which roastable accounts have paths to Tier 0.
3. Roast selectively. Start with accounts that have privileged paths, and check whether RC4 is still allowed (Rubeus.exe kerberoast /stats shows supported etypes without requesting tickets).
4. Crack offline with a wordlist and rules tuned to the client's naming patterns.
5. Use the recovered credential, then document the path end to end.

DefenderDefender's playbook

Written for the sysadmins who will do the work. The goal: no service account that a human chose a password for, no RC4 where it isn't required, no account without pre-auth, and alerts that fire on the few events that matter.

Quick wins (days)

1. Inventory every user account that has an SPN. Note its privileges, password age and etypes.

   Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName,PasswordLastSet,msDS-SupportedEncryptionTypes,MemberOf,AdminCount |
     Select Name,PasswordLastSet,msDS-SupportedEncryptionTypes,AdminCount,ServicePrincipalName

2. Remove privileged group membership from service accounts (Domain Admins, Enterprise Admins, Administrators, Account Operators). This is often the single biggest severity reducer.
3. Remove stale SPNs from user accounts that no longer run a service: setspn -D <SPN> <account>.
4. Reset remaining service account passwords to 25 or more random characters. Use a password manager or vault. Length is common practitioner guidance; longer is better since nobody types it.
5. Turn pre-auth back on for every account that has it disabled.

   Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' | Select Name
   Set-ADAccountControl -Identity svc_legacy -DoesNotRequirePreAuth $false

6. Enable the right auditing on DCs: Advanced Audit Policy, Account Logon, "Audit Kerberos Authentication Service" and "Audit Kerberos Service Ticket Operations," both Success and Failure.
7. Create one or two honey SPN accounts. Give each a realistic name and SPN, a long random password, no rights, and an alert on any 4769 for it.

Longer-term fixes (weeks to months)

1. Move services to gMSAs. AD generates and rotates the password. Requires a KDS root key once per forest.

   Add-KdsRootKey -EffectiveImmediately   # then allow time to replicate (up to 10 hours)
   New-ADServiceAccount -Name gmsa_sql -DNSHostName gmsa_sql.corp.example.com `
     -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers"
   # on the SQL host:
   Install-ADServiceAccount gmsa_sql ; Test-ADServiceAccount gmsa_sql

   Restrict who can read the managed password (the PrincipalsAllowedToRetrieveManagedPassword group). Reading it is an attack path in its own right.
2. Finish the RC4 retirement. Set msDS-SupportedEncryptionTypes to 24 (0x18) on service accounts so the setting is explicit, then reset the password so AES keys exist.

   Set-ADUser svc_sql -Replace @{'msDS-SupportedEncryptionTypes'=24}
   # reset the password afterward if it predates AES support

   Configure the GPO "Network security: Configure encryption types allowed for Kerberos" to AES128, AES256 and future types once Kdcsvc events 201 to 209 are quiet.
3. Use a fine-grained password policy for remaining human-managed service accounts, with a long minimum length.
4. Tier the accounts. A service account that touches Tier 0 is Tier 0. Restrict where it can log on.
5. Consider dMSA on Windows Server 2025 for migrations. Note: in 2025, researchers published "BadSuccessor," showing that dMSA migration features could be abused to escalate privileges in some configurations. Patch, and restrict who can create dMSA objects or write to the relevant attributes before adopting it.
6. Feed DC logs to the SIEM, or deploy MDI or a similar identity detection product.

Detection signals

# Splunk-style idea: many distinct SPNs from one requester in 10 minutes
index=dc EventCode=4769 Service_Name!="*$" Service_Name!="krbtgt"
| bin _time span=10m
| stats dc(Service_Name) as spns values(Ticket_Encryption_Type) by _time, Account_Name, Client_Address
| where spns > 10

Verify the fix worked

1. Request a ticket for the SPN and check the etype: klist get <SPN> then klist. You should see AES-256-CTS-HMAC-SHA1-96. On the DC, the 4769 should show 0x12.
2. Confirm PasswordLastSet is after the finding date, and the account is no longer in privileged groups.
3. For gMSAs, run Test-ADServiceAccount on the host and confirm the service runs as the gMSA.
4. Ask the testers to re-roast. Run the original wordlist and rules against the new ticket for a fixed time budget; it should not crack.
5. Trigger the honey SPN from a test machine and confirm the alert fires end to end.

Why remediation stalls, and workable compromises

ExecutiveExecutive brief

The risk in plain language

Our network uses Kerberos to let staff log in once and reach everything they need. Behind the scenes, many business systems run under "service accounts," which are logins that programs use rather than people. Some of those accounts have passwords people chose years ago and never changed.

Any employee login, including one stolen by a phishing email, can be used to collect scrambled copies of those service account passwords. The attacker takes them away and guesses at them on their own computers, where we can't see it and nothing locks them out. If one of those accounts has broad administrative access, the attacker can take control of the entire network.

Business impact

• Full control of the Windows environment: the precondition for ransomware deployment across the company and for large-scale data theft.
• Access to the specific systems the service account runs, such as finance databases or backup servers.
• Very little warning. The guessing happens outside our network.

What drives likelihood

• Low barrier. It needs only one ordinary login, and the tools are free and well known.
• Old, weak passwords on service accounts that nobody owns.
• Too much privilege on those accounts.
• Legacy encryption still allowed for some systems. Microsoft turned it off by default in 2026 updates, but exceptions remain.

Cost of inaction

The fix is mostly staff time: inventory, password changes, and moving services to accounts Windows manages automatically. Not fixing it leaves a path from a single phished employee to company-wide compromise. That's the path behind many ransomware incidents, where recovery, downtime and disclosure costs are far larger than the remediation effort.

What good looks like

• Every service account has an owner, and none has a password a person chose.
• Most services run on automatically managed accounts (gMSA) with long passwords that rotate themselves.
• No service account holds top-level administrator rights.
• Legacy encryption is off, with a short, documented list of exceptions and end dates.
• Monitoring raises an alert when someone collects these tickets, including a decoy account that only an attacker would touch.

Questions executives ask

Presenting this finding to leadership

1. Headline in one sentence: "From one ordinary employee login, we reached full administrative control in under a day, using a weakness in how service account passwords are managed."
2. The path, as a short story: stolen login, collected encrypted ticket, password guessed offline, administrator access. Three or four steps, no jargon.
3. Impact tied to their business: name the system the account controlled, such as payroll, backups or the domain.
4. The fix, with owner and timeline: quick wins this month, managed accounts this quarter.
5. The ask: an owner for service accounts, a change window, and confirmation that monitoring is in scope.

Talk the talk

Jargon decoder

Smart questions to ask

Sysadmins

• Who owns each service account, and where is its password stored?
• Which service accounts are in privileged groups, and what rights do they actually use?
• Are all DCs on the July 2026 or later updates? Have you reviewed Kdcsvc events 201 to 209?
• Which accounts have msDS-SupportedEncryptionTypes explicitly allowing RC4, and why?
• Do you have a KDS root key, and what's blocking gMSA adoption?
• Are 4768, 4769 and 4771 collected from every DC and retained long enough to investigate?

Executives

• Who is accountable for service accounts today?
• If an employee's login were stolen tomorrow, how would we know, and how fast?
• Which business systems would we least want an attacker to control? We'll check which accounts reach them.

Coworkers

• Does this engagement include detection testing? Should we roast broadly or selectively?
• Is RC4 still possible for any targets, or are we cracking AES this time? That changes our time budget.
• Any honey accounts we know about from previous tests?

Say this, not that

Same point, two audiences

Acronyms

Every acronym used on this page. Four test modes are below the table.

Test yourself

Flashcards

Quiz

Fifteen questions, mostly scenarios. Feedback appears as soon as you choose.

Conversation drills

Say or type your answer first, then compare with the sample.

Export cards

Basic cards (Quizlet and Anki Basic)

Standard flashcards, acronym cards, and cloze cards turned into "sentence with ____" fronts. Tab separates front and back; one card per line.

• Quizlet: Create a set, choose Import, paste, set "Between term and definition" to Tab and "Between cards" to New line.
• Anki: Paste into a .txt file, then File, Import, choose the Basic note type with Tab as the field separator.

Anki cloze cards

Uses Anki's {{c1::answer}} syntax. Quizlet doesn't support cloze.

• Anki: Paste into a .txt file, then File, Import, choose the Cloze note type; the whole line maps to the Text field.

Keep going

What to learn next, in order

1. Part 2 of this series: ticket theft and forgery. Pass-the-ticket, overpass-the-hash, golden, silver, diamond and sapphire tickets, krbtgt rotation, and the PAC signature changes from 2022 onward.
2. Part 3: delegation and trust. Unconstrained, constrained and resource-based constrained delegation, S4U, referrals across trusts, Protected Users, and FAST armoring.
3. AD attack paths as graphs. Learn to read BloodHound output so you can explain why a roastable account matters.
4. NTLM, relay and coercion. The other half of Windows authentication, and where Kerberos fallback sends you.
5. Active Directory Certificate Services abuse. Certificates become Kerberos tickets through PKINIT, which is a whole attack surface of its own.
6. AD tiering and privileged access design. The strategic fix that makes every finding above smaller.

Resources worth seeking out

• Specifications: RFC 4120 (Kerberos V5), RFC 3961 and 3962 (encryption framework and AES), RFC 4757 (RC4-HMAC), RFC 8009 (AES with SHA-2), and Microsoft's open specifications [MS-KILE] and [MS-PAC].
• Microsoft Learn and Support: "Detect and remediate RC4 usage in Kerberos" and KB5073381 for the 2026 RC4 changes; the Kerberos Policy and audit policy reference pages.
• MITRE ATT&CK pages for T1558.003 and T1558.004, including the detection and mitigation sections.
• Background reading: "Designing an Authentication System: a Dialogue in Four Scenes" (Bill Bryant, MIT, 1988) is still the best plain-English introduction to why Kerberos looks the way it does.
• Offensive origins: Tim Medin's 2014 DerbyCon talk that introduced Kerberoasting, and Will Schroeder's (harmj0y) blog posts on Kerberoasting and Rubeus.
• Tool documentation: the Rubeus (GhostPack) and Impacket READMEs on GitHub; Sean Metcalf's ADSecurity.org for defender-oriented AD articles.
• Hands-on labs: build a small AD lab, or use Orange Cyberdefense's GOAD project. Run each attack, then find its trace in the DC logs.
• Courses: on O'Reilly, Pluralsight or Udemy, look for Active Directory attack and defense courses that include a lab component.