PW-006Attack pathKerberos, passwords and credentials

Kerberoastable account with Tier Zero access

An account with a service principal name is in Tier Zero or has a path to it, and its password can be attacked offline by any domain user.

Category: Attack Path
Severity: From exposure.
Typical owner: AD / identity team with the service owner
Data needed: Any collection: SPNs and group memberships are readable by any domain user.

MITRE ATT&CKT1558.003

Most useful toDefensive engineers Identity and access engineers Offensive operators

On this page

In plain language

Accounts that run services get a service principal name (SPN). Any domain user may ask for a Kerberos ticket to such a service, and part of that ticket is encrypted with a key made from the service account's password. An attacker can take the ticket away and guess the password offline, as fast as their hardware allows, where no lockout policy or log sees the guesses. This is called Kerberoasting.

Service account passwords are often old and chosen by a person, so they are often cracked. When the account is privileged, cracking one password means owning the domain. Group Managed Service Accounts (gMSAs) remove the risk: their passwords are long, random and rotated automatically.

What Pathwarden flags

A user account with a service principal name (SPN) is in Tier Zero or has a path to it. Any domain user can request a Kerberos service ticket for it, and that ticket is encrypted with a key derived from the account's password.

Group and standalone managed service accounts (gMSA, sMSA) are not reported: the domain gives them a 240-byte (120-character) random password and rotates it, so their tickets can't be cracked. In SharpHound collections Pathwarden recognizes them from the gmsa and msa flags; in RustHound-CE and built-in collections, which have no such flag, from the computer-account bit (userAccountControl 0x1000) on a user object. In those collections a user account an administrator gave the computer-account bit by hand, which still has a human-set password, is treated as managed and not reported: check SPN accounts with that bit (Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=4096)") if you collect with RustHound-CE or the built-in collector.

How attackers use it

Kerberoasting (Steal or Forge Kerberos Tickets: Kerberoasting, T1558.003) needs only a normal domain account: request tickets for every SPN, take them offline and crack the passwords. Service account passwords are often old, human-chosen and never rotated, and RC4 tickets crack quickly. A cracked privileged service account means domain compromise without any alert on the target.

Find it with Pathwarden

Data needed: Any collection: SPNs and group memberships are readable by any domain user.

In the web UI or the HTML report, open the Findings tab and expand PW-006: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-006
# the step-by-step guide on this page, offline
pathwarden guide PW-006
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-006

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Identify the service using the SPN (setspn -L <Account>), the computers running it, and who owns it.
Check whether the SPN is still used: event 4769 on domain controllers shows service ticket requests for the account. No requests over weeks often means a stale SPN.
If the account is privileged only because of a group it does not need (common for old SQL service accounts in Domain Admins), removing that membership is part of the fix.

How to fix it

Option A: Move the service to a group Managed Service Account (recommended)

Create a gMSA (New-ADServiceAccount) allowed for the service's computers.
Install it on the computers (Install-ADServiceAccount) and change the service to run as <Domain>\<gMSA>$ with an empty password.
Move the SPNs to the gMSA, then disable the old account. gMSA passwords are 240-byte (120-character) random values rotated automatically: not crackable.

Option B: Remove unneeded SPNs or privileges

Remove stale SPNs with setspn -D, and remove the account from privileged groups it does not need.

Option C: If the account must stay

Set a random password of 25+ characters, enable AES-only Kerberos for the account ("This account supports Kerberos AES 128/256 bit encryption" in ADUC Account tab), then change the password once more so the account has AES keys: a password set before the domain supported AES has none, and with AES only the service stops working. Rotate the password on a schedule after that.

PowerShell

Import-Module ActiveDirectory

# Kerberoastable user accounts
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName, PasswordLastSet, MemberOf

# Option A: create a gMSA (needs a KDS root key in the forest)
New-ADServiceAccount -Name "<gMSA>" -DNSHostName "<gMSA>.<Domain>" `
    -PrincipalsAllowedToRetrieveManagedPassword "<ServerGroup>"
Install-ADServiceAccount -Identity "<gMSA>"     # run on each service computer

# Option B: remove a stale SPN
setspn -D <SPN> <Account>

# Option C: AES only (0x18 = AES128 + AES256), then reset the password
Set-ADUser -Identity "<Account>" -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }
Set-ADAccountPassword -Identity "<Account>" -Reset -NewPassword (Read-Host -AsSecureString "New password")

Verify the fix

Get-ADUser "<Account>" -Properties ServicePrincipalName shows no SPNs (Options A/B), or msDS-SupportedEncryptionTypes is 24 and PasswordLastSet is recent (Option C). Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

Re-register an SPN with setspn -S <SPN> <Account>; switch the service back to the old account in the Services console. Keep the old account disabled, not deleted, until the gMSA has run cleanly for a while.

References

Microsoft: Group Managed Service Accounts overviewlearn.microsoft.com
MITRE ATT&CK T1558.003: Steal or Forge Kerberos Tickets: Kerberoastingattack.mitre.org