- \n
- 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.<\/li>\n\n\n\n
- 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.<\/li>\n\n\n\n
- 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.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- 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.<\/li>\n\n\n\n
- Kerberos provides a mechanism for clients and servers to establish an encrypted circuit in order to keep network communications private.<\/li>\n<\/ul>\n\n\n\n
As an attacker, we can identify the following interesting points.<\/p>\n\n\n\n
- \n
- Compromising a domain account that has access to services authenticated by Kerberos gives us practical control over the respective services and possibly their servers.<\/li>\n\n\n\n
- A user can have access to multiple services.<\/li>\n\n\n\n
- 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.<\/li>\n\n\n\n
- 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.<\/li>\n<\/ul>\n\n\n\n
Now, we’re gonna explore some known Kerberos vulnerabilities and\/or misconfigurations.<\/p>\n\n\n\n
SPN Tickets<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
We access the domain controller as domain administrator and run Powershell with administrative privileges.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-1024x640.png\")
<\/figure>\n\n\n\nWe’re going to use the “SetSPN” cmdlet.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-1-1024x658.png\")
<\/figure>\n\n\n\nWe 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. <\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-2-1024x647.png\")
<\/figure>\n\n\n\nThis 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”.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-3-1024x645.png\")
<\/figure>\n\n\n\nIn 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
It’s necessary to have a valid domain account to be able to query the tickets.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-4-1024x273.png\")
<\/figure>\n\n\n\nUsing 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.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-5-1024x251.png\")
<\/figure>\n\n\n\nNote: 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.<\/p>\n\n\n\n
Since usually the domain controller can also work as an NTP server, the command that does the trick is “sudo rdate -n IP-DC”<\/p>\n\n\n\n
Once the problem is solved, we get the respective TGS tickets, so we can proceed with the cracking process using “hashcat”.<\/p>\n\n\n\n
Using a common password dictionary, we crack the file (for this lab, we added the exact password to the rockyou.txt file).<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-9-1024x531.png\")
<\/figure>\n\n\n\nThe type of hash, defined by the parameter “-m”, is 13100, according to the documentation found in the next link:<\/p>\n\n\n\n
https:\/\/hashcat.net\/wiki\/doku.php?id=example_hashes<\/a><\/p>\n\n\n\n
We wait for a couple of seconds until the tool manages to crack the TGS ticket, obtaining the “Service_BD” account password.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-8-1024x564.png\")
<\/figure>\n\n\n\nJudging 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.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image_2022-06-06_003254461-1024x307.png\")
<\/figure>\n\n\n\nThis way, we confirm we have administrative access to the “DB01” server, so we can proceed with credential harvesting and lateral movement tasks.<\/p>\n\n\n\n
Note:<\/strong> 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:<\/p>\n\n\n\n
- \n
- Weak passwords.<\/li>\n\n\n\n
- The service user has excessive privileges over internal hosts.<\/li>\n\n\n\n
- There are registered SPN tickets associated with the domain admin and other privileged users.<\/li>\n<\/ul>\n\n\n\n
Disabled Kerberos Pre-authentication.<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
To configure this scenario in our laboratory, we can perform the following steps.<\/p>\n\n\n\n
We access the domain controller, the we go to the Active Directory users and computers utility.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-10-1024x608.png\")
<\/figure>\n\n\n\nWe select the account which we want to be vulnerable to this attack, in my case, “Service_BD”, then right and access the “Properties” tab.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-11-1024x836.png\")
<\/figure>\n\n\n\nMoving into the “Account” tab, we identify the “Do not require Kerberos preauthentication” checkbox and we enable it.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-12-1024x751.png\")
<\/figure>\n\n\n\nDuring 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.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-13-1024x421.png\")
<\/figure>\n\n\n\nAs 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”.<\/p>\n\n\n\n
With the knowledge of the vulnerable accounts, we continue with the exploitation using the “impacket suite”.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-14.png\")
<\/figure>\n\n\n\nBy 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.<\/p>\n\n\n\n
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”.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-16.png\")
<\/figure>\n\n\n\nWe execute “hashcat” to crack the obtained TGT.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-17-1024x407.png\")
<\/figure>\n\n\n\nAfter a couple of seconds, we get the password.<\/p>\n\n\n\n
![\"\"](\"https:\/\/jsec-rt.com\/wp-content\/uploads\/2022\/06\/image-18.png\")
<\/figure>\n\n\n\nFrom this point onward, we can continue with credential harvesting and lateral movement for domain escalation.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 As an attacker, we can Continue Reading<\/i><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[28,30],"class_list":["post-392","post","type-post","status-publish","format-standard","hentry","category-p-rt-en","tag-english","tag-rt"],"_links":{"self":[{"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/posts\/392","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/comments?post=392"}],"version-history":[{"count":2,"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/posts\/392\/revisions"}],"predecessor-version":[{"id":405,"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/posts\/392\/revisions\/405"}],"wp:attachment":[{"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/media?parent=392"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/categories?post=392"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jsec-rt.com\/index.php\/wp-json\/wp\/v2\/tags?post=392"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}