BIPI
BIPI

Kerberoasting in 2024: Why Service Accounts Still Hand Over Domain Admin

Cybersecurity

Kerberoasting remains the highest ROI move on most internal engagements because RC4 service tickets still leak from AES-capable forests. We walk the full attack and the detection pipeline that actually catches it.

By Arjun Raghavan, Security & Systems Lead, BIPI · November 4, 2024 · 8 min read

#active-directory#kerberos#pentest#detection-engineering

Almost every internal pentest report we ship has a Kerberoasting finding somewhere on page two. The attack is almost two decades old, the fix has been documented since Windows Server 2008, and yet the same SQL service account with a 2017 password keeps showing up in domain admin paths. The reason is operational: service account hygiene is hard, and most blue teams are still detecting the wrong event.

How attackers find this

Any authenticated domain user can request a service ticket for any account with a registered SPN. That ticket is partially encrypted with the service account's NTLM hash, which means anyone who can read it offline can brute force the password. There is no failed login, no lockout, and no privileged access required to start.

  • Enumerate SPNs with impacket-GetUserSPNs.py -request domain/user:pass to dump roastable hashes in hashcat format.
  • Rubeus.exe kerberoast /nowrap /outfile:hashes.txt from a beachhead host gives the same output without dropping Python.
  • Filter for accounts in privileged groups using BloodHound's Kerberoastable + High Value query before cracking. Cracking a tier-2 account that has Domain Admin via nested groups is the usual path.
  • Crack with hashcat -m 13100 -a 0 hashes.txt rockyou.txt -r rules/OneRuleToRuleThemAll.rule. RC4 hashes fall in minutes on a single GPU.

The accounts that crack are predictable: svc_sql with a name reused as the password, svc_backup with a 2018 rotation, sccm_naa, and anything that ends in _service or starts with svc_. We have cracked accounts that ended in CompanyName2019! more times than we can count.

What defenders see

The signature event is 4769, A Kerberos service ticket was requested. The high-fidelity filter is Ticket Encryption Type 0x17 (RC4-HMAC) requested for a service account, especially when the requesting account is a normal user. AES-only forests should never see RC4 tickets for compliant accounts, so a single 0x17 is enough to investigate.

  • Build a Splunk or Sentinel rule on EventCode=4769 TicketEncryptionType=0x17 ServiceName!=krbtgt and exclude known legacy service accounts explicitly.
  • Track per-user SPN request volume. A normal user requesting tickets for fifty SPNs in two minutes is the Rubeus signature.
  • Honeypot SPNs work. Create a high-privilege-looking account with an unguessable AES password and an SPN, then alert on any 4769 for it.

Remediation that actually works

The single highest-impact change is enforcing AES on every service account and removing RC4 from the supported encryption types. This is a checkbox on the user object: msDS-SupportedEncryptionTypes. When set correctly, the KDC refuses to issue RC4 tickets and the offline crack speed drops by orders of magnitude. Combined with a 25-character password, AES Kerberoasting is computationally impractical.

  1. Inventory every account with a non-empty servicePrincipalName. PowerShell: Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties msDS-SupportedEncryptionTypes,PasswordLastSet.
  2. Migrate every eligible service account to a Group Managed Service Account (gMSA). The 240-character auto-rotated password makes cracking irrelevant.
  3. For accounts that cannot move to gMSA, set a 25-character random password and force AES-only via msDS-SupportedEncryptionTypes = 0x18.
  4. Remove service accounts from Domain Admins, Account Operators, and other tier-zero groups. Service accounts almost never need DA. They need delegated rights on specific resources.
  5. Add the Protected Users group for human admins and explicitly forbid RC4 at the domain level via Group Policy: Network security: Configure encryption types allowed for Kerberos.

The combination that closes the door: gMSA where possible, AES-only enforcement, and a 4769 RC4 alert that pages the on-call engineer. Any pentester who walks into that environment has to find a different path.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.