Listen to this Post
Introduction:
In the complex landscape of Active Directory (AD) security, a seemingly minor misconfiguration can lead to a full domain compromise. Kerberoasting is a pervasive attack technique that exploits service accounts to extract crackable credentials, and it all begins with the enumeration of Service Principal Names (SPNs). This article provides a technical deep dive into identifying vulnerable accounts and hardening your environment against this stealthy threat.
Learning Objectives:
- Understand the fundamental mechanics of Kerberoasting attacks and their impact on AD security.
- Master both offensive and defensive command-line techniques for SPN enumeration using PowerShell and native Linux tools.
- Implement robust mitigation and detection strategies to protect service accounts from credential theft.
You Should Know:
1. The Foundation: Enumerating SPNs with PowerShell
The initial step in a Kerberoasting attack is identifying user accounts with Service Principal Names (SPNs) set. These accounts are often less frequently monitored and can have weaker passwords.
Verified Command:
Basic SPN Enumeration
Get-ADUser -Filter -Properties ServicePrincipalName | Where-Object {$_.ServicePrincipalName -ne $null} | Select-Object SamAccountName, ServicePrincipalName
Targeted SPN Query (as seen in the source)
Get-ADUser -Filter 'ServicePrincipalName -eq "vmware/inlanefreight.local"' -Properties ServicePrincipalName | Select-Object SamAccountName, DistinguishedName, ServicePrincipalName
Step-by-Step Guide:
This PowerShell command, executed from a domain-joined machine with the Active Directory module loaded, queries the domain controller. The `-Filter ` parameter retrieves all user objects. The `-Properties ServicePrincipalName` clause ensures this specific attribute is loaded. The `Where-Object` filter then narrows the results to only users that have at least one SPN configured. The final `Select-Object` cmdlet formats the output to show the username and associated SPNs, providing a target list for an attacker.
2. Offensive Tooling: Automating the Attack with Rubeus
Once target accounts are identified, attackers request Kerberos service tickets (TGS) for these SPNs. These tickets are encrypted with the service account’s password hash, which can be cracked offline.
Verified Command:
Using Rubeus for Kerberoasting (on a compromised Windows host) Rubeus.exe kerberoast /stats /outfile:hashes.txt Targeting a specific user Rubeus.exe kerberoast /user:sqlsvc /outfile:sqlsvc_hash.txt
Step-by-Step Guide:
Rubeus is a powerful C tool for Kerberos exploitation. The `kerberoast` command automates the process of requesting TGS tickets for accounts with SPNs. The `/stats` flag provides a summary of the results. The requested tickets are output in a format (like Hashcat mode 13100) suitable for offline password cracking with tools like Hashcat or John the Ripper. This allows an attacker to potentially recover the plaintext password of the service account.
3. The Adversary’s Linux Toolkit: Impacket’s GetUserSPNs
Attackers operating from a Linux machine within the network can perform the same enumeration and extraction without needing Windows-specific tools.
Verified Command:
Using Impacket's GetUserSPNs without pre-authentication (if anonymous binds are allowed) GetUserSPNs.py -request -dc-ip 10.10.10.10 INLANEFREIGHT.LOCAL/ Using Impacket with a low-privilege domain user's credentials GetUserSPNs.py INLANEFREIGHT.LOCAL/jdoe:Password123 -dc-ip 10.10.10.10 -request
Step-by-Step Guide:
This Python script from the Impacket library connects to the Domain Controller (IP specified with -dc-ip). The `-request` flag is crucial; it not only lists the accounts with SPNs but also automatically requests their TGS tickets and outputs them in a crackable format. The first command attempts an anonymous bind, which may work in poorly secured environments. The second command uses known domain credentials to authenticate and perform the query, which is more common.
4. Defensive Hardening: Auditing with PowerShell
Proactive defense requires regularly auditing your environment for accounts with SPNs. This helps identify over-privileged accounts and potential targets for attackers.
Verified Command:
Comprehensive SPN Audit Script
Get-ADUser -Filter -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate, Enabled | Where-Object {$<em>.ServicePrincipalName -ne $null} | Select-Object Name, SamAccountName, Enabled, @{Name="SPN Count";Expression={$</em>.ServicePrincipalName.Count}}, PasswordLastSet, LastLogonDate | Export-Csv -Path "SPN_Audit_Report.csv" -NoTypeInformation
Step-by-Step Guide:
This defensive PowerShell command creates a comprehensive audit report. It fetches all users and includes key properties like ServicePrincipalName, PasswordLastSet, and LastLogonDate. The `Where-Object` filter isolates accounts with SPNs. The calculated property `SPN Count` shows how many SPNs are assigned to each account, which can be an indicator of excessive privileges. Finally, the results are exported to a CSV for further analysis, helping security teams identify stale, disabled, or over-permissioned service accounts.
- Mitigation Strategy: Implementing Group Managed Service Accounts (gMSAs)
The most effective technical mitigation is to use Group Managed Service Accounts (gMSAs) instead of standard user accounts for services. gMSAs have long, complex, and automatically rotated passwords, making Kerberoasting impractical.
Verified Command:
Create a new gMSA New-ADServiceAccount -Name "WebApp-gMSA" -DNSHostName "WebApp.inlanefreight.local" -PrincipalsAllowedToRetrieveManagedPassword "WEB_SERVERS$" Install the gMSA on a target server Install-ADServiceAccount -Identity "WebApp-gMSA" Verify the gMSA is installed correctly Test-ADServiceAccount -Identity "WebApp-gMSA"
Step-by-Step Guide:
First, create the gMSA using New-ADServiceAccount. The `-PrincipalsAllowedToRetrieveManagedPassword` parameter specifies which computer accounts (note the `$` suffix) are allowed to use this gMSA. Next, on each server that will run the service, install the gMSA with Install-ADServiceAccount. Finally, always verify the installation was successful using Test-ADServiceAccount. Once configured, the service runs under the gMSA context, and Windows manages the password, effectively neutralizing the Kerberoasting threat for that account.
- Advanced Detection: Hunting for Kerberoasting with Sigma Rules
Detecting Kerberoasting activity is critical. Security teams should monitor for a high volume of TGS requests, which is a key indicator of this attack.
Verified Command/Sigma Rule Snippet:
title: Kerberoasting Attack Pattern logsource: product: windows service: security detection: selection: EventID: 4769 A Kerberos service ticket was requested ServiceName: '' Matches any service TicketEncryptionType: 0x17 RC4 encryption (often used with weak passwords) filter: AccountName: 'NOT_A_SERVICE_ACCOUNT$' Exclude computer accounts condition: selection and not filter timeframe: 5m groupby: AccountName trigger: num: 10 same: IpAddress, ServiceName
Step-by-Step Guide:
This Sigma rule (convertible to SIEM queries like Splunk or Elasticsearch) detects Kerberoasting patterns. It focuses on Windows Security Event ID 4769. The key detection logic looks for requests using older, weaker RC4 encryption (0x17), which attackers prefer because the resulting hashes are easier to crack. The rule then groups events by the source account and IP address within a 5-minute window. If an account requests more than 10 different service tickets (a low threshold for a service account), it triggers an alert, indicating potential malicious activity.
- Beyond the Basics: Forcing AES Encryption for Service Accounts
If migrating to gMSAs is not immediately feasible, a strong mitigation is to enforce AES encryption for Kerberos tickets, making them significantly harder to crack.
Verified Command:
Check current Kerberos encryption settings for a user
Get-ADUser -Identity "sqlsvc" -Properties "msDS-SupportedEncryptionTypes"
Configure a user account to require AES encryption
Set-ADAccountControl -Identity "sqlsvc" -KerberosEncryptionType AES128, AES256
Alternatively, set the encryption type via the attribute
Set-ADUser -Identity "sqlsvc" -Replace @{"msDS-SupportedEncryptionTypes" = 24} 24 = AES128 + AES256
Step-by-Step Guide:
First, check the current encryption types supported by the service account. Then, use the `Set-ADAccountControl` cmdlet to enforce AES encryption. This setting ensures that when a TGS ticket is requested for this account, it will be encrypted with a strong AES key instead of the weaker RC4-HMAC. This doesn’t prevent the ticket from being stolen, but it makes offline cracking computationally infeasible with current technology, effectively protecting the account’s password.
What Undercode Say:
- The Principle of Least Privilege is Non-Negotiable: The core vulnerability Kerberoasting exploits is the use of domain user accounts with excessive privileges for services. The fundamental mitigation is architectural: never use a standard user account for a service if a Managed Service Account (gMSA or sMSA) is an option.
- Detection Relies on Knowing Your Baseline: Effective detection of Kerberoasting is not about looking for a single “bad” event, but recognizing anomalous behavior. A service account requesting 5 tickets in an hour might be normal; a user account requesting 50 different service tickets in 10 minutes is a blazing red alert.
The technical simplicity of Kerberoasting is what makes it so dangerous. It leverages built-in, legitimate Kerberos functions, requiring no exploits or zero-days. The attack’s success hinges entirely on procedural and configuration weaknesses—specifically, weak service account passwords and a lack of monitoring for TGS request anomalies. While tools like Rubeus and Impacket make the attack accessible, they also provide a clear signature for defenders. The battle is won through proactive hardening: minimizing SPN usage, enforcing strong authentication protocols like AES, and implementing robust, behavior-based detection rules. This moves the defense from a reactive posture to a preventive one.
Prediction:
As organizations continue to migrate to cloud-centric hybrid environments (Azure AD/Entra ID, AWS Managed AD), the classic on-premises Kerberoasting attack will evolve. We predict a significant rise in “Cloud Kerberoasting” techniques targeting Azure AD service principals and managed identities. While the underlying protocols differ, the core attack pattern—abusing over-permissioned service identities to steal credentials—will remain. Future offensive security tools will automate the enumeration of cloud service principals and the extraction of associated tokens, while defensive strategies will need to focus on conditional access policies, privileged identity management (PIM), and monitoring cloud audit logs for anomalous service principal sign-ins. The lesson of Kerberoasting will continue to be relevant: the security of any identity, especially non-human identities, is paramount.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Gabriel Dueck – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
