Kerberos authentication
Before explaining how these two attack techniques included in ZAIUX’s toolkit work, it is essential to understand how Kerberos authentication in an Active Directory environment work.
Within Active Directory, Kerberos protocol is responsible for the management of most authentications, both at user and services level. Unlike NTLM authentication, which works following a challenge-response principle, Kerberos authentication works on the basis of tickets.
Whenever a user logs in, it sends a request to the Domain Controller, which acts as “Key Distribution Center” (KDC). The initial authentication request, named AS_REQ, includes an encrypted timestamp, resulted from the current user name and its password. When the server receives the authentication request, it requests the user’s password hash and tries to decrypt the timestamp with it. If the decrypting process is successful, the authentication is considered as valid.
At this point, the service answers the client with an “Authentication Server Reply” (AS_REP), which includes an encrypted session-key with the user’s password, and a “Ticket Granting Ticket” (TGT).
Once the client has received the session-key and the TGT, the KDC considers the authentication completed and it will consider the TGT valid for 10 hours. During this time span, the user will not be asked to repeat its password.
Accessing a service
Another situation in which the KDC is involved is if the user tries to access a business resource, such as an Exchange Service, SQL or a network share with a registered Service Principal Name (SPN).
In this case the client will forge a Ticket Granting Service Request (TGS_REQ), which will once again include the current user, an encrypted timestamp, the SPN of the resource that would like to be accessed, and the encrypted TGT.
The KDC Server will receive the TGS_REQ request and if the SPN exists, it tries to decrypt the TGT, using a key, which is known only the KDC itself. If the decryption is successful, the session-key is extracted, which will be, in turn, used to decrypt the username and the timestamp. If the latter will result as valid, then the request will be accepted.
At this stage, the Ticket Granting Service will answer the client with a Ticket Granting Server Reply (TGS_REP), which is itself made of three parts:
- The SPN whose access is being requested;
- A Service-Ticket, which contains information on the user;
- The session-key, which shall be used between the client and the SPN.
Now the service authentication can begin.
First of all, the client sends an Application Request (AP_REQ), which contains the username and an encrypted timestamp with the session-key associated to the Service-Ticket. When the service receives the AP_REQ, it decrypts its ticket by extracting the session-key and the username. If the username corresponds, then the request is authorized.
Kerberos in an attack scenario
Now that Kerberos authentication has been understood, let’s see which security issues could be exploited by attackers to perform Privilege Escalation or Lateral Movement actions within an IT infrastructure.
KERBEROASTING
The Kerberoasting attack belongs to the post-exploitation phase, that is, the attacker has already access to the internal network and possesses a valid domain user, even with minimum privileges.
Through this technique, the attacker is able to request a TGS for a service, by specifying only its SPN. Active Directory will itself return an encrypted ticket, by using the NTLM hash of the account associated with the SPN. Now the attacker can extract the ticket from the memory and try to decrypt it offline, also through dictionary attacks, without risking to block the user.
To defend themselves from this attack type, one must make sure that the Service Accounts which use the SPN have long and complex passwords and, as far as possible, to change passwords regularly. It is also possible keep the unusual authentications monitored through adequate tools.
ASREP ROASTING
The AS-REP Roasting technique exploits the Kerberos protocol and, in particular, the user accounts which do not require any prior preauthentication. The preauthentication is, indeed, the first step of the Kerberos authentication and it has been developed to prevent brute force attacks; by default it is configured in an Active Directory environment. However, this step can be disabled for any user account, due to the compatibility with libraries which do not support the latest Kerberos versions.
Unlike Kerberoasting, it is not necessary to know the credentials of any user to exploit this vulnerability. A TGT request to the KDC for users which do not require preauthentication will be sufficient. After sending the AS_REQ to the KDC and getting the AS_REP in response, it is therefore possible to immediately extract the session-key, which, as said before, has been encrypted with the user’s password. Now, like for Kerberoasting, the attacker can try the hashcracking locally, without risking to block the mentioned user.
To mitigate this attack technique it is necessary to make sure that the preauthentication is enabled for all user accounts, and, in cases where it is mandatory to disable this step, it would be appropriate to use complex passwords and to change them continuously.
A Penetration Test allows you to validate the security of your network agains attacks targeting Kerberos, and thanks to ZAIUX® Evo’s automated and continuous approach it is now possible to autonomously execute frequent tests and keep a constant security level.