I Attacked My Own Active Directory Lab — Here’s Exactly How Kerberoasting Works (and How to Catch It)

Imagine walking through a high-security bank while the guards hand you the vault keys just for asking nicely.

When it comes to cybersecurity, we are trained to look for anomalies — sudden spikes in traffic, unauthorized software installations, or repeated failed login attempts. But the highest risk comes from techniques that convert legitimate, everyday network requests into weapons.

That’s where Kerberoasting comes in.

This post-exploitation technique allows an attacker with standard, low-level access to steal the cryptographic hashes of highly privileged service accounts. Because the attack exploits the fundamental design of the Kerberos authentication protocol rather than a software bug, it is incredibly difficult to detect.

I wanted to see it happen end-to-end in a lab I built myself:- run the attack, crack the password, and then write a detection rule that actually catches it. Here’s what I found, and what it taught me about defending against it.

The Setup

I run a home SOC lab having six VMs including a Windows Server domain controller, a Kali Linux attack box, endpoint workstations, and a Wazuh SIEM ingesting logs from everything. For this attack, I deliberately left a weak point in the environment: a service account called svc_backup, registered with a Service Principal Name (SPN) and given a password that could be cracked without much effort.

Why Any Domain User Can Do This

Here’s the part that surprised me the first time I actually understood it: Kerberoasting doesn’t require any special privilege escalation or exploit. Any domain user — even one with zero administrative privileges — can ask the Domain Controller for a Ticket Granting Service (TGS) ticket to talk to a specific service. That is not a flaw. It’s just how Kerberos is designed to work, because services need to prove who they are.

Here’ s the catch: because that ticket is encrypted with the service account’s password hash, you can take it offline to crack it. With no rate limits and zero risk of tripping a lockout policy, you can guess passwords indefinitely without ever touching the domain controller again.

Running the Attack

Using a low-privilege account (jsmith), I asked the domain controller for tickets for every SPN-registered account using Impacket's GetUserSPNs tool. It found svc_backup immediately and handed back a ticket.

I saved that ticket and ran it through Hashcat, targeting Kerberos TGS-REP hashes specifically. Within a short cracking run, the plaintext password came back: Back2024! — a password pattern that's common enough in real environments that this isn't a contrived scenario.

At that point, I had full credentials for a service account. In a real environment, service accounts like backup or scheduled-task runners are often far more privileged than people realize, which makes kerberoasting a genuinely dangerous foothold, rather than just a theoretical risk.

Catching It: The Part Most Write-Ups Skip

This is the piece I actually cared most about. If you look up how to detect Kerberoasting, 90% of guides give you the exact same advice: “Enable auditing and look for Event ID 4769 (A Kerberos service ticket was requested).”

But it’s not that simple, right? Event ID 4769 happens thousands of times a day in a normal network. Every time a legitimate user opens an Outlook client, connects to a file share, or hits an internal website, a 4769 event is generated. If you just alert on that ID, your SIEM will drown you in false positives, and your security team will quickly mute the alert.

The actual signature of Kerberoasting is more specific: attackers deliberately request tickets using older RC4 encryption instead of the modern AES default, RC4 hashes can be cracked significantly faster. That single detail — ticket encryption type 0x17 on a service ticket request (Windows Event ID 4769) — is a far more precise indicator than the ticket request itself.

I wrote a custom Wazuh rule to fire specifically on that combination: a 4769 event with RC4 encryption. When I ran the attack again to confirm, the rule caught it immediately.

What This Actually Means for Defense

Kerberoasting cannot be prevented outright; by design, accounts with registered SPNs must be able to issue tickets to facilitate normal network operations. Because of this architectural necessity, effective defense relies on pulling four specific defensive levers:

• Enforcing Password strength on service accounts. A 25+ character random password, or better, a Group Managed Service Account (gMSA) that rotates its own password automatically, makes offline cracking practically pointless.
• Deprecate Legacy Cryptography: Force AES encryption domain-wide for all Kerberos communications to completely eliminate weak RC4 ciphers from your environment.
• Target High-Fidelity Event Logs: Shift away from broad ticket-request alerts and focus detection logic specifically on Event ID 4769 where legacy RC4 encryption (0x17) is explicitly requested.
• Conduct Routine SPN Audits: Regularly auditing which accounts have SPNs, since it’s common for old or forgotten service accounts to carry SPNs no one remembers assigning.

The Bigger Lesson

Ultimately, the most valuable part of this exercise wasn’t dissecting Kerberoasting — it was the shift in mindset. It reinforced the importance of building detections tailored to a specific technical signature rather than a generic event, and the absolute necessity of testing that logic to ensure it isn’t silently failing. Overcoming the assumption that “no alert fired” equals “no attack happened” is exactly the milestone that elevates a security practitioner from just running tools to thinking like a true detection engineer.

This investigation was documented as part of a structured home SOC lab, including full incident reports, MITRE ATT&CK mapping, and detection rule development. Full write-ups are available on GitHub.