Finding and Fixing Kerberoastable Accounts with PowerShell
- Chris Keim
- 7 hours ago
- 11 min read
In This Article:
What is Kerberoasting
Kerberoasting is one of the most effective attack techniques used against Active Directory environments, and one of the easiest to miss. It doesn't trigger account lockouts. It doesn't require elevated privileges. It works entirely within normal Kerberos authentication behavior. Any authenticated domain user can request a service ticket for any account with a Service Principal Name (SPN) registered in Active Directory. That ticket is encrypted with the service account's password hash, and once an attacker has it, they crack it offline, no further interaction with your domain controllers required. If the service account has a weak password, it's game over.
In most of the environments I've reviewed, Kerberoastable accounts exist and nobody knows about them. Old service accounts with SPNs that were set years ago and never cleaned up. Application accounts with weak passwords that haven't changed since the server was built. These are low-hanging fruit for attackers who have already gained a foothold in your environment.
This article is written for AD administrators and systems engineers. You don't need a pen testing background to follow along, just PowerShell and access to Active Directory. By the end, you'll know how to find every Kerberoastable account in your environment, identify which ones are actually risky, and take concrete steps to reduce your exposure.
How Kerberoasting Works
To understand Kerberoasting, you need a basic understanding of how Kerberos authentication works, specifically the part that gets abused.
When a user needs to access a service in Active Directory, their workstation requests a Kerberos service ticket from the Domain Controller. That ticket is encrypted using the service account's password hash. The workstation presents the ticket to the service, the service decrypts it, and access is granted. This is normal, expected behavior, it happens thousands of times a day in your environment.
Here's where the problem starts. Any authenticated domain user can request a service ticket for any account that has a Service Principal Name (SPN) registered in Active Directory. The Domain Controller doesn't check whether the user actually needs access to that service. It just hands over the ticket. That ticket is encrypted with the service account's password hash and sent back to the requesting user.
An attacker with a valid domain account, even a low-privilege one, can request tickets for every SPN enabled account in your domain and walk away with the encrypted hashes. No elevated privileges required. No traffic sent to the target service. No alerts triggered. They take those hashes offline and crack them at their own pace using tools like Hashcat.
Whether they succeed comes down to one thing, password strength. A service account with a short, human-set password is cracked in minutes. A 25 character randomly generated password may never be cracked. In most environments I've worked in, service account passwords fall into the first category, set once when the application was installed and never touched again.
The attack gets more dangerous the higher the privilege of the compromised account. A cracked Domain Admin service account means full domain compromise. Even a lower privilege service account can open doors to lateral movement, data access, or a stepping stone to something worse.
What Makes an Account Kerberoastable
Not every account in your environment is a target. Kerberoasting requires a specific set of conditions to be exploitable. Understanding what to look for is the first step in knowing where your risk actually lives.
A Service Principal Name (SPN) is registered on a user account. This is the core requirement. SPNs are how Kerberos maps a service to the account it runs under. Computer accounts have SPNs too, but they aren't vulnerable — their passwords are long, complex, and rotate automatically every 30 days. User accounts are the target because their passwords are set by people and often never change. If a user account has an SPN, it can be Kerberoasted.
RC4 encryption is not disabled. By default, Kerberos will use RC4 encryption when issuing service tickets if the account supports it. RC4 hashes are significantly easier to crack offline than AES. Accounts that have never been configured with a specific encryption type will almost always fall back to RC4, which is exactly what an attacker wants.
The password is weak or non-expiring. Service accounts are notorious for this. They're created during an application deployment, given a password that meets the minimum policy, and then excluded from password expiration so the application doesn't break. That password may have been set five years ago and never changed. Even a moderately equipped attacker can crack it.
The account carries high privilege. A Kerberoastable account with no meaningful access is a low-risk finding. A Kerberoastable account that is a member of Domain Admins, has broad delegation rights, or has access to sensitive systems is critical. Privilege level is what separates a cleanup item from an emergency.
In practice, the accounts that show up most often are legacy application service accounts, SQL service accounts, accounts used for scheduled tasks, and sync accounts like older Azure AD Connect configurations. These are the ones to focus on first.
Finding Kerberoastable Accounts with PowerShell
This is where we get to work. The goal here is to find every user account in your environment that has an SPN registered, evaluate the encryption type, and flag accounts that carry elevated privilege or have non-expiring passwords. All of this is read-only, nothing is changed.
Basic SPN Enumeration
Start with the simplest query, every user account with an SPN configured:
This gives you the full list. In a small environment you might get five accounts. In a larger one you may get fifty. Either way, this is your starting point.
Adding Encryption Type
The next thing to check is whether the account is configured to support AES encryption or is falling back to RC4. This is stored in the msDS-SupportedEncryptionTypes attribute. A value of 0 or not set means RC4 is likely in play.
Checking Group Membership for Privilege
Knowing an account has an SPN is one thing. Knowing it's a member of Domain Admins is another. Add a group membership check to start separating low risk findings from high-risk ones:
Putting It Together, Export to CSV
Once you have the full picture, export it so you can review it properly and share it with your team or document it for a security review:
Run this on any domain-joined machine with the Active Directory module loaded. You don't need elevated privileges, standard domain user rights are sufficient to pull this data, which is exactly why this attack is so effective in the first place.
Interpreting What You Find
Running the script is the easy part. What you do with the results is where most security reviews fall apart. Not every account in your output is a crisis, but some of them will be. Here's how to triage what you're looking at.
Start with privilege. The first thing to look at is the Groups column. Any account with an SPN that is a member of Domain Admins, Enterprise Admins, Schema Admins, or any other tier-zero group is an immediate priority. These need to be addressed before anything else. In most environments I've reviewed, finding a privileged account with an SPN is too common, it's a critical finding.
Look at the encryption type. Accounts with an EncryptionType value of 0, blank, or 2 are likely falling back to RC4. These are the accounts most vulnerable to offline cracking. Accounts with a value of 8 or 24 support AES, which significantly raises the bar for an attacker. If an account has AES enabled and a strong password, the practical risk is much lower, though it's still worth cleaning up.
Check the password age. The PasswordLastSet column will tell you a story. A service account with a password that was set in 2017 and has never changed is a red flag regardless of its privilege level. Combine that with PasswordNeverExpires = True and you have an account that has been sitting with the same crackable hash for years.
Identify the account's purpose. Not every SPN you find belongs to an actively used service. In most environments there are accounts with SPNs that were set during an application deployment years ago, the application was decommissioned, and nobody cleaned up the account. These are easy wins, disable or delete the account and the risk is gone.
Some accounts you'll recognize immediately. SQL service accounts, backup agent accounts, application service accounts, these are expected. Others won't be obvious. For anything you can't immediately identify, track down the application owner before making changes. Removing an SPN from an active service account will break authentication for that service.
Watch for sync accounts. If your environment has Azure AD Connect, the sync account will show up in your results. It requires replication rights by design and will have an SPN. This is expected, but it's worth confirming the account is locked down, has a strong password, and isn't carrying more privilege than it needs.
A simple way to prioritize your findings is to sort by risk tier:
Priority | Criteria |
|---|---|
Critical | SPN on a privileged account. |
High | RC4 encryption + password never expires + password age over 1 year. |
High | RC4 encryption + password age over 1 year. |
Low | AES enabled + strong password hygiene. |
Work through them in that order. The goal isn't to fix everything today, it's to make sure the highest risk accounts get addressed first.
Remediation
Finding Kerberoastable accounts is only half the job. Here's how to actually reduce the risk, starting with the highest impact changes.
Remove Unnecessary SPNs
The simplest fix is also the most effective, if an account doesn't need an SPN, remove it. This completely eliminates the account as a Kerberoasting target. Before removing an SPN, confirm the service it was associated with is no longer active. Removing an SPN from a live service account will break Kerberos authentication for that service immediately.
Migrate to Group Managed Service Accounts (gMSA)
This is the right long-term solution for any service account that legitimately needs an SPN. Group Managed Service Accounts have their passwords managed automatically by Active Directory, 240-character randomly generated passwords that rotate on a schedule. An attacker can request the ticket all day long and never crack it.
gMSAs do require some setup and not every application supports them, but for SQL services, IIS application pools, scheduled tasks, and Windows services, they work well and eliminate the password management problem entirely.
Force AES Encryption, Disable RC4
For accounts that can't be migrated to gMSA right away, forcing AES encryption significantly raises the bar for offline cracking. Set the msDS-SupportedEncryptionTypes attribute to require AES only.
Keep in mind this only helps if the account also has a strong password. AES with a weak password is still crackable, it just takes longer.
Set Strong Passwords on Service Accounts
For any service account that must stay as a standard user account, the password needs to be long. The commonly cited minimum is 25 characters. At that length, even RC4 hashes become computationally expensive to crack. Use a password manager or PAM solution to generate and store these, a 25-character random password is not something you want to type manually or store in a spreadsheet.
After changing a service account password, make sure the service is updated and tested. A password change on an account running a Windows service, scheduled task, or IIS application pool requires updating the credentials in that service or it will fail to start.
Disable or Remove Stale Accounts
For any account you identified as no longer active, disable it first and confirm nothing breaks before deleting it. A disabled account with an SPN can still be targeted by Kerberoasting, so the final step is deletion once you've confirmed it's safe to remove.
Remediation Priority
Work through your findings in this order:
Remove SPNs from decommissioned accounts or delete the accounts entirely.
Migrate active service accounts to gMSA where supported.
Force AES encryption on accounts that can't be migrated yet.
Reset passwords to 25+ characters on remaining accounts.
Document everything for the next review.
Don't try to fix everything at once. In a production environment, service account changes carry real risk of outage if they're not coordinated with application owners. Work through the critical and high findings first, document the rest, and build a remediation plan with realistic timelines.
Detection, Are You Being Roasted Right Now?
Remediation takes time. While you're working through your findings, it's worth knowing whether someone is already taking advantage of what you have. The good news is that Kerberoasting does leave traces in your event logs, if you know where to look.
Event ID 4769, Kerberos Service Ticket Request
Every TGS ticket request generates a 4769 event on your Domain Controllers. This event logs the account that made the request, the service name, and critically, the encryption type used. This is your primary detection point.
On its own, 4769 is extremely noisy. Every user accessing every service generates one. The key is filtering for the specific conditions that indicate Kerberoasting activity:
Ticket Encryption Type = 0x17. This is RC4. In a modern environment, legitimate Kerberos traffic should be AES. An RC4 ticket request is not automatically malicious, but it warrants attention, especially from accounts that don't typically request service tickets.
A single account requesting tickets for multiple SPNs in a short window. Normal users request tickets for services they actually use. An attacker enumerating your environment will request tickets for every SPN they can find in rapid succession.
Requests from unexpected sources. A workstation account or standard user account suddenly requesting tickets for SQL service accounts or backup agent accounts is worth investigating.
To start monitoring for this on your Domain Controllers, make sure Advanced Audit Policy is configured to log Kerberos Service Ticket Operations:
Once enabled, you can query for suspicious RC4 ticket requests directly from PowerShell:
Deploy a Honeypot SPN Account
One of the most effective detection techniques is also one of the simplest. Create a dedicated user account with an SPN that has no legitimate purpose, nothing should ever request a ticket for it. Any 4769 event targeting that account is an immediate indicator of enumeration activity. Be sure to update the following with one of your own passwords.
Alert on any 4769 event where the ServiceName matches your honeypot account. A single hit on this account is enough to start an investigation.
What to Do When You See It
If you identify active Kerberoasting in your environment, the immediate priorities are:
Identify the source account and workstation from the ClientAddress field in the 4769 events.
Disable the source account and isolate the workstation pending investigation.
Reset passwords on any SPN accounts that were targeted.
Review what access the source account had and whether any service account credentials may have already been compromised.
Detection without response is just watching. If you have the logging in place, make sure someone is actually reviewing it, or feed these events into a SIEM and build an alert around the RC4 encryption type filter.
Putting It Together, A PowerShell Audit Workflow
The previous sections covered each piece individually. This section pulls it all together into a single script you can run on a schedule and use as the foundation for an ongoing Kerberoasting audit. The script finds all Kerberoastable accounts, assigns a risk tier based on what it finds, and exports a CSV report.
What the Script Does
Enumerates every user account with an SPN registered in AD.
Resolves encryption type to a human readable label.
Calculates password age in days.
Checks group membership against a list of privileged groups.
Assigns a risk tier of Critical, High, Medium, or Low based on the combination of those factors.
Exports a dated CSV to C:\Reports for review and documentation.
Suggested Cadence
Run this monthly as part of a regular AD security review. Service accounts get created, SPNs get added, and password hygiene drifts, a monthly check keeps you ahead of it. If your environment has a change management process, also consider running it after any major application deployment or AD infrastructure change.
Conclusion
Kerberoasting isn't a new attack. It's been a staple of Active Directory compromise since 2014 and it's still showing up in breach reports today, not because it's sophisticated, but because the conditions that enable it are extremely common in real environments. Service accounts with SPNs, weak passwords, and no expiration are the norm, not the exception.
The good news is that this is one of the more straightforward risks to address. You don't need expensive tooling or a security team to find it. A PowerShell script and read access to Active Directory is all it takes to get a complete picture of your exposure. From there, the remediation path is clear, remove unnecessary SPNs, migrate to gMSA where you can, force AES encryption, and get service account passwords to a length that makes offline cracking impractical.
The environments that get hurt are the ones where nobody looked. Run the audit script, work through your findings by risk tier, and put the detection logging in place so you know if someone is already enumerating your environment. That combination, find it, fix it, detect it, is what moves the needle on your actual security posture.
If you haven't already, check out my related posts on Active Directory Trust Security and AD Functional Levels for more on hardening your AD environment.
Comments