Kerberos attacks explained 
….somewhat 
By Peter Swedin
Easy authentication
• The user Alice logs on 
to her domain joined 
client. 
• Alice then accesses the 
intranet. 
• User is greeted with 
”Welcome Alice!” 
without authenticating 
to the web service. 
• Kerberos SSO!
The handshake
Challenges 
• KDC validation 
• Replay attacks 
• Downgrade attacks 
• Pass-the-ticket attacks
MitM 
• An Attacker can trick the client into believing 
he is the KDC during the AS negotiation 
• But in order to create the Service Ticket the 
attacker has to know the shared secret 
between the client and the KDC…
The problem with AS_REQ 
• During password authentication, AS_REQ is 
encrypted with a key derived from the 
password. 
• Most of AS_REQ is sent in the clear (without 
server validation), making it possible for man-in- 
the middle attacks
The problem with ERR PREAUTH 
REQUIRED 
• A phony KDC can ask the client to use a weak 
encryption algorithm (downgrade etype attack) 
• DES and Windows ”export grade” RC4 are 
vulnerable to brute-forcing and dictionary attacks 
• The MITM attacker can manipulate the seed 
making the key easier to crack
Platforms vulnerable to etype 
downgrade attacks 
• MIT Kerberos v1.7 and below will accept any 
form of DES 
• Windows 2008 / Vista and prior will accept 
any form of DES
MitM 
• When a client computer joins the domain, 
there is no need for a Service Ticket 
The attacker can own the client and its 
identity by acting as a proxy between the real 
KDC and the client
Smart card Kerberos auth in pre- 
Windows 2008R2 domains is 
vulnerable to MiTM attacks 
• Windows clients will not check the DC 
certificate for the EKU (Enhanced Key Usage) 
id-pkinit-PKPKdc, unless told to do so. 
• For whatever reason the Server 
Authentication EKU is considered enough, 
making every client with a computer 
certificate a possible MiTM platform.
Pass-the-Ticket Attack 
The Attack 
The Pass-the-Ticket attack enables an attacker to 
authenticate to a Windows server using the 
Kerberos "ticket granting ticket" of a user recently 
logged into the domain. 
After previously compromising and gaining 
privileged access to a computer logged into the 
domain, the attacker extracts the Kerberos ticket 
granting ticket and uses it to access all servers the 
victim is authorized to access.
Pass-the-Ticket Attack Tools 
• Tools for the attack include: 
• Windows Credentials Editor (WCE), 
• KDE Replay, 
• Corelab Pass-the-Hash Toolkit, SMBShell 
• Mimikatz
The Golden Ticket 
• Using pass-the-ticket or pass-the-hash, gain 
Domain administrator privileges 
• Obtain the NTLM hash from the krbtgt user 
from a pre-2008R2 Domain Controller 
• Use Mimikatz to produce fake TGT for any 
user (even non existing users will work) 
• Pwnd
Risk asessment – Kerberos attacks 
Popularity Low 
Ease of Implementation Medium/easy 
Impact high 
Remotely Exploitable Yes 
Risk High
Hardening Microsoft Kerberos 
• Use ONLY Windows 2012R2 Domain Controllers 
• Use AES 256 
• Disallow etype downgrade 
• Use Kerberos KDC certificates (requires a 2008 R2 
Certificate Authority or later) 
• Enable the GPO ”Require strict KDC validation” 
• Only allow clients to join the domain from a 
separate, secure network segment
Pass-the-Ticket Defenses 
Very hard to detect, since it is a valid protocol 
doing valid things 
Change KRBTGT password, TWICE 
Upgrade to 2012R2 on ALL DCs 
Or apply patch KB 2871997 
(A SIEM solution may be able to determine that the 
ticket granting ticket is being used inappropriately).
Questions?

