If you are a developer who has ever been handed credentials to run a service on a Windows domain, you have probably contributed to a security problem you did not know existed. I am not saying this to be condescending — I did not understand Kerberoasting until I started doing Active Directory security reviews professionally. Now I find the same three misconfigurations in almost every organization I assess.
This post explains Kerberoasting plainly for people who write code but do not specialize in Active Directory security. No acronym soup, no red team posturing.
What is Kerberos, briefly
When you log into a Windows domain, Kerberos handles authentication. You prove your identity to a central server (the Key Distribution Center, or KDC) and receive a Ticket Granting Ticket (TGT). When you need to access a specific service — a SQL Server, a web application, a file share — your client uses that TGT to request a Service Ticket (TGS) for that specific service.
The service is identified by a Service Principal Name (SPN). An SPN is a string like MSSQLSvc/sqlserver01.corp.local:1433 registered in Active Directory against the account that runs that service.
Here is the key point: the TGS is encrypted with the NTLM hash of the service account's password. The KDC does not check whether the requesting user is authorized to use the service — that check happens when the user actually presents the ticket to the service. Any authenticated domain user can request a TGS for any SPN in the domain.
What Kerberoasting actually is
Kerberoasting is requesting TGS tickets for service accounts and taking those encrypted tickets offline to crack them. Since the ticket is encrypted with the service account's password hash, cracking it gives you the plaintext password.
There is nothing exotic about this. Any domain user can do it. No elevated privileges required for the initial step.
# Find accounts with SPNs (potential Kerberoasting targets)
# Run this as any domain user
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
-Properties ServicePrincipalName, PasswordLastSet, Description |
Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, Description |
Where-Object { $_.SamAccountName -ne "krbtgt" } |
Sort-Object PasswordLastSet
# Request and export TGS tickets (legitimate Windows API call)
Add-Type -AssemblyName System.IdentityModel
$spns = @("MSSQLSvc/sqlserver01.corp.local:1433")
foreach ($spn in $spns) {
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken `
-ArgumentList $spn
}
# Tickets now in memory, exportable with tools like Mimikatz or Rubeus
Once you have the .kirbi ticket file, you take it to a machine with GPU power and run Hashcat against it. A service account with password Summer2023! falls in seconds.
The three misconfigurations developers introduce
1. Running applications as domain admin accounts
This is the most damaging one. A developer needs their application to read from Active Directory or write to a shared folder. IT gives them a domain admin account to "make sure it works." The application runs, it works, everyone moves on.
Now that domain admin account has an SPN registered against it (so Kerberos can issue tickets for the service), and if its password is weak or old, an attacker who compromises any domain account can request that ticket and crack it offline — resulting in full domain compromise.
The fix: create a dedicated service account with only the permissions the application actually needs. Nothing more. This sounds obvious but it requires someone to actually think through what "the permissions the application actually needs" means, which often requires back-and-forth with the developer. This conversation frequently does not happen.
2. Service account passwords that never change
Active Directory, by default, does not enforce password rotation for service accounts the way it does for user accounts. A service account created in 2018 with a password set during the Obama administration is still out there in most organizations I assess.
The modern solution is Group Managed Service Accounts (gMSA). These are accounts where Active Directory manages the password automatically, rotating it every 30 days. The password is 120 characters of random bytes. Kerberoasting a gMSA account is computationally impossible with current hardware.
# Create a gMSA (run as domain admin)
New-ADServiceAccount -Name "svc-myapp" `
-DNSHostName "svc-myapp.corp.local" `
-PrincipalsAllowedToRetrieveManagedPassword "WebServers$" # AD group
# Install on the target server
Install-ADServiceAccount -Identity "svc-myapp"
# Test it
Test-ADServiceAccount -Identity "svc-myapp"
Most applications support gMSA. The ones that do not tend to be legacy applications that have other problems.
3. No tiering — everything on one flat network/domain
Active Directory tiering (also called the administrative tier model) separates accounts and systems into tiers: Tier 0 (domain controllers, PKI), Tier 1 (servers and applications), Tier 2 (workstations and end-user devices). Accounts in Tier 2 should never be able to touch Tier 0 systems.
When everything is flat, a Kerberoastable service account on a developer's web application server can be the entry point to full domain compromise if that account has been granted excessive permissions "just in case."
I have documented the most common AD misconfigurations and their remediation steps in detail in the , a cybersecurity consulting firm. We publish security hardening checklists for FortiGate, Palo Alto, Active Directory, and more — free PDF and Excel.
SOCIAL SHARE CARD GENERATOR