many enterprise IT departments these days are afraid of golden ticket or pass the ticket attacks -which is good because privilege escalation and privileged account exploitation are at the center of cyber attacks as we see them. Attackers crash through the network perimeter, hijack credentials and use them to move laterally throughout the network, taking additional credentials and escalating privileges along the way to accomplish their goals. In this blog series we will have a look at kerberos golden ticket and silver ticket attacks. I’ll try my best to explain how it works and how Azure ATP / Advanced Threat Analytics can help to detect.
This post is the first part of another blog series that is coming up. It will deal with:
- Azure ATP: Golden Ticket Attack – Understanding Kerberos
- Azure ATP: Golden Ticket Attack – How golden ticket attacks work
- Azure ATP: Golden Ticket Attack – Detect and recover from a compromised Active Directory
During my research for a customer documentation I bumped into some really good articles about the concept behind kerberos and mitigation best practices which I’ll list at the very end of each article. The risk behind kerberos attacks was summarized pretty good in an article of cyberark from 2015.
Kerberos attacks have been identified as one of the most dangerous attack techniques at the RSA Conference 2015, Kerberos attacks are troublesome for three primary reasons:
- Access: Once an attacker has Local Admin privileges, it is possible to dump additional credentials, which if left behind in the compromised machines, enable the attacker to move laterally in the network, elevate privileges and gain unauthorized access to valuable assets
- Obscurity: To bypass security controls and evade detection, an attacker can reuse Kerberos tickets to impersonate authorized users and sidestep authentication processes – disguising activity and avoiding authentication log traces.
- Persistence: The days of stolen data being dumped all at once are largely over – attackers often prefer to remain on the network undiscovered for extended periods of time, funneling information out little –by – little. Kerberos attacks give attackers what they need most to do this: time. It is possible to maintain persistence with Kerberos tickets, even when credentials have been changed.
Just to make sure that everybody is aware of what we are talking about: Kerberos is a pretty old technique which was implemented into Microsoft technology with the release of Windows 2000 Active Directory. It is a computer network authentication protocol that works on the base of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol is called Kerberos based on the three- headed dog figure from Greek mythology. The three heads of Kerberos comprise the Key Disitrbution Center (KDC), the client user and server with the desired service to access. The Key Distribution Center is installed as part of the domain controller and basically performs the two service functions:
- the Authentication Service (AS)
- the Ticket Granting Service (TGS)
If you want to read more about both of them. Check out the docs.microsoft.com article called: Kerberos Explained
In a nutshell Kerberos works like this:
- User logs on with Active Directory user name and password to a domain-joined computer and provides both to Authentication Service (AS)
- The user requests authentication by sending a timestamp (Pre-auth data) encrypted with the users password-based encryption key (password hash).
- User account (firstname.lastname@example.org) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos AS-REQ).
- The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP) if the data is correct.
- This TGT can be (re-)used for any further requests within its validity without urging the user to re-enter the username and password again.
here is another good illustration of the process that I’ve found here:
A more detailed explanation of Kerberos:
Kerberos differs from username/password authentication methods because instead of authenticating each user to each network service, it uses symmetric encryption and a trusted third party — known as the Key Distribution Center (KDC) — to authenticate users to a suite of network services. Once a user authenticates to the KDC, it sends a ticket specific to that session back the user’s machine and any kerberized services look for the ticket on the user’s machine rather than asking the user to authenticate using a password.
- So when a user logs in to his workstation, their principal is sent to the KDC in a request for a Ticket-granting Ticket (TGT) from the Authentication Server (AS).
- The KDC checks for the principal in its database. If the principal is found, the KDC creates a TGT, which is encrypted using the user’s key and returned to that user.
- The login on the client machine then decrypts the TGT using the user’s key (which it computes from the user’s password). The user’s key is used only on the client machine and is not sent over the network.
- The TGT is set to expire after a certain period of time (usually ten hours) and stored in the client machine’s credentials cache. An expiration time is set so that a compromised TGT is of use to an attacker for only a short period of time. Once the TGT is issued, the user does not have to re-enter their password until the TGT expires or they logout and login again.
- Whenever the user needs access to a network service, the client software uses the TGT to request a new ticket for that specific service from the Ticket-granting Server (TGS). The service ticket is then used to authenticate the user to that service transparently.
As mentioned before the concept about the Kerberos tickets is that two different principals have to agree that it’s legit. On the one hand we have the krbtgt User Account which’s NT hash is used and on the other hand we have the encrypted NTLM hash of the principal requesting the ticket.
In essence, each side of the conversation has some assurance that the other side is who they claim to be since “in theory” the only way the TGT could be valid is that both sides can read their part. And here comes the weakness that is used for a golden ticket attack: because the NT hash of the krbtgt account is that important, it obviously rarely changes it’s password. This would affect the hash which is used for every kerberized service and would lead into all Kerberos tickets being invalid.
An easy way to check when your krbtgt account password has last been changed is the following command:
net user krbtgt /domain
Above you can see that the password hasn’t changed for more than two years in that domain. Which is independent of the domain password policy by the way.
The three scenario’s where it would change it’s password are
- a domain functional level change (NT5 to NT6 for example)
- a bare metal recovery
- a manual change of the KDC service account password (krbtgt account).
Kerberos can use a variety of cipher algorithms to protect data. A Kerberos encryption type (also known as an enctype) is a specific combination of a cipher algorithm with an integrity algorithm to provide both confidentiality and integrity to data. If you want to find out more about the different encryption types, check out this blogpost: Windows Configurations for Kerberos Supported Encryption Type
In general you need to know the following:
|KERBEROS ENCTYPE NAME(S)||CIPHER ALGORITHM||CIPHER MODE||KEY LENGTH||HMAC||STRENGTH|
|aes256-cts||AES||CBC+CTS||256 bits||SHA-1 96-bits||strongest|
|aes128-cts||AES||CBC+CTS||128 bits||SHA-1 96-bits||strong|
|rc4-hmac||RC4||128 bits||SHA-1 96-bits||weak|
|des3-cbc-sha1||3DES||CBC||168 bits||SHA-1 96-bits||weak|
|des-cbc-crc||DES||CBC||56 bits||CRC 32-bit||weakest|
Here is good slide from Benjamin Delpy on a presentation he did years ago. It helps to understand the different scenarios.
Check out the next post in this series to find out how an attacker would run a Golden Ticket attack.