Kerberos is an authentication protocol that is used in Microsoft Windows in order to authenticate users. Oliver Kunz explained its basics in his Labs dated July 24th, 2014. In this Labs, I want to present two attacks against Kerberos that utilise vulnerabilities in the granting of tickets. In order to fully comprehend these attacks, it helps to understand how Kerberos grants tickets.

Granting a Kerberos Ticket

The process that Kerberos uses to grant a ticket can be summed up in five steps:

1. Authentication Service Request (AS-REQ): A client requests a Ticket Granting Ticket (TGT), asking the service Key Distribution Center (KDC). In the initial request, the UTC Timestamp is being encrypted using a Long Term Key (usually the password of the user). Upon Login, Windows generates Long Term Keys for the user using the following encryption algorithms. Interesting detail: the NTLM Hash is the same as the value of the RC4-HMAC Hash in Kerberos:
   • RC4-HMAC
   • AES128-CTS-HMAC-SHA1-96
   • AES256-CTS-HMAC-SHA1-96
2. Authentication Service Response (AS-REP): The request is being checked by the KDC, the decryption is done using the Long Term Key in the Active Directory (AD). If this check is successful, the KDC grants the TGT. This TGT has a limited validity and will be encrypted with the Long Term Key of the user krbtgt. The TGT contains, among other things, in the context of a Privilege Attribute Certificate (PAC) information about the identity of the user as well as their group affiliation.
3. Ticket-Granting Service Request (TGS-REQ): If the client accesses a resource like CIFS, RPC, Scheduler or WS-Man, to name a few, another request has to be made. The client requests another ticket called Ticket-Granting Service (TGS) at the KDC in order to access a random resource. This requests contain the TGT granted earlier as well as the name of the server that offers the resource.
4. Ticket-Granting Service Response (TGS-REP): The TGT sent in the request TGS-REQ is being decrypted by the KDC and the PAC information is being copied into the TGS grated for the service. The user receives this ticket and forwards it to a target server. The ticket is being encrypted with the Long Term Key of the target server.
5. Application Server Request (AP-REQ): The user forwards the ticket to the target server. This server decrypts the ticket and takes over the PAC information inside the ticket in order to check the access rights of the user. During this, the PAC information is being analysed without verifying them with the KDC again. This is to boost performance. If the check is successful, the client gains access to the resource.

An article written by security consultant Mike Pilkington describes the granting of tickets in great detail and points out weaknesses in the individual steps. Further information can be found in the article titled How the Kerberos Version 5 Authentication Protocol Works published on Microsoft’s TechNet.

Attack 1: MS14-068

On November 19, 2014, Microsoft published Security Bulletin MS14-068 outside their regular patchday cycle. The bulletin deals with a vulnerability in Kerberos that enables an attacker to elevate his rights until he gains the rank of domain administrator.

In a test environment I have recreated a possible attack scenario.

A user, his account is a member of the group Domain Users, tries to elevate his rights on a Windows 7 client that is integrated into the domain. The account doesn’t have local administrator rights. The attack can be carried out from outside the domain as Dave Kennedy, founder and CEO of Trustedsec has discovered and demonstrated step by step.

The attack he presents is based on the Python Kerberos Exploitation Kit. Using PyKEK the exploitation of the vulnerability leads to the granting of a Kerberos ticket that gives any domain user the rights of the following groups:

• Domain Users (RID 513)
• Domain Admins (RID 512)
• Schema Admins (RID 518)
• Enterprise Admins (RID 519)
• Group Policy Creator Owners (RID 520)

To do this, the attacker needs the following data:

• Username
• Password or NTLM hash
• Security Identifier (SID)

You can request your own SID using the command whoami/USER. The following example in PowerShell enables the attacker to request the SIDs of other users.

After gaining knowledge of the account’s SID, PyKEK can be run:

