An important part of the authentication mechanisms and protocols used by Active Directory is Kerberos, which in short, establishes a secure authentication channel between trusted hosts on an untrusted network.
Some of the objectives of a Kerberos authentication process are listed in the following section
- Passwords are not transmitted over the network.
- Passwords are not stored on client operating systems and must be discarded immediately after use.
- Passwords are not stored in clear text, even on authentication servers.
- A password is entered only once per session, similar to an SSO (Single Sign-on) process, since it requires authentication of a user only once, allowing access to the resources authorized for that user.
- All authentication information is centralized in an authentication server. Application servers do not store any authentication information, allowing the following features to be implemented:
- An administrator can disable authorization for a user on any application server from the centralized authentication server. Access to individual servers is not required to revoke authorization.
- A user’s password is sufficient to access all services authenticated by Kerberos. A user can reset his pass only once, regardless of the number of services he is authenticated to.
- Protection of user information is simplified since all authentication information is located on a centralized server instead of multiple servers where the user has access.
- All parties, users and application servers, must authenticate each other when required. Users authenticate when logging in, application services can be configured to request authentication to the client.
- Kerberos provides a mechanism for clients and servers to establish an encrypted circuit in order to keep network communications private.
As an attacker, we can identify the following interesting points.
- Compromising a domain account that has access to services authenticated by Kerberos gives us practical control over the respective services and possibly their servers.
- A user can have access to multiple services.
- It is possible that the accounts used are service accounts, so there is a possibility that the passwords used have not been changed in a long time or are of low complexity.
- They are a different protocol, so it is possible that monitoring processes on authentication attempts in the active directory are not monitoring authentications by Kerberos.
Now, we’re gonna explore some known Kerberos vulnerabilities and/or misconfigurations.
SPN Tickets
Service Principal Name (SPN), is a unique identifier of an instance of a specific service. They are used by Kerberos authentication to associate a service instance with a service domain account.
Using the Active Directory test environment we set up in a previous post, we will generate SPN tickets for 2 different users and then from a Kali machine we will query for them and perform the cracking process.
We access the domain controller as domain administrator and run Powershell with administrative privileges.
We’re going to use the “SetSPN” cmdlet.
We have multiple options, all of them with the proper documentation, for our exercise, we’re going to use the flag “-A”, that will allow us to set up a new ticket belonging to an internal user.
This way, we have a SPN ticket created for the “Administrator” user, now we’re going to create another one for a new domain user called “Service_BD”.
In the screenshot an error was obtained when executing the command “Duplicate SPN Found, aborting operation!”, this is because an attempt was made to create a new SPN for a service instance that already has an SPN assigned, since SPN tickets associate a service instance to a service domain account, a new ticket cannot be defined, it would be as if we were telling the domain that a single session is being initiated in the service with two different users. For simplicity purposes, we assigned the ticket to a service in a different port.
Now, we can use the impacket suite to obtain these tickets and the corresponding hashes, that can be cracked offline, revealing service accounts passwords, in case they’re weak.
It’s necessary to have a valid domain account to be able to query the tickets.
Using a low privilege account, we obtain the list of registered tickets, for the user “Administrator” and “Service_BD”, however, we do not observe any encrypted value that we can save in a text file and then try to crack, to request the value of the respective ticket we add the parameter “-request” to the command used.
Note: If you get a message like “clock_skew_too_great” whenever you try to run the command, you must synchronize the attacker host time with the domain controller time.
Since usually the domain controller can also work as an NTP server, the command that does the trick is “sudo rdate -n IP-DC”
Once the problem is solved, we get the respective TGS tickets, so we can proceed with the cracking process using “hashcat”.
Using a common password dictionary, we crack the file (for this lab, we added the exact password to the rockyou.txt file).
The type of hash, defined by the parameter “-m”, is 13100, according to the documentation found in the next link:
https://hashcat.net/wiki/doku.php?id=example_hashes
We wait for a couple of seconds until the tool manages to crack the TGS ticket, obtaining the “Service_BD” account password.
Judging by the name and the SPN ticket information, the account is most likely associated with a database, so we can validate our access to one of the live servers we found during recon.
This way, we confirm we have administrative access to the “DB01” server, so we can proceed with credential harvesting and lateral movement tasks.
Note: The capability to query for the registered SPN tickets using a low privileged account is not considered a vulnerability, since it’s the normal Active Directory behaviour. The associated vulnerabilities are:
- Weak passwords.
- The service user has excessive privileges over internal hosts.
- There are registered SPN tickets associated with the domain admin and other privileged users.
Disabled Kerberos Pre-authentication.
There is the possibility of configuring the Kerberos service so that, for a specific account, pre-authentication is not required before generating the TGS for the respective user. If this were the case, an attacker could request a user’s ticket without needing to know his password, and then try to crack it, potentially gaining control over the respective account.
To configure this scenario in our laboratory, we can perform the following steps.
We access the domain controller, the we go to the Active Directory users and computers utility.
We select the account which we want to be vulnerable to this attack, in my case, “Service_BD”, then right and access the “Properties” tab.
Moving into the “Account” tab, we identify the “Do not require Kerberos preauthentication” checkbox and we enable it.
During a pentest, we can obtain a list of all the users that have this flag set and therefore are vulnerable to AS-REP roasting by exploring the “ldapdomaindump” tool results.
As an example, the image shows a previous Active Directory dump, where we can find the property “DONT_REQ_PREAUTH” on the “Flags” tab for the users “jseclow” y “jsec”.
With the knowledge of the vulnerable accounts, we continue with the exploitation using the “impacket suite”.
By doing this, we’ll get asked for the users’s password, however, we can just hit enter and we’ll still get the TGT because of the set flag.
For the “jsec” and “jseclow” users, the password is expired, so we can’t use these accounts, since we won’t get the TGT, however, for the “Service_BD” account, we got the hash, so we’re going to crack it using “hashcat”.
To identify which hash type value we need to use, we can analyze the help menu and grep for REP, to identify the correct value for an AS-REP roasting.
We execute “hashcat” to crack the obtained TGT.
After a couple of seconds, we get the password.
From this point onward, we can continue with credential harvesting and lateral movement for domain escalation.
These are some common attacks that I found pretty successful on a lot of corporate environments, using dictionary and ruleset cracking, where I add new possible passwords associated to the specific entity I’m evaluating.
The second part of this post will be mostly focused on lateral movement and post exploitation techniques, such as Pass-the-ticket and Golden tickets usage for persistence.