> For the complete documentation index, see [llms.txt](https://officerwasu.gitbook.io/officerwasu-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://officerwasu.gitbook.io/officerwasu-docs/untitled/windows-attacks/kerberoasting.md). # Kerberoasting Kerberoasting is a post-exploitation technique used to extract account password hashes from Active Directory for offline cracking. Unlike AS-REP Roasting in which we target users with pre-authentication disabled Kerberoasting can be used against any domain user account that has a Service Principal Name (SPN) set. Because any authenticated domain user can request a service ticket for any service in the forest this is one of the most common ways to move from a standard user to a high privileged service account (like a SQL service or a backup admin). #### What is an SPN? A Service Principal Name (SPN) is a unique identifier for a service instance. Think of it as an address for Kerberos. If our user wants to use a service (like SQL or a Web Server) Kerberos needs to know which account is running that service so it can encrypt the ticket with the right key. In Active Directory if you link a service to a login account (User or Computer) using an SPN. The format usually looks like `ServiceClass/HostName:Port/ServiceName` There are two main types of SPNs: 1. Host-based SPN: These are the most common types of SPN. They are automatically mapped to Computer Accounts. When you join a Windows machine to a domain, it gets SPNs for things like `HOST/` or `RestrictedKrbHost/`. Computer accounts have 128-character random passwords that rotate every 30 days. So not crackable. 2. Arbitrary SPN: These are SPNs manually assigned to User Accounts (Service Accounts). This happens when a service needs to run under a specific domain user identity.Since these are user accounts, they often have human-readable passwords. This is what we Kerberoast. #### How does it work? When a user wants to access a specific service (like a database) they need a Service Ticket (ST). 1. Our user already has a TGT (from the initial logon). 2. The user sends a `KRB_TGS_REQ` to the KDC requesting access to a specific SPN like `Service/service.domain.local`. 3. The KDC checks if the user is authenticated or not and looks up the account associated with that SPN. 4. The KDC then generates a `KRB_TGS_REP` which contains a Service Ticket that is encrypted with the Service Account’s key. The Vulnerability: Since the Service Ticket is encrypted using the service account's secret key the attacker who requests this ticket can take it offline and attempt to brute-force it. If the service account has a weak password the attacker can recover the plain-text password. #### The Encryption: msDS-SupportedEncryptionTypes This is a 32-bit field that tells the KDC what encryption types an account supports: * RC4\_HMAC\_MD5 (value: 4) * AES128\_CTS\_HMAC\_SHA1\_96 (value: 8) * AES256\_CTS\_HMAC\_SHA1\_96 (value: 16) Computer accounts have this property set by default to 28 (RC4 + AES128 + AES256), but user accounts don't have it set at all.\ When this property is undefined or set to 0, the default behavior is RC4 encryption. That's why Kerberoasting "just works" so well most service accounts return RC4 encrypted tickets by default, which are thousands of times faster to crack than AES and even if you enable AES encryption on a user account and if you specifically request RC4, you will still get an RC4 ticket. ### Tools and Commands **NetExec (nxc)** ```bash nxc ldap -u -p --kerberoasting output.txt ``` **Rubeus** ```powershell .\Rubeus.exe kerberoast /format:hashcat /outfile:hashes.txt ``` **Impacket** ```bash GetUserSPNs.py /: -dc-ip -request ``` **PowerView** ```powershell Get-DomainUser -SPN -Properties samaccountname,serviceprincipalname ``` **2. Cracking** After getting the hash we cam use Hashcat or John. **Hashcat** ```bash hashcat -m 13100 hashes.txt rockyou.txt ``` John ```bash john --format=krb5tgs --wordlist=rockyou.txt hashes.txt ``` #### Moral of the story? DO NOT USE WEAK PASSWORDS FOR SERVICE ACCOUNTS #### Sources [https://specterops.io/blog/2019/02/20/kerberoasting-revisited](https://specterops.io/blog/2019/02/20/kerberoasting-revisited/)