First, PyKEK runs the request AS-REQ, but requests – contrary to normal operation – a TGT without PAC. PyKEK takes the TGT of the KDC (see step AS-REP) and generates a PAC containing the listed group identifiers. The received TGT and the generated PAC are used as pieces making up TGS-REQ. The vulnerable KDC takes this information and grants a TGS that grants the account rights of a domain administrator. This TGS is being extracted into a file by PyKEK and can thus be re-used.

Using mimikatz the ticket is being loaded into an existing user session.

After importing the ticket, the account is a member of the group domain admin during the session and can thus access administrative sharing options of the domain controller.

As a countermeasure the patch MS14-068 by Microsoft should be installed immediately.

Attack 2: Golden Ticket

In the second attack scenario, we’re aiming to create a Golden Ticket, a Kerberos ticket that makes a user a member of the Domain Admins for ten years.

The attack is being carried out on a client that is integrated into the domain using a user account that doesn’t have local administrator privileges. The requirements for this attack are considerably higher than those of the first attack in this article. In order to create such a ticket, the NTLM hash of the account krbtgt needs to be known. The account krbtgt is being used to grant Kerberos tickets and is being created during the installation of an AD. An attacker can extract the NTLM hash – should his attack be successful – from a domain controller (using the hashdump) or from an unsecured backup. The password of the account krbtgt is usually set upon creation of the domain and is rarely ever changed. Therefore, an attacker can use a backup that is several years old.

Mimikatz is being used to generate the Golden Ticket. Needed for this attack are the following:

• NTLM hash of user krbtgt’s password
• Domain name
• Domain SID

The command kerberos::golden generates a Kerberos ticket that identifies an otherwise unprivileged account a member of several administrative groups. Using the available information, any ticket can be granted. Analogous to the first attack in this article, the account that gets outfitted with the Golden Ticket gains the rights of a Domain Admin and can access the sharing options of the domain controller.

The main countermeasure against the Golden Ticket attack is the protection of krbtgt’s credentials. The document Mitigating Service Account Credential Theft on Windows that was written in collaboration between HD Moore of Rapid7, Joe Bialek of Microsoft and Ashwath Murthy of Palo Alto Networks describes how the configuration of the domain controller can be hardened. Specific measures against the attack can be found in the document Protection from Kerberos Golden Ticket by CERT-EU. If the credentials of krbtgt have been compromised, the password of the account should be reset twice in order to make Golden Tickets that may or may not have been generated invalid. Microsoft published a blog post titled KRBTGT Account Password Reset Scripts now available for customers in which they included a script to change the password of krbtgt.

What are the Countermeasures?

Apart from the two attacks I described in detail there are more attacks against Kerberos. In the presentation Abusing Microsoft Kerberos that was held at the security conference black hat USA 2014 security researchers Alva “Skip” Duckwall and Benjamin Delpy (developer of mimikatz) have presented additional attacks.

To protect your infrastructure against the attacks, there are several counter measures:

• Install security updates as quickly as possible
• Harden configuration (deactivate RC4-HMAC algorithm support, among other things)
• Regularly change password of user krbtgt
• Monitor operations by targeted analysis of log data.

Using these methods, it’s a lot more difficult for an attacker to successfully attack Kerberos.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• http://blog.gentilkiwi.com/downloads/Abusing-Microsoft-Kerberos-Sorry-You-Guys-Don-t-Get-It.pdf
• http://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/
• http://cert.europa.eu/
• http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf
• http://digital-forensics.sans.org/blog/2014/11/24/kerberos-in-the-crosshairs-golden-tickets-silver-tickets-mitm-more
• http://technet.microsoft.com/en-us/library/cc772815%28v%3DWS.10%29.aspx
• http://www.scip.ch/?labs.20140724
• http://www.scip.ch/?vuldb.68239
• https://community.rapid7.com/docs/DOC-2881
• https://github.com/bidord/pykek/
• https://github.com/gentilkiwi/mimikatz
• https://technet.microsoft.com/library/security/MS14-068
• https://twitter.com/mikepilkington
• https://www.trustedsec.com/december-2014/ms14-068-full-compromise-step-step/