Kerberos Pre Authentication Attack
This is a continuation of the previous notes on Kerberos attacks. If you haven't read the previous chapter, I recommend doing so first to gain a better understanding of what Kerberos is.
Last updated
This is a continuation of the previous notes on Kerberos attacks. If you haven't read the previous chapter, I recommend doing so first to gain a better understanding of what Kerberos is.
Last updated
In Kerberos pre-authentication attacks, the primary objective is to obtain valid usernames and crack passwords. The acquired information can be leveraged to establish a foothold within the target system or to exploit other vulnerabilities within the Active Directory environment. By successfully compromising user credentials, an attacker can potentially escalate privileges, gain unauthorized access to sensitive resources, or pivot to launch further attacks.
Before diving deep into the actual attack we have to know about the kerberos pre-authentication process because we didn't discuss that in detail in the previous chapter. Previously we only discussed the kerberos generally but now for the sake of this attack, we have to discuss it more deeply.
In Kerberos Authentication the user first initiates the authentication request to the key distribution center (KDC) or Authentication Server. The first initial request is denoted by AS-REQ. In AS-REQ they send the username and the timestamp to get the Ticket Granting ticket (TGT).
Note: If the Pre Authentication signing is enabled that is enabled in most cases, then the user first has to send the timestamp that is encrypted with the user's password hash (NT Hash). This helps to prevent tampering or replay attacks.
To learn about pre-authentication attacks, it is important to have a detailed understanding of the Ticket Granting Ticket (TGT). Although we are aware that the TGT is utilized to request Service Tickets (ST), delving into the specifics of the TGT is crucial in the context of pre-authentication attacks.
The TGT initial Request (AS-REQ) contains the following structure.
Ticket Version Number: Indicates the version of the AS-REP format.
Client Realm: Specifies the realm or domain to which the client belongs.
Client Principal Name: Identifies the client's principal, typically in the form of a username or a user principal name (UPN).
Ticket: Contains the TGT (Ticket Granting Ticket) for the client, encrypted using the client's password or the Key Distribution Center's (KDC) secret key. The TGT includes information such as the client's identity, network address, and session key.
Ticket Expiration Time: Specifies the time at which the TGT expires and is no longer valid.
Server Realm: Specifies the realm or domain of the Key Distribution Center (KDC).
Server Principal Name: Identifies the KDC server's principal name.
Encrypted Part: Contains additional encrypted data, including the client's session key encrypted with the client's password or the KDC's secret key.
If you capture the AS-REQ in the network capture tools like wireshark you will see this type of structure.
In the Kerberos AS-REP message, the Encrypted Part contains two session keys, each encrypted with a different secret key. This is done to support mutual authentication and secure communication between the client and the Key Distribution Center (KDC).
One of the session keys is encrypted using the client's secret. The client's secret can be derived from the client's password or other means. This encrypted session key allows the client to authenticate itself to the KDC in subsequent Ticket Granting Service (TGS) requests.
The other session key is encrypted using the KDC's secret key. This encrypted session key ensures secure communication between the client and the KDC.
By having two session keys, the Kerberos protocol enables the client to establish a secure connection with the KDC and authenticate itself while maintaining the confidentiality and integrity of the communication.
For more information, I recommend reading to RFC of Kerberos to better understand the structure of TGT and I also recommend this video that I also watched to learn about.
In this scenario, we focus on a specific attack called AS-REQ or pre-authentication password brute force attack. In this attack, we aim to capture network traffic containing a user's AS-REQ request. During this request, the user sends an encrypted timestamp to the Key Distribution Center (KDC) as proof of their identity. This encrypted timestamp is generated using the user's password hash. Our objective is to crack this ciphertext using tools like Hashcat and JohnTheRipper. By successfully cracking the encrypted timestamp, we can obtain the user's password and potentially gain unauthorized access to their account or other sensitive information.
To capture the network traffic and identify the relevant packets for our analysis, we can utilize a tool like Wireshark. By filtering the results based on kerberos packets, we can narrow down our focus to the Kerberos-related traffic. Once we identify the AS-REQ request packets from the users, we can extract the associated cipher field. This cipher field contains the encrypted ciphertext that we are interested in for further analysis and potential cracking attempts using appropriate tools.
In the provided screenshot, we observe an AS-REQ request where the user sends the encrypted timestamp in the form of ciphertext to the Key Distribution Center (KDC). We can extract this ciphertext from the packet capture and proceed with cracking it using specialized tools such as Hashcat or JohnTheRipper. In this demonstration, we will utilize hashcat for the cracking process. However, those who are interested can also explore the option of using JohnTheRipper as an alternative tool for this purpose.
The Hashcat command syntax to crack that cipher text are following.
Where:
/usr/share/wordlists/rockyou.txt is the wordlist of passwords.
-m flag is used to specify the hash mode, you can get this information using the hashcat with -h options or also by viewing the hashcat example hashes site.
Note: The above site contains all the hash modes for different hash types and also contains the example hash. For this attack the mode is
19900and that is because we are dealing withetype (18)as you can see in the above screenshot, but if your instance uses another type of encryption then you have to use a relative option according to that.
The Next thing you should be aware of is to match the hash format with the example hash format in the screenshot above.
Example
The success of password cracking relies entirely on the strength and complexity of the password itself. If a password is weak and susceptible to cracking, we can exploit this vulnerability and obtain the corresponding credentials. With these compromised credentials, we can launch further attacks within the target environment. It is crucial to emphasize the importance of using strong and complex passwords to mitigate the risk of unauthorized access and potential security breaches.
In this case, this password is very weak and we crack it in less than a minute.
Note: In this command I stored the hash in the file name
hash.txtand pass that as an argument.
This attack can be performed in many other methods and I just show you one way to perform this attack but I recommend interesting readers to research other ways to perform this attack and share your thought about it in your network. If you like then you can tag me also on Twitter so I can also share it.
The other attack I will highlight has an unrealistic scenario in which kerberos pre-authentication is disabled which means users doesn't have to send encrypted timestamp to verify themselves. Why I'm saying it is unrealistic because, in the real world, it doesn't make sense that someone disable pre-authentication but I could be wrong.
If any account is disabled pre-authentication then we can request TGT for that user and KDC will send the TGT that contains the session key encrypted with the user password hash as we discussed above.
After we get the encrypted cipher text from TGT then again we can try to crack that cipher text to get the user's password.
For this attack, there is a very useful Python script in Impacket suite named GetNPusers.py that allows us to identify any users in the Active Directory environment whose pre-authentication is disabled. Additionally, it retrieves their Ticket Granting Ticket (TGT) and displays the encrypted cipher text associated with it. This cipher text can be subjected to cracking attempts in order to obtain the password.
The syntax for the GetNpUser.py script is the following.
Example
The above command will only show you which user has pre-authentication disabled but if you use it with the -request option they also get its cipher text from TGT like the following.
Now we can pass this cipher to tools like Hashcat and JohnTheRipper to crack the password. Using the hashcat the command will like the following.
For this scenario, we need to use the hashcat module 18200 since we are working with the AS-REP response, unlike the previous time when we dealt with AS-REQ. You can find more information about this mode on the Hashcat example hashes website.
![[AS-REP HASH cat example.png]]
This script can perform other stuff also but at this time I just showed one use case.
Another type of attack that can be performed on Kerberos is AS-REQ user enumeration. However, it is important to note that this attack generates a significant amount of network noise. The attack involves sending numerous incorrect requests, which can easily be detected by a Security Operations Center (SOC) team or intrusion detection systems.
If you are conducting penetration testing where detection is not a primary concern, you may consider using this attack to gather information about user accounts. However, in red team engagements or scenarios where remaining undetected is crucial, it is advisable to avoid using this attack.
Let's delve into the details of this attack. During the Kerberos pre-authentication process, the user initiates the authentication by sending their username and timestamp to the Key Distribution Center (KDC). If the KDC is configured with pre-authentication signing enabled, it will respond with an error message: KRB5KDC_ERR_PREAUTH_REQUIRED. This error message indicates that the user needs to send the timestamp encrypted with their password to the KDC, as discussed in the previous attack.
However, if the username provided in the request is incorrect, the KDC will return a different error message: KDC_ERR_C_PRINCIPAL_UNKNOWN. This error signifies that the principal or username specified in the request is not recognized or does not exist within the Kerberos realm.
We can determine whether a user exists or not by looking at the KDC's response when sending an authentication request (AS-REQ). This enables us to effectively carry out a bruteforce attack on usernames using wordlists. Another attack that is related to this is called AS-REP roasting, which allows us to discover user accounts with disabled pre-authentication. We will discuss this attack in more detail in a later section.
Performing this attack may result in the account being locked out. So you should also be careful about that.
The tool we can use for this attack is called Kerbrute and you can download it from this link. The syntax to perform this attack using Kerbrute are following.
Output
As mentioned earlier, this attack involves generating a significant number of incorrect requests in the network, which can raise detection concerns. This attack vector is primarily used to confirm the validity of usernames obtained through OSINT recon or other means. It is often employed when you have a list of potential employee names and want to verify if they are valid or not.
