Kerberoasting Explained: How to Find and Fix Roastable Accounts in Active Directory

Get-ADUser -Filter 'servicePrincipalName -like "*" -and Enabled -eq $true' |
    Where-Object SamAccountName -ne 'krbtgt' |
    Select-Object SamAccountName, DistinguishedName

What Kerberoasting is

Services like SQL Server, IIS app pools and backup software often run under a domain user account. To let users authenticate to those services with Kerberos, the account gets a service principal name (SPN), something like MSSQLSvc/sql01.contoso.com:1433.

When a user wants to connect, their machine asks a domain controller for a service ticket for that SPN. The DC encrypts part of the ticket with a key derived from the service account's password. That's how the service knows the ticket is real. It's also the problem. Anyone holding the ticket can take it offline and keep guessing passwords until one produces the right key.

That's worse than an ordinary password attack for two reasons:

• Any domain user can do it. Requesting a service ticket is normal Kerberos behavior. The DC doesn't check whether you're actually allowed to use the service.
• The guessing happens offline. No failed logons, no lockouts and nothing in the DC's logs while the guessing runs.

Add the fact that service account passwords tend to be set once by a person and never changed, because nobody wants to break the app. That's why this attack has lasted so long.

Not every account with an SPN is realistically at risk. Computer accounts and group managed service accounts (gMSAs) have long random passwords that Windows rotates for them. The risk is user accounts with SPNs, where a person picked the password.

Insight Recon flags every enabled user account with an SPN, since any domain user can request a ticket for it.

Why Kerberoasting is risky

Service accounts tend to have more access than anyone remembers. A SQL service account might be local admin on every database server. A backup account might be able to read everything. It's not unusual to find a service account sitting in Domain Admins because that was the quickest way to make something work years ago. MITRE's mitigation for Kerberoasting calls out exactly that. Crack that password and the attacker has all of it.

The encryption type matters too. RC4 tickets are much faster to guess against than AES ones. Microsoft says RC4 "uses no salt or iterated hash," which speeds up guessing. Since the 2026 updates, domain controllers no longer fall back to RC4 for accounts without encryption types set, unless a DC's domain-wide default still includes RC4. Any account still explicitly allowed RC4 keeps getting RC4 tickets, though. And AES doesn't save a weak password. In Microsoft's words, "AES alone is not a solution for brute forcing and needs to be used in combination with strong passwords."

Kerberoasting vs AS-REP roasting

They sound alike and both end in offline password guessing. The difference is what makes an account a target and what the attacker needs first.

Our AS-REP roasting post covers the other one.

Kerberoasting in real attacks

Kerberoasting went public at DerbyCon in 2014, when Tim Medin presented it. MITRE tracks it as T1558.003 and lists groups from FIN7 to the Ryuk ransomware operators using it, along with APT29 during the SolarWinds intrusion.

The best-known recent case is Ascension, one of the largest hospital systems in the US. In September 2025, Senator Ron Wyden asked the FTC to investigate Microsoft over the ransomware attack. Per his letter, a contractor clicked a malicious link. The attackers then used Kerberoasting to take over privileged accounts in Ascension's Active Directory. From there they pushed ransomware to thousands of computers and stole data on 5.6 million patients.

Microsoft has been pushing back on the attack for a while. In October 2024 it published guidance to help mitigate Kerberoasting. Then in 2026 it removed the silent RC4 fallback for service tickets. Both help. Neither fixes a service account with a short password a person picked, which is still the heart of the problem.

How attackers use it

Once an attacker has any domain account, often from a phished user, they ask AD which user accounts have SPNs. Any user can see that. They request service tickets for those accounts, prioritizing the privileged ones and the ones with old passwords. Then they take the tickets offline and guess.

From the defender's side, you can see the lookup and the requests. Defender for Identity can alert on SPN enumeration. The ticket requests show up on your domain controllers as event 4769. The guessing happens on the attacker's own hardware. If the password falls, the attacker logs on as the service account with whatever rights it has.

Find Kerberoastable accounts

List the accounts at risk

This lists every enabled user account with an SPN, with the details that decide how much risk each one carries: password age, whether the account has been in a protected admin group, its Kerberos encryption types and its SPNs. Run it as any domain user with the ActiveDirectory module.

