Kerberoasting is a post-exploitation attack technique targeting the Kerberos authentication protocol in Active Directory. In a Kerberoasting attack, an adversary uses a valid (even low-privilege) domain user account to request service tickets for service accounts – accounts that have a Service Principal Name (SPN) registered. These service tickets (TGS tickets) are encrypted with the service account’s password hash, and the attacker can retrieve them and crack the hash offline to obtain the plaintext password. Because this technique uses Kerberos in a standard way (requesting tickets) and performs password cracking offline, it is often difficult to detect with traditional security tools or antivirus – there’s no malware involved, just normal Kerberos traffic and offline computation.
The risk to Active Directory environments is significant. Kerberoasting is considered a “low-tech, high-impact” attack: many publicly available tools can automate the process of finding SPNs, extracting tickets, and brute-forcing passwords offline. If attackers crack a service account’s password, they can impersonate that service and gain whatever access the account has. Service accounts often have elevated privileges or access to sensitive systems, so this can enable lateral movement and privilege escalation across the network. For example, threat actors might compromise a high-privilege service account and then use it to deploy ransomware or steal data from multiple systems. In short, Kerberoasting exposes weak service account credentials and can lead to a complete Active Directory domain compromise if not mitigated.
How Kerberos Attack Works
Image Source: Cymulate
Understanding the mechanics of Kerberoasting will help in devising detection and prevention strategies. Here’s a step-by-step overview of how a Kerberoasting attack typically unfolds:
Target Identification: The attacker (already in the network with at least a regular user account) enumerates Active Directory to find user accounts with SPNs, i.e. service accounts. Any authenticated domain user can query directory data to identify these accounts (often using tools or scripts) since having an SPN means the account is running a Kerberos-service and is kerberoastable.
Ticket Request (TGS): Using any domain user credentials, the attacker requests a Kerberos service ticket (TGS) for one or more of the identified SPNs. This request is made to the Key Distribution Center (KDC) on the domain controller. Notably, the KDC does not check whether the requesting user has permission to actually use the service – it only verifies that the user is authenticated and the SPN exists This design flaw is what makes Kerberoasting possible: any authenticated user can request a service ticket for any SPN.
Ticket Retrieval: The domain controller responds by issuing the requested TGS. Importantly, the service ticket is encrypted with the service account’s secret key – effectively using a hash of the service account’s password as the encryption key. The attacker now receives this encrypted ticket. The ticket (encoded in the Kerberos TGS format) can be saved from memory or the Kerberos cache (attackers often use tools like Mimikatz or Rubeus to extract these tickets). At this point, the attacker has not needed any elevated privileges – even a domain user with no special rights can perform the above steps.
Offline Cracking: With the encrypted TGS ticket in hand, the attacker’s next step is to crack the service account password offline. They take the ticket to a separate system or offline cracking tool and attempt to recover the plaintext password by guessing passwords and computing the corresponding hash to see if it decrypts the ticket. Common tools for this include Hashcat, John the Ripper, or specialized Kerberos hash cracking scripts. Because this brute-force/dictionary attack is done offline, it does not generate logon failures or lock out any accounts. The speed of cracking depends on the password strength and the encryption algorithm used. (Notably, attackers often request the ticket using the older RC4-HMAC encryption if possible, since it’s weaker and faster to crack than modern AES encryption.)
Service Account Compromise: If the password hash is cracked, the attacker now knows the service account’s actual password. This is a critical win for the adversary – they can now authenticate as that service account in the domain. The attacker effectively “roasts” the account and gains all privileges associated with it. Many service accounts are highly privileged (sometimes even Domain Admins or similar) or have access to sensitive resources by design. Using the service account’s identity, the attacker can move laterally to other systems, access databases or services that account runs, dump additional credentials, or elevate their domain privileges further. In real attacks, this foothold often leads to full domain compromise if the service account has extensive rights.
It’s worth emphasizing that Kerberoasting does not exploit a code vulnerability – it abuses legitimate Kerberos functionality. Any domain user can request service tickets, and if service account passwords are weak, cracking them offline is the attacker’s goal. This is why detection is challenging: the initial ticket request traffic doesn’t look malicious, and the heavy lifting (password cracking) happens outside the network. Nevertheless, there are some tell-tale signs in Kerberos logs we can use to spot Kerberoasting attempts.
Kerberos Indicators of Compromise (IOCs)
- Multiple SPN Ticket Requests: Unusual volume of Kerberos service ticket requests (Event ID 4769) from a single user, especially targeting many different services in a short period. Kerberoasting tools often request tickets for all SPNs to find any weak service account password.
- RC4 Encryption Usage: Service tickets using RC4-HMAC (encryption type 0x17) are a red flag. Modern Kerberos defaults to AES encryption, so an RC4 ticket request may indicate the attacker intentionally requested a crackable encryption type.
- Non-Standard User Agents: In Event 4769 logs, the requesting account is a normal user (no “$” at end) requesting tickets for services – normal users don’t typically request service tickets for arbitrary applications.
- No Corresponding Access: Service tickets requested but never actually used to log into the service (since the attacker’s goal is only to obtain the ticket hashes).
Detection (Using Event Viewer & PowerShell)
Detecting Kerberoasting activity can be challenging, but by using native Windows tools (PowerShell and Event Viewer) and auditing features, administrators can catch suspicious patterns. Below we outline a two-pronged approach: first identify which accounts are at risk (have SPNs), and then monitor Kerberos ticket requests for anomalies. All of this can be done with built-in tools, no third party products required.
Before you begin: Ensure that your domain controllers are logging Kerberos service ticket requests. You may need to enable the Audit Kerberos Service Ticket Operations audit policy on the domain controllers (under the Account Logon category) to get Event ID 4769 (Kerberos service ticket requested) events. By default, these events might not be audited because they can be very frequent. Once enabled, the domain controller’s Security log will record 4769 events for every service ticket request. Keep in mind that in a typical environment, Kerberos TGS requests are common (on the order of 10–20 per user per day, as users access various services), so you will need to filter and analyze these events to spot the malicious ones.
Listing Service Accounts with SPNs
The first step is to inventory which accounts in your Active Directory have an SPN, since those are the potential Kerberoasting targets. You can use PowerShell (with the ActiveDirectory module) to find all user accounts that have an SPN set:
# List all user accounts that have a ServicePrincipalName (SPN) defined
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
Select-Object Name, ServicePrincipalName
This command queries Active Directory for user accounts where the ServicePrincipalName attribute is not empty, and it displays each account’s name and SPN(s). Review this list to identify your service accounts. Pay attention to any service accounts that are highly privileged (e.g. members of Domain Admins or other sensitive groups) – those are prime targets for Kerberoasting. If you find any such accounts, you might flag them for extra scrutiny (and later, for password changes or privilege reduction as part of mitigation).
Monitoring Kerberos Ticket Requests
After identifying the accounts at risk, the next step is to monitor Kerberos ticket request events (Event ID 4769) for patterns that indicate Kerberoasting. You can do this via Event Viewer on the domain controller or by using PowerShell to parse the Security event log.
Using Event Viewer: On a domain controller, open Event Viewer and navigate to Windows Logs -> Security. Use the Filter Current Log option to filter by Event ID 4769 (which corresponds to “A Kerberos service ticket was requested”). Look at the details of these events, focusing on fields like Service Name, Account Name, and Ticket Encryption Type:
Service Name – the SPN or service that was requested. Typically, normal service tickets are requested by computer accounts for services they are accessing (these service names might end with “$” or be things like
cifs/for file share, etc.). If you see an unusual service SPN being requested, especially one that corresponds to a high-value service account, take note.Account Name (or Client/User Name) – the account that requested the ticket. In typical use, many Kerberos TGS requests come from computer accounts (which have names ending in
$) or from user accounts accessing a single service. A red flag is if you see a normal user account (no$) requesting tickets for many different services or for services it doesn’t normally use. For example, if an account that is not a known admin suddenly requests 10 different service tickets in a short timespan, that’s suspicious.Ticket Encryption Type – this indicates the encryption algorithm used for the Kerberos ticket. In modern environments, AES encryption types (0x11 or 0x12 for AES128/256) are the default. If you notice tickets being issued with RC4-HMAC (value 0x17), it could be a sign of Kerberoasting. Attack tools often request RC4 encryption because it’s easier to brute-force. RC4 (0x17) tickets should be rare in environments where AES is fully deployed. Thus, any 4769 event where Ticket Encryption Type = 0x17 deserves attention.
Event Viewer XML Filter
You can create a custom XML filter in Event Viewer to find 4769 events with RC4 encryption. For instance, the following XML query will filter the Security log for event 4769 with TicketEncryptionType 0x17:
<QueryList>
<Query Id="0" Path="Security">
<Select>*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]</Select>
</Query>
</QueryList>
In the Event Viewer UI, this can be added under the XML tab of the filter dialog. This will surface any service ticket requests using RC4.
Using PowerShell
If you prefer command-line, PowerShell’s Get-WinEvent makes it possible to query and filter events. For example, to retrieve Kerberos service ticket requests that used RC4 encryption, you can run:
# Find Kerberos TGS requests (4769 events) that used RC4-HMAC (0x17) encryption
Get-WinEvent -LogName Security -FilterXPath `
"*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]"
This query uses an XPath filter on the event data to return only the 4769 events where the TicketEncryptionType is 0x17 (RC4). In a well-configured AD environment, this should ideally return zero events, or only known legacy cases. If you get hits, investigate why those services are using RC4 and whether the requests are expected.
You can also use PowerShell to identify accounts making unusually high numbers of TGS requests. For instance, to count how many service tickets each account has requested in the last day, you could do:
# Count Kerberos TGS requests per account in the last 24 hours
$since = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769; StartTime=$since} |
Group-Object -Property { ($_).Properties[4].Value } |
Sort-Object Count -Descending | Select-Object Name, Count -First 10
(Note: In the above, the index for .Properties[...] may vary by event schema; another approach is parsing the Message field or using XPath as shown earlier.)
This snippet groups the 4769 events by the requesting account name and shows the top 10 accounts with the most requests. If a single user account appears at the top with an abnormally high count, especially if it’s not a service or computer account, that could indicate Kerberoasting activity. Attackers often attempt to request multiple service tickets in a short period to maximize their chances of finding a weak password.
Event IDs to Watch
Aside from 4769, you might also consider Event ID 4768 (“A Kerberos authentication ticket (TGT) was requested”) on domain controllers. 4768 events are logged for Ticket Granting Ticket requests and can similarly be filtered for anomalies, though they generally mirror some of the same information. In most cases, focusing on 4769 is sufficient for Kerberoast detection since it directly signals service ticket requests. Also note Event ID 4770 (“Kerberos service ticket was renewed”), which might not be directly indicative of Kerberoasting but is related to TGS renewals if observed. The primary indicator remains an unusual pattern of 4769 events.
By leveraging these native tools and audit logs, you can detect Kerberoasting attempts. The key indicators are unexpected service ticket requests – either by volume, by encryption type, or by unusual requesting accounts. When such indicators are spotted, they should be investigated promptly as potential signs of an attacker probing for crackable service accounts.
Active Directory Health & Security Assessment
Try our Active Directory Health & Security Assessment Tool. Monitor DC replication, DNS, Active Directory configuration, Operational checks, DC hardware, AD security assessment, GPO checks, permissions & more..
Kerberoasting Prevention & Mitigation
Image Source: CyberArrow
Preventing Kerberoasting attacks centers on reducing the factors that make them possible or attractive targets. In practice, this means hardening your service accounts and keeping an eye on Kerberos-related activity. Here are several best practices to mitigate Kerberoasting in Active Directory:
Limit Privileges for Service Accounts: Avoid assigning high-level privileges (Domain Admin, enterprise admin, etc.) to any service account that has an SPN registered. Service accounts should run with the least privileges necessary for their service. If a service account does not need administrative rights, don’t grant them. High-privilege accounts with SPNs are the golden prize for Kerberoasting – an attacker who cracks such an account gains very powerful access. By ensuring that service accounts aren’t members of highly privileged groups and don’t have excessive rights, you greatly reduce the impact if one is Kerberoasted. Perform an audit of accounts with SPNs and remove or separate any that are unnecessarily privileged.
Use Strong Passwords or gMSAs: The single most effective mitigation for Kerberoasting is to use extremely strong, complex passwords for all service accounts, or better yet, use Group Managed Service Accounts (gMSAs) where possible. A gMSA is a special type of account that automatically has a long (120 characters by default) random password managed by Active Directory. These passwords are practically impossible to crack with current techniques. If you can use gMSAs for services (IIS application pools, SQL Server, scheduled tasks, etc.), do so – it eliminates the static password weakness. For traditional service accounts (non-gMSA), set passwords that are longer than 25 characters, not guessable, and ideally randomly generated. This length makes brute-force cracking extremely difficult, effectively defanging the Kerberoast. Also ensure these passwords meet your complexity requirements (mix of uppercase, lowercase, numbers, symbols). Remember that any account with an SPN is a potential Kerberoast target, so all such accounts should have strong passwords (Microsoft recommends at least 14 characters as a minimum, but much longer is better).
Monitor Kerberos Logs and Audit SPN Usage: Incorporate continuous monitoring of Kerberos-related events into your security regimen. As described in the detection section, keep an eye on Event ID 4769 for anomalies (consider setting up alerts in your SIEM for things like a single user requesting many service tickets, or any RC4-encrypted tickets being issued). Regularly review the list of accounts with SPNs in your domain and verify that each is expected and properly managed. Remove SPNs from accounts that don’t need them, and document service accounts so you know what each one is for. By auditing SPNs, you can catch situations like someone creating a rogue service account with an SPN (which an attacker might do to facilitate Kerberoasting), or find old service accounts that are no longer in use (and thus shouldn’t be left with valid credentials). Enabling enhanced Kerberos logging and reviewing those logs can provide early warning of attempts to exploit Kerberos. In summary, make Kerberos auditing part of your routine Active Directory security monitoring.
Regularly Rotate Service Account Passwords: Even with complex passwords, it’s wise to rotate service account passwords periodically. This limits the time window an attacker has to crack any given credential. For manual service accounts, establish a schedule (for example, every 90 days or even more frequently for high-value accounts) to update their passwords – and ensure the new passwords are also complex and lengthy. If you’re using gMSAs, password rotation is handled automatically by AD, typically on a 30-day schedule (configurable). Regular rotation means that even if an attacker grabs a ticket, the password might change before they can crack it, or it will become useless afterwards. It also helps invalidate old credentials that might have leaked. Treat service account credential changes with the same importance as user account expirations, if not more, given their significance.
Harden Kerberos Encryption and Policies: Make sure your domain and service accounts are configured to use modern Kerberos encryption (AES) instead of legacy RC4 where possible. In Active Directory, service accounts can be configured (via account properties) to require AES encryption for Kerberos. If all your clients and services support it, you can disable RC4 encryption for Kerberos in your domain. This doesn’t stop Kerberoasting outright (a weak password encrypted with AES can still be cracked, just with more effort), but it removes the option for attackers to choose the faster RC4 cracking path. Microsoft has indicated plans to eventually disable RC4 by default in newer Windows versions, but you can be proactive in enforcing AES-only for your service accounts. Additionally, consider placing highly privileged service accounts (if any) in the “Protected Users” security group, which among other things disallows Kerberos DES/RC4 encryption and older authentication mechanisms for those accounts. This can provide extra protection against credential theft attacks.
By implementing these measures – principle of least privilege, strong credentials (or managed accounts), vigilant monitoring, and strict Kerberos policies – you significantly reduce the likelihood of a successful Kerberoasting attack. Essentially, you want to make it impractical for an attacker to find an easy target: even if they can get a service ticket, the password behind it should be uncrackable or the account should not grant them significant power.
Also Read: The Role of Threat Hunting in Active Directory Security Operations
Summary - Kerberoasting Attack Detection & Prevention
Kerberoasting remains a potent threat to Active Directory environments because it exploits weak passwords and a fundamental aspect of Kerberos ticketing. An attacker with even low-level access can use this technique to elevate their privileges by cracking service account passwords offline and impersonating those accounts. The good news is that with attentive defense, you can dramatically lower the risk. In this article, we discussed how Kerberoasting works and how to detect it using native tools like PowerShell and Event Viewer – for example, watching for unusual Event ID 4769 patterns such as RC4-encrypted tickets or a user requesting many service tickets. We also covered proactive steps to prevent Kerberoasting, including using strong, long passwords (or gMSAs) for service accounts, limiting their privileges, monitoring Kerberos logs, and rotating credentials regularly.
To stay secure, organizations should regularly audit their Active Directory for potential weaknesses (like poorly managed service accounts or weak encryption settings) and enforce robust credential policies. Hardening service accounts – by limiting privileges and using strong passwords – is crucial, as is having good visibility into your Kerberos authentication traffic. With these measures in place, the window of opportunity for Kerberoasting attacks can be greatly narrowed. In essence, detect early and harden continuously: by catching suspicious Kerberos activity and ensuring no easy targets exist, you can protect your AD “keys to the kingdom” from being roasted by attackers. Regular auditing and adherence to best practices will keep your Active Directory environment resilient against Kerberoasting and related credential attacks in the long run.