Golden ticket, pass the ticket mi tm kerberos attacks explained

  • 1.
    Kerberos attacks explained ….somewhat By Peter Swedin
  • 2.
  • 3.
    • The userAlice logs on to her domain joined client. • Alice then accesses the intranet. • User is greeted with ”Welcome Alice!” without authenticating to the web service. • Kerberos SSO!
  • 4.
  • 5.
    Challenges • KDCvalidation • Replay attacks • Downgrade attacks • Pass-the-ticket attacks
  • 6.
    MitM • AnAttacker can trick the client into believing he is the KDC during the AS negotiation • But in order to create the Service Ticket the attacker has to know the shared secret between the client and the KDC…
  • 7.
    The problem withAS_REQ • During password authentication, AS_REQ is encrypted with a key derived from the password. • Most of AS_REQ is sent in the clear (without server validation), making it possible for man-in- the middle attacks
  • 8.
    The problem withERR PREAUTH REQUIRED • A phony KDC can ask the client to use a weak encryption algorithm (downgrade etype attack) • DES and Windows ”export grade” RC4 are vulnerable to brute-forcing and dictionary attacks • The MITM attacker can manipulate the seed making the key easier to crack
  • 9.
    Platforms vulnerable toetype downgrade attacks • MIT Kerberos v1.7 and below will accept any form of DES • Windows 2008 / Vista and prior will accept any form of DES
  • 10.
    MitM • Whena client computer joins the domain, there is no need for a Service Ticket The attacker can own the client and its identity by acting as a proxy between the real KDC and the client
  • 11.
    Smart card Kerberosauth in pre- Windows 2008R2 domains is vulnerable to MiTM attacks • Windows clients will not check the DC certificate for the EKU (Enhanced Key Usage) id-pkinit-PKPKdc, unless told to do so. • For whatever reason the Server Authentication EKU is considered enough, making every client with a computer certificate a possible MiTM platform.
  • 12.
    Pass-the-Ticket Attack TheAttack The Pass-the-Ticket attack enables an attacker to authenticate to a Windows server using the Kerberos "ticket granting ticket" of a user recently logged into the domain. After previously compromising and gaining privileged access to a computer logged into the domain, the attacker extracts the Kerberos ticket granting ticket and uses it to access all servers the victim is authorized to access.
  • 13.
    Pass-the-Ticket Attack Tools • Tools for the attack include: • Windows Credentials Editor (WCE), • KDE Replay, • Corelab Pass-the-Hash Toolkit, SMBShell • Mimikatz
  • 14.
    The Golden Ticket • Using pass-the-ticket or pass-the-hash, gain Domain administrator privileges • Obtain the NTLM hash from the krbtgt user from a pre-2008R2 Domain Controller • Use Mimikatz to produce fake TGT for any user (even non existing users will work) • Pwnd
  • 16.
    Risk asessment –Kerberos attacks Popularity Low Ease of Implementation Medium/easy Impact high Remotely Exploitable Yes Risk High
  • 17.
    Hardening Microsoft Kerberos • Use ONLY Windows 2012R2 Domain Controllers • Use AES 256 • Disallow etype downgrade • Use Kerberos KDC certificates (requires a 2008 R2 Certificate Authority or later) • Enable the GPO ”Require strict KDC validation” • Only allow clients to join the domain from a separate, secure network segment
  • 18.
    Pass-the-Ticket Defenses Veryhard to detect, since it is a valid protocol doing valid things Change KRBTGT password, TWICE Upgrade to 2012R2 on ALL DCs Or apply patch KB 2871997 (A SIEM solution may be able to determine that the ticket granting ticket is being used inappropriately).
  • 19.

Editor's Notes

  • #22 1. Alice’s attempt to logon with a smart card (PKINIT AS-REQ) is intercepted by Ivan. 2. Ivan sends an AS-REP, with a TGT key, back to Alice, encrypted with her public key. The client principal of the AS- REP and TGT is not set to Alice’s identity, but to Connie’s. (the encryption notation of the AS-REP in the diagram has been simplified for clarity) 3. Alice accepts Ivan’s AS-REP, and makes a TGS-REQ for Wally, to complete her logon. 4. Ivan asks Connie for credentials to Wally. 5. Connie makes an AS-REQ to Bob. 6. Bob gives Connie a TGT. 7. Connie makes a TGS-REQ for Wally. 8. Bob gives Connie his TGS-REP for Wally. 9. Connie decrypts the TGS-REP and sends its contents (Connie’s copy of the session key, and Connie’s ticket to Wally) to Ivan. 10. Ivan forms a TGS-REP for Alice containing the session key received from Connie, and Connie’s ticket to Wally (as originally issued by Bob). 11. Alice receives the TGS-REP. She can decode and extract the session key and ticket. She forms an authenticator and makes an AP-REQ to Wally. 12. Wally decrypts the ticket, validates the authenticator (formed with the same session key in the ticket) and PAC checksum (created by Bob), and creates a logon session for Connie.