Extracting service account passwords with Kerberoasting

Kerberoasting lets an attacker with any standard domain account request encrypted tickets for service accounts and then crack their passwords offline, where no lockout policy applies and the domain controller isn't involved.

It succeeds against weakly protected accounts, and 76% of organizations don't fully govern or monitor non-human identities, including service accounts, according to the Netwrix 2026 Data and Identity Security Report.

The attack starts with a list of those accounts, which an attacker can build through LDAP reconnaissance.

What is Kerberoasting?

Kerberoasting is an Active Directory (AD) attack that turns a normal Kerberos feature into a password-cracking opportunity. Kerberos lets any authenticated user request a service ticket from a domain controller, and the ticket is encrypted with a key derived from the service account's password.

An attacker who collects those tickets can guess passwords against them offline until one decrypts. The targets are user accounts with service principal names (SPNs), including most service accounts. The attack needs no elevated rights to start.

How attackers extract service account passwords with Kerberoasting

Extraction runs in four steps, and Rubeus and Impacket's GetUserSPNs.py combine the first three into one command while Hashcat handles the fourth.

1. Find the accounts that have SPNs

An SPN names a service instance in three parts, as in MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand, which gives the service class, the host, and the port. The service class hints at what a cracked account can reach, such as database access for MSSQLSvc.

An attacker with any domain account can list accounts with SPNs via an LDAP query, a PowerShell query, or the Active Directory module for PowerShell. Rubeus and GetUserSPNs.py also enumerate kerberoastable accounts on their own, and Rubeus can report statistics about them without sending ticket requests.

2. Request service tickets for the SPNs

Kerberos proves identity and leaves authorization to the service (RFC 4120), so the domain controller doesn't check whether the requester may use the service before issuing a ticket. Any authenticated user therefore receives a ticket encrypted with a key derived from the service account's password.

Two lines of PowerShell request a ticket for a named SPN, and Windows stores it in memory.

      Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'MSSQLSvc/jefflab-sql02.jefflab.local:1433'
      

Rubeus automates the request for every kerberoastable account and can write the results to a file.

      Rubeus.exe kerberoast /outfile:hashes.txt
      

Impacket's GetUserSPNs.py does the same with its -request option, which outputs the tickets in a format that John the Ripper and Hashcat accept.

      GetUserSPNs.py DOMAIN/user:<password> -dc-ip <DC IP> -request -outputfile hashes.txt
      

When an account with Kerberos pre-authentication disabled exists, Rubeus's /nopreauth option requests service tickets by sending AS-REQ (Authentication Service Request) messages through it.

3. Extract the service tickets

A ticket requested with the PowerShell lines above sits in memory until the attacker exports it. Mimikatz lists the tickets in the current session and writes them to files for offline cracking with a single command.

      kerberos::list /export
      

Rubeus and GetUserSPNs.py with -request skip this step, because they output crackable hashes directly.

4. Crack the tickets

Cracking runs on the attacker's own hardware, so no lockout policy applies, and the domain controller sees nothing after the ticket request. Hashcat tests password guesses against each ticket and recovers the cleartext password when a guess decrypts it. It accepts the format that GetUserSPNs.py outputs, and it has a separate mode for each encryption type.

Why the ticket encryption type matters

A ticket's encryption type, RC4 (Rivest Cipher 4) or AES (Advanced Encryption Standard), determines how quickly an attacker can guess it, and Microsoft changed its defaults in 2026.

RC4 tickets crack fastest

An RC4 ticket's key is the account's NT LAN Manager (NTLM) hash, an unsalted hash of the password (RFC 4757). Without a salt, the same password produces the same key for every account, and each guess costs one hash computation.

Attackers can request RC4 for accounts that support AES

Rubeus requests each account's highest supported encryption type by default, but its /usetgtdeleg option requests RC4 tickets for accounts that support AES, and its /rc4opsec option skips AES-enabled accounts.

Impacket's GetUserSPNs.py also asks for RC4 by default unless -no-rc4 is set. Removing RC4 from the service account's supported encryption types closes that downgrade path.

AES tickets slow guessing but still fall to weak passwords

AES keys come from a salted key derivation that runs 4,096 iterations by default (RFC 3962), making each guess more expensive. Rubeus's /aes option targets AES-enabled accounts and requests their AES tickets, and Hashcat has a separate mode for each ticket encryption type.

All three types are crackable, so password length and randomness decide the outcome.

The April 2026 update changed the domain controller default

Microsoft's update KB5073381 began with audit events in January 2026. On April 14, 2026, it changed the domain controller default so that accounts with no explicit msDS-SupportedEncryptionTypes value are assumed to support only AES-SHA1, and updates released in or after July 2026 no longer support the registry value that let administrators roll the change back.

