Create a directory on the Desktop with the machine's name, and inside this directory, create another directory to store the materials and outputs needed to run the machine.
suecho"10.10.68.235 CONTROLLER.local">>/etc/hostsmkdir-pthm/AD/ADKcdthm/AD/ADKmkdir{nmap,content,exploits,scripts}# At the end of the room# To clean up the last line from the /etc/hosts filesed-i'$ d'/etc/hosts
The target machine is reachable using SSH or RDP protocols.
What is Kerberos?
Kerberos is the default authentication service for Microsoft Windows domains. It is intended to be more "secure" than NTLM by using third party ticket authorization as well as stronger encryption. Even though NTLM has a lot more attack vectors to choose from Kerberos still has a handful of underlying vulnerabilities just like NTLM that we can use 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 orde
Kerberos Authentication Overview
AS-REQ - 1.) The client requests an Authentication Ticket or Ticket Granting Ticket (TGT).
AS-REP - 2.) The Key Distribution Center verifies the client and sends back an encrypted TGT.
TGS-REQ - 3.) 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 - 4.) The Key Distribution Center (KDC) verifies the TGT of the user and that the user has access to the service, then sends a valid session key for the service to the client.
Kerberos Tickets Overview
The main ticket you will receive is a ticket-granting ticket (TGT). These can come in various forms, such as a .kirbi for Rubeus and .ccache for Impacket. A ticket is typically base64 encoded and can be used for multiple attacks.
The ticket-granting ticket is only used to get service tickets from the KDC. When requesting a TGT from the KDC, the user will authenticate with their credentials to the KDC and request a ticket. The server will validate the credentials, create a TGT and encrypt it using the krbtgt key. The encrypted TGT and a session key will be sent to the user.
When the user needs to request a service ticket, they will send the TGT and the session key to the KDC, along with the service principal name (SPN) of the service they wish to access. The KDC will validate the TGT and session key. If they are correct, the KDC will grant the user a service ticket, which can be used to authenticate to the corresponding service.
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
Download Kerbrute and make it executable using chmod +x kerbrute_linux_amd64
[] Ticket cache size: 4 [] Sleeping until 6/28/2025 9:28:05 AM (30 seconds) for next display
To find the administrator ticket as well, you need to disable Windows Defender completely
Brute-Forcing / Password-Spraying w/ Rubeus
Rubeus can both brute force passwords as well as password spray user accounts.
Psw-Spraying attack will take a given Kerberos-based password and spray it against all found users and give a .kirbi ticket. This ticket is a TGT that can be used in order to get service tickets from the KDC as well as to be used in attacks like the pass the ticket attack.
Before password spraying with Rubeus, you need to add the domain controller domain name to the windows host file. You can add the IP and domain name to the hosts file from the machine by using the echo command
3.1 - Which domain admin do we get a ticket for when harvesting tickets?
Administrator
3.2 - Which domain controller do we get a ticket for when harvesting tickets?
CONTROLLER-1
Task 4 - Kerberoasting w/ Rubeus & Impacket
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 success of the attack depends on how strong the password is and if it is trackable as well as the privileges of the cracked service account. To enumerate Kerberoastable accounts I would suggest a tool like BloodHound to find all Kerberoastable accounts, it will allow you to 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. That is a bit out of scope for this room but it is a great tool for finding accounts to target.
in this case, we can copy only the SQL Service hash (we'll do the same for HTTP Service using another technique) into the attacker machine and put it into a .txt file so we can crack it with hashcat
in this case, we can copy only the HTTP Service hash (because SQL Service was already done using the other technique) into the attacker machine and put it into a .txt file so we can crack it with hashcat
THM provide us a modified rockyou wordlist in order to speed up the process download it here
hashcat -m 13100 -a 0 hash.txt pass.txt
Summer2020
Kerberoasting Mitigation
Strong Service Passwords - If the service account passwords are strong then kerberoasting will be ineffective
Don't Make Service Accounts Domain Admins - Service accounts don't need to be domain admins, kerberoasting won't be as effective if you don't make service accounts domain admins.
Task 5 - AS-REP Roasting w/ Rubeus
Very similar to Kerberoasting, AS-REP Roasting dumps the krbasrep5 hashes of user accounts that have Kerberos pre-authentication disabled. Unlike Kerberoasting these users do not have to be service accounts the only requirement to be able to AS-REP roast a user is the user must have pre-authentication disabled.
in this case we need to specify the parameter 18200 and the same wordlist as the previous task:
hashcat -m 18200 -a 0 hash.txt pass.txt
5.1 - What hash type does AS-REP Roasting use?
Kerberos 5 AS-REP etype 23
5.2 - Which User is vulnerable to AS-REP Roasting?
User3
5.3 - What is the User's Password?
Password3
5.4 - Which Admin is vulnerable to AS-REP Roasting?
Admin2
5.5 - What is the Admin's Password?
P@$$W0rd2
Task 6 - Pass the Ticket w/ mimikatz
Pass the Ticket Overview
Pass the ticket works by dumping the TGT from the LSASS memory of the machine. The Local Security Authority Subsystem Service (LSASS) is a memory process that stores credentials on an active directory server and can store Kerberos ticket along with other credential types to act as the gatekeeper and accept or reject the credentials provided. You can dump the Kerberos Tickets from the LSASS memory just like you can dump hashes. When you dump the tickets with mimikatz it will give us a .kirbi ticket which can be used to gain domain admin if a domain admin ticket is in the LSASS memory. This attack is great for privilege escalation and lateral movement if there are unsecured domain service 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 to act as that domain admin. You can think of a pass the ticket attack like reusing an existing ticket were not creating or destroying any tickets here were simply reusing an existing ticket from another user on the domain and impersonating that ticket.
Prepare Mimikatz & Dump Tickets
We can run mimikatz.exe, assure that the output of privilege::debug is '20' OK mimikatz.exe - run mimikatz
mimikatz.exe
privilege::debug
Now we need to export the .kirbi tickets into the directory that you are currently in
sekurlsa::tickets /export
Pass the Ticket w/ Mimikatz
Now, we need to choose an administrator ticket from the krbtgt for impersonification step and cache it to impersonate administrator:
Using klist command we're able to verify that we successfully impersonated the ticket.
Task 7 - Golden/Silver Ticket Attacks w/ mimikatz
KRBTGT Overview
A KRBTGT is the service account for the KDC this is the Key Distribution Center that issues all of the tickets to the clients. If you impersonate this account and create a golden ticket form 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 from like the SQLService ticket.
Golden/Silver Ticket Attack Overview -
A golden ticket attack works by dumping the ticket-granting ticket of any user on the domain this would preferably be a domain admin however for a golden ticket you would dump the krbtgt ticket and for a silver ticket, you would dump any service or domain admin ticket. This will provide you with the service/domain admin account's SID or security identifier that is a unique identifier for each user account, as well as the NTLM hash. You then use these details inside of a mimikatz golden ticket attack in order to create a TGT that impersonates the given service account information.
Dump the krbtgt hash
We need to dump the hash as well as the security identifier needed to create a Golden Ticket.
To create a silver ticket is necessary to change the /name: to 'krbtgt' and dump the hash of either a domain admin account or a service account such as the SQLService account.
cd Downloads
mimikatz.exe
privilege::debug
lsadump::lsa /inject /name:krbtgt
Create a Golden/Silver Ticket
Starting to the following command base: Kerberos::golden /user:Administrator /domain:controller.local /sid: /krbtgt: /id:
to create a golden ticket we need to put a service NTLM hash into the krbtgt slot, the sid of the service account into sid, and change the id to 1103.
and spawn a new shell with new privileges usugin: misc::cmd command.
7.1 - What is the SQLService NTLM Hash?
We can check all NTLM hash executing lsadump::lsa /patch
cd40c9ed96265531b21fc5b1dafcfb0a
7.2 - What is the Administrator NTLM Hash?
2777b7fec870e04dda00cd7260f7bee6
Task 8 - Kerberos Backdoors w/ mimikatz
Along with maintaining access using golden and silver tickets mimikatz has one other trick up its sleeves 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 a master password.
The Kerberos backdoor works by implanting a skeleton key that abuses the way that the 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"
This will only be an overview section and will not require you to do anything on the machine however I encourage you to continue yourself and add other machines and test using skeleton keys with mimikatz.
Skeleton Key Overview
The skeleton key works by abusing the AS-REQ encrypted timestamps as I said above, the timestamp is encrypted with the users NT hash. The domain controller then tries to decrypt this timestamp with the users NT hash, once a skeleton key is implanted the domain controller tries to decrypt the timestamp using both the user NT hash and the skeleton key NT hash allowing you access to the domain forest.
Installing the Skeleton Key w/ mimikatz
cd Downloads && mimikatz.exe
privilege::debug
misc::skeleton
It permits to access the forest and the default credentials will be: "mimikatz".
example: net use c:\\DOMAIN-CONTROLLER\admin$ /user:Administrator mimikatz - The share will now be accessible without the need for the Administrators password
example: dir \\Desktop-1\c$ /user:Machine1 mimikatz