Import-Module ActiveDirectory
Get-ADUser -Filter 'servicePrincipalName -like "*" -and Enabled -eq $true' `
    -Properties servicePrincipalName, PasswordLastSet, adminCount, 'msDS-SupportedEncryptionTypes' |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    ForEach-Object {
        $et = $_.'msDS-SupportedEncryptionTypes'
        [pscustomobject]@{
            Account         = $_.SamAccountName
            PasswordAgeDays = if ($_.PasswordLastSet) { (New-TimeSpan -Start $_.PasswordLastSet).Days }
            Privileged      = $_.adminCount -eq 1
            EncTypes        = if ($et) { '0x{0:X}' -f $et } else { 'not set' }
            SPNs            = $_.servicePrincipalName -join '; '
        }
    } | Sort-Object Privileged, PasswordAgeDays -Descending

What to look for:

• Privileged True: the account is, or was, in a protected group like Domain Admins. These come first. Note that adminCount can stay at 1 after an account leaves the group. Confirm current membership.
• High PasswordAgeDays: an old password is more likely to be weak and more likely to be known by people who've left.
• EncTypes with the 0x4 bit set, like 0x1C: RC4 is explicitly allowed. The account still gets the faster-to-guess tickets. 0x18 means AES only. "not set" follows the domain default, which is AES only on domain controllers with the 2026 updates unless someone has added RC4 back to that default.

Check whether you use gMSAs

Get-ADServiceAccount -Filter * | Select-Object Name, ObjectClass, Enabled

What to look for: msDS-GroupManagedServiceAccount is a gMSA, msDS-ManagedServiceAccount is an older standalone MSA and msDS-DelegatedManagedServiceAccount is a dMSA. No output means nobody has created any managed service accounts yet. Every service account on the list above is a candidate to move.

Watch for Kerberoasting in your logs

Domain controllers log event 4769 for every service ticket request, as long as Audit Kerberos Service Ticket Operations is on for Success. This finds service tickets issued with RC4 (0x17) and counts them per requesting account. Run it as an admin or a member of Event Log Readers on the DC:

$xpath = "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 1000 -ErrorAction SilentlyContinue |
    ForEach-Object {
        $d = @{}
        ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [pscustomobject]@{ Requester = $d.TargetUserName; Service = $d.ServiceName }
    } |
    Group-Object Requester | Sort-Object Count -Descending | Select-Object Count, Name

What to look for: RC4 tickets should be rare now. One account requesting tickets for lots of different services in a short window is the pattern Microsoft and MITRE both call out. So is a user suddenly asking for tickets to services they've never touched. Feed 4769 into your SIEM so you can see this across every DC.

Check it with Insight Recon

The commands above are the manual way. Insight Recon's read-only Active Directory security assessment covers Kerberoasting from a few angles, along with 150+ other checks:

• Accounts Vulnerable to Kerberoasting (High): lists every enabled user account with an SPN that any domain user could request a ticket for.
• Accounts with SPNs Not Supporting AES (Moderate): flags roastable accounts that can still get RC4 tickets.
• Kerberos Pre-Authentication In Use (Critical): the AS-REP roasting side of the same problem.
• DES/RC4 Support Enabled (Moderate): flags domain controllers that still advertise RC4 for Kerberos.
• gMSA Not In Use (Low): flags domains with no gMSAs at all.

Every finding comes with the attacker context and the remediation steps. Want to see what one looks like first? Here's a sample report.

How to fix Kerberoastable accounts

Remove SPNs nobody needs

Start with the easy wins. Old SPNs pile up on user accounts from retired servers, test installs and services that moved. If an account doesn't need to accept Kerberos logons, it doesn't need an SPN. Check with the app owner, then remove it:

Set-ADUser -Identity svc-oldapp -ServicePrincipalNames @{ Remove = 'HTTP/oldapp.contoso.com' }

No SPN, no ticket to request. That account drops off the list.

Move services to gMSAs

Group managed service accounts are the real fix. Windows generates a long random password for them, 120 characters according to Microsoft. It also rotates the password automatically. Nobody knows it and nobody has to manage it. Most Windows services, scheduled tasks and IIS app pools support them. So does SQL Server, from 2014 for standalone instances and 2016 for clusters and availability groups. On Windows Server 2025, delegated managed service accounts (dMSAs) can replace an existing service account.

# One-time per domain, if you've never used gMSAs
Add-KdsRootKey -EffectiveImmediately

New-ADServiceAccount -Name gmsa-sql01 -DNSHostName gmsa-sql01.contoso.com `
    -PrincipalsAllowedToRetrieveManagedPassword 'SQL-Servers' `
    -ServicePrincipalNames 'MSSQLSvc/sql01.contoso.com:1433'

Even with -EffectiveImmediately, other domain controllers can't use the key until it replicates. Microsoft says to allow up to 10 hours. Do that step ahead of time. Keep PrincipalsAllowedToRetrieveManagedPassword tight. Only the servers that run the service should be in it.

Fix the accounts that have to stay

Some apps can't use a gMSA. For those:

• Long random password. MITRE recommends 25 or more characters. Generate it, store it in a vault and rotate it on a schedule. Microsoft's floor is 14 characters. Longer is better.
• AES only. Set the account to AES and then reset the password so it's guaranteed to have AES keys. Accounts whose password hasn't changed in a very long time may not have them. Our RC4 post covers this in detail.
• Least privilege. Take service accounts out of Domain Admins and other privileged groups. Give them only the rights the service needs, on the servers it runs on.
• Restrict where it can log on. Deny interactive and Remote Desktop logon for service accounts. A guessed password is less useful if it can't be used at a console.

Set-ADUser -Identity svc-legacy -KerberosEncryptionType AES128, AES256
# Then reset the password so the account gets AES keys

Keep watching

Keep 4769 flowing into your SIEM and alert on RC4 tickets and bursts of requests from one account. Review accounts with SPNs every quarter. New ones show up every time someone installs an app with a service account.

Take service account passwords off the table

Kerberoasting works because service accounts are the passwords nobody wants to touch. Find every user account with an SPN and drop the ones nobody needs. Move what you can to gMSAs. Then give the rest long random passwords and keep them out of privileged groups.

Validation checklist

• Have you listed every enabled user account with an SPN?
• Have unneeded SPNs been removed?
• Are services that can use a gMSA using one?
• Do the remaining service accounts have long random passwords in a vault?
• Are they set to AES only, with a password reset since?
• Are any of them still in Domain Admins or other privileged groups?
• Are you alerting on 4769 for RC4 tickets and request bursts?

A no on any of these leaves a service account password that someone can guess offline.

Compliance mapping

Kerberoasting is a credential problem first. It lines up with the frameworks like this:

FAQ

References

• Microsoft Security Blog: Microsoft's guidance to help mitigate Kerberoasting
• MITRE ATT&CK: T1558.003, Kerberoasting
• Microsoft Learn: Event 4769, a Kerberos service ticket was requested
• Microsoft Learn: Group Managed Service Accounts overview
• Senator Wyden's letter to the FTC on the Ascension breach