The change doesn't touch accounts that explicitly allow RC4 through that attribute, and a domain default that was set explicitly is honored as written. Those accounts can still receive RC4 tickets, so they're the ones to find first.

Protecting service accounts from Kerberoasting

Each control limits a different part of the attack, and all use native Active Directory and Windows features.

Move service accounts to managed accounts

Group managed service accounts (gMSAs) use 120-character random passwords that Active Directory rotates, so attackers have nothing weak to guess. Delegated managed service accounts (dMSAs) also have Active Directory manage the credential.

Netwrix research on the BadSuccessor attack, which abuses dMSAs for privilege escalation, recommends auditing who holds CreateChild, WriteProperty, WriteDACL, GenericAll, and WriteOwner rights on organizational units before deploying them.

Set long random passwords on the rest

For accounts that can't move, MITRE ATT&CK recommends passwords of ideally 25 or more characters. Random generation matters as much as length, because cracking wordlists are built from passwords people choose.

Reset passwords and enforce AES

AES keys are generated when a password is set or changed, so an account whose password predates AES support has none until it's reset, and an AES-only account without them can't receive tickets.

Reset the password first, then check the account's msDS-SupportedEncryptionTypes attribute for explicit RC4 settings and restrict it to AES128 and AES256 (value 24).

      Set-ADUser <account> -Replace @{'msDS-SupportedEncryptionTypes'=24}
      

Test each service before restricting it, because services that don't support AES, including some non-Windows devices, stop authenticating once RC4 is removed.

Remove SPNs that accounts don't need

Every SPN on a user account makes that account requestable, so list them all and compare each against a running service.

      Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties ServicePrincipalName | Select-Object SamAccountName, ServicePrincipalName
      

The krbtgt account appears in the results by design and isn't something to change. For any other SPN that points to a decommissioned host or a retired application, check it with setspn -L <account>Expand and delete it with setspn -D <SPN> <account>Expand.

Control who can add SPNs

In targeted Kerberoasting, an attacker with GenericAll, GenericWrite, WriteProperty, or Validated Write to Service Principal Name rights on an account adds an SPN to it, making the account roastable. Review the access control lists on service accounts and remove those rights from anyone who doesn't manage the account. Members of the built-in Account Operators group usually hold them.

Limit service account privileges

A cracked password gives an attacker whatever the account can do. Remove service accounts from privileged groups such as Domain Admins, and grant only the rights the service uses, under the principle of least privilege. That work belongs to broader Active Directory security hardening.

Log service ticket requests

Enable the Audit Kerberos Service Ticket Operations subcategory on domain controllers, which logs each request as Event ID 4769. MITRE advises watching for anomalous requests that use RC4, shown as Ticket Encryption Type 0x17, while AES tickets show 0x11 or 0x12.

Roasting through an account without pre-authentication sends AS-REQ messages instead, so those requests log as Event ID 4768, and the same RC4 check applies to them.

Microsoft's Kerberos-Crypto repository includes a Get-KerbEncryptionUsage.ps1 script that reads both event types, and running it with -Encryption RC4 and -SearchScope AllKdcs lists RC4 requests across every domain controller.

How Netwrix helps defend against Kerberoasting

Netwrix products add three controls beyond native Windows settings: blocking the attack, detecting what follows, and assessing Active Directory for the weaknesses it exploits.

Block Kerberoasting attempts in real time

Netwrix Threat Prevention stops Kerberoasting, DCSync, and Pass-the-Hash attempts against Active Directory before they succeed. That gives teams an enforcement point at the moment of attack, which log review can't provide.

Detect identity-based attacks

Netwrix Threat Manager identifies credential theft, lateral movement, and privilege escalation, which are identity-based attacks that can follow a cracked service account password. It also detects when an SPN is added to a privileged account, the setup step of targeted Kerberoasting.

Assess Active Directory security posture

Netwrix PingCastle scores Active Directory security and identifies misconfigurations, attack paths, and privilege exposure.

Start with the accounts that still allow RC4

Kerberoasting needs only one weak service account password, so defense works best as a sequence applied account by account.

After Microsoft's April 2026 default change, accounts that explicitly allow RC4, either on the account or through an explicitly set domain default, can still receive RC4 tickets, so they come first. Move what can move to managed accounts, then reset the rest and restrict them to AES.

Accounts that can't move to managed accounts need long, random passwords to outlast offline guessing. The ticket request is the one step defenders can still observe, so logging it covers what password hygiene can't.

Request a demo to see how Netwrix Threat Prevention stops Kerberoasting attempts against your Active Directory service accounts before they succeed.