Kerberosting / AS-REP Rosting
Last updated
Last updated
The process of cracking Kerberos service tickets and rewriting them in order to gain access to the targeted service is called Kerberoast. This is very common attack in red team engagements since it doesn’t require any interaction with the service as legitimate active directory access can be used to request and export the service ticket which can be cracked offline in order to retrieve the plain-text password of the service. This is because service tickets are encrypted with the hash (NTLM) of the service account so any domain user can dump hashes from services without the need to get a shell into the system that is running the service.
Red Teams usually attempt to crack tickets which have higher possibility to be configured with a weak password. Successful cracking of the ticket will not only give access to the service but sometimes it can lead to full domain compromise as often services might run under the context of an elevated account. These tickets can be identified by considering a number of factors such as:
SPNs bind to domain user accounts
Password last set
Password expiration
Last logon
Specifically the Kerberoast attack involves five steps:
SPN Discovery
Request Service Tickets
Export Service Tickets
Crack Service Tickets
Rewrite Service Tickets & RAM Injection
The discovery of services in a network by querying the Active Directory for service principal names.
Services that support Kerberos authentication require to have a Service Principal Name (SPN) associated to point users to the appropriate resource for connection. Discovery of SPNs inside an internal network is performed via LDAP queries and can assist red teams to identify hosts that are running important services such as Terminal, Exchange, Microsoft SQL etc. and being stealthy at the same time. Furthermore identification of SPNs is the first step to the kerberoasting attack.
SetSPN is a native windows binary which can be used to retrieve the mapping between user accounts and services. This utility can add, delete or view SPN registrations.
Services that are bind to a domain user account and not a computer account are more likely configured with a weak password since the user has selected the password. Therefore services which they have their Canonical-Name to Users should be targeted for Kerberoasting. From the list of SPNs below the service sql.megabank.local is associated with a user account.
kerberost toolkit can be used to query the active directory to discover only services that are associated with a user account as a more focused approached compared to SetSPN.
There is also a VBS script which is part of the same tookit and can provide the same information. The script can be executed from the windows command prompt by using the native Windows binary cscript.
Service Principal Names can be also discovered from non-joined domain systems with the python version of GetUserSPNs which is part of impacket. However valid domain credentials are required for communication with the Active Directory as token based authentication cannot be used.
Targeted kerberoasting by setting SPN - We need have ACL write permissions to set UserAccountControl flags for the target user, see above for identification of interesting ACLs. Using PowerView:
Get the hash for a roastable user (see above for hunting). Using ASREPRoast.ps1:
Crack the hash with Hashcat:
Targeted AS-REP roasting by disabling Kerberos pre-authentication - Again, we need ACL write permissions to set UserAccountControl flags for the target user. Using PowerView:
The easiest method to request the service ticket for a specific SPN is through PowerShell as it has been introduced by Tim Medin during his DerbyCon 4.0 talk.
Execution of the klist command will list all the available cached tickets.
An alternative solution to request service tickets is through Mimikatz by specifying as a target the service principal name.
Similarly to klist the list of Kerberos tickets that exist in memory can be retrieved through Mimikatz and save the output to a file:
Note that the service ticket file is binary. Keep this in mind when transferring it with a tool like Netcat, which may mangle it during transfer.
then we can use kerberost tool in kali to crack the service account ticket:
Alternatively loading the Kiwi module (meterpreter) will add some additional Mimikatz commands which can performed the same task.
Or by executing a custom Kiwi command:
Impacket has a python module which can request Kerberos service tickets that belong to domain users only which should be easier to cracked compared to computer accounts service tickets. However requires valid domain credentials in order to interact with the Active Directory since it will executed from a system that is not part of a domain
The service account hashes will also retrieved in John the Ripper format or this hashcat command:
Make user appear to be a different user
Add user to another group (in this case Domain Admin)
Kerberos tickets are signed with the NTLM hash of the password. If the ticket hash has been cracked then it is possible to rewrite the ticket with Kerberoast python script. This tactic will allow to impersonate any domain user or a fake account when the service is going to be accessed. Additionally privilege escalation is also possible as the user can be added into an elevated group such as Domain Admins.
The new ticket can be injected back into the memory with the following Mimikatz command in order to perform authentication with the targeted service via Kerberos protocol.
