Comment on page
Kerberoasting Attack
Kerberoasting abuses native Kerberos protocol to harvest password hashes for Active Directory user accounts with servicePrincipalName (SPN) values (i.e. service accounts created from the user accounts). A user who is part of the domain is allowed to request a ticket-granting service (TGS) ticket for any SPN, and parts of the TGS may be encrypted with the RC4 using the password hash (NTLM) of the service account.
NOTE: This does not mean the user would be able to access any service present in the domain, the user is only allowed to request TGS Ticket for the services in the domain. In the end, the decision is taken by the service (to which TGS is presented by the client) whether to allow/deny the user's access request.
An adversary who is able to get the TGS tickets from memory, or captures them by sniffing network traffic, can extract the plain text password for the service account through an offline brute-force attack.
People who don't require too much detailing can skip this section.
The Windows implementation of the Kerberos protocol uses service principal names (SPNs) to determine which service account hash to use to encrypt the service ticket.
SPN (Service Principal Name): It is the mapping between service and account. The KDC gathers the info from servicePrincipalName attribute and encrypts the server portion of service tickets. Setspn.exe is used to map an AD account to a service
There are two “types” of service principal names in Active Directory: “host-based” SPNs that are linked to a domain computer account and “arbitrary” SPNs that are usually (but not always) linked to a domain user account.
From the Kerberoasting perspective, we generally don’t care about host-based SPNs, as a computer’s machine account password is complex and randomized by default and rotates every 30 days. The encryption mechanism used for encrypting TGS Ticket would be mostly AES 128/256 bit. However, it is better to understand it.
As Microsoft explains, “When a new computer account is created in Active Directory, host-based SPNs are automatically generated for built-in services". Here is an example of a computer account in my lab:
When a user requests/tries to access the share \\sqlsvr.redwolf.local\C$, the KDC maps this request to the HOST/sqlsvr.redwolf.local, indicating that the sqlsvr$ machine account NTLM hash (which is stored both on SQLSVR locally and the NTDS.dit Active Directory database on the DC/KDC) should be used to encrypt the server part of the service ticket. The TGS ticket is then presented to sqlsvr.redwolf.local, which is responsible for determining whether the requesting user should be granted access.
Any domain user account that has a
servicePrincipalName attribute set would be vulnerable to Kerberoasting attack. Any domain user can have a TGS for that SPN, allowing for the offline cracking of the service account plaintext password! This is obviously dependent on a crackable service account plaintext, but luckily for us service accounts tend to often have simple passwords that change very infrequently.Note: Any user account with 'servicePrincipalName' attribute set can be kerberoasted, irespective of whether there is an actual service running and various other scenarios
My Lab environment for this lab is:
- 1.SQLSVR - Computer/Machine on which we have access
- 2.[email protected] - User account on which we have registered SPN (websvc/redwolf-dc.redwolf.local:8080)
- 3.redwolf-dc - Domain Controller
NOTE: Websvc account does not use AES 128/256 Bit Encryption type for encrypting the ticket. Websvc uses RC4_HMAC_MD5 for encrypting the tickets. Keberoasting of AES enabled accounts is a different story.
Attribute - servicePrincipalName on websvc account
Packet flow captured in Wireshark
setspn -a <HOST>/<USERNAME>.<DOMAIN>.local:<PORT> <DOMAIN>\<USERNAME>
setspn -a redwolf-dc/[email protected]:8080 REDWOLF\websvc
Get-DomainUser function from PowerView can be used to enumerate domain user accounts for which SPN value is set. Get-DomainUser -SPN
Note: You would also receive KRBTGT account in this list, since it is also an service account. We cannot crack the hash as the password is managed by domain controller.
Invoke-Kerberoast function from PowerView can be used to dump the ST ( Service Ticker which is from TGS-REP encrypted using service account's password ).
Rubeus.exe kerberoast
Once the hash is retrieved we can use john or hashcat tool to crack the hash
hashcat -m 13100 '<HASH>' <WORDLIST_PATH>
- Set long and complex passwords for service accounts.
- Use Group Managed Service Accounts.
- Limit privileges of service accounts.
- Service accounts should NOT be part of the domain admin group!
- Use AES encryption instead of RC4 encryption (Only for windows server 2019)
Note : cracking AES encrypted ticket is still possible and it’s just a matter of time & effort (create/choose a reasonable dictionary). Desirable thing for kerberoasting would be RC4 encryption.
In a domain with Windows Server 2016 (or before) as the Domain Controller, enabling AES encryption does not mitigate Kerberoasting at all since attackers can simply specify RC4 as the only supported encryption method and ask for RC4 encrypted service tickets. For DC Windows Server 2019, enabling AES encryption does mitigate Kerberoasting by returning the highest level encryption key that the service account supports.
A Managed Service Account (MSA) enables administrators to manage rights and permissions for services but with automatic password management. It can be used on a single server. A group Managed Service Account (gMSA) provides the same functions as managed service accounts but can be managed across multiple servers as in a server farm or a load-balancing arrangement. It provides a higher security option for non-interactive applications/services/processes/tasks that run automatically.
- No default way of detection Kerberoasting, custom detections/alerts are necessary
- Enable “Audit Kerberos Service Ticket Operations” on DC
- Monitor Event ID 4769 – A Kerberos service ticket was requested.
- Looking for TGS-REQ packets with RC4 encryption is probably the best method.
- High rate of false positives
- Search for users with a high count of event 4769
Last modified 2yr ago