Kerberos attacks - from AS-REP Roasting to Golden Ticket

Kerberos has been the default authentication protocol in Active Directory since Windows 2000. Designed at MIT in the 1980s, it was meant to solve the problem of secure authentication across untrusted networks. After more than 25 years of operation in production environments, we know its weaknesses well - and we regularly exploit them during penetration tests to show clients the real risk.

This article is not a hacking tutorial. It is written from the perspective of defenders and security teams who want to understand how attackers exploit Kerberos in order to better protect their environments.

How Kerberos works - the minimum you need to understand the attacks

Kerberos authentication relies on three elements:

1. KDC (Key Distribution Center) - a domain controller role that issues tickets
2. TGT (Ticket Granting Ticket) - a “ticket for tickets,” confirming user identity
3. TGS (Ticket Granting Service) - a ticket granting access to a specific service

Simplified flow:

Step	Message	Description
1	AS-REQ	Client sends authentication request to KDC
2	AS-REP	KDC returns TGT encrypted with the krbtgt account key
3	TGS-REQ	Client presents TGT and requests a service ticket
4	TGS-REP	KDC returns TGS encrypted with the service account key
5	AP-REQ	Client presents TGS to the target service

Each of these steps has specific vulnerabilities that attackers have learned to exploit.

AS-REP Roasting - attacking steps 1 and 2

How it works: If an AD account has the “Kerberos Pre-Authentication” option disabled (DONT_REQUIRE_PREAUTH flag), any user on the network - even without domain credentials - can request an AS-REP ticket for that account. The KDC response contains an encrypted portion that can be subjected to offline cracking.

Why accounts have pre-auth disabled: Most often this is the result of migrations from older systems, misconfiguration, or applications that do not support preauthentication. In our audits, we find such accounts in roughly 30-40% of environments.

Detection:

• Monitor EventID 4768 with status code 0x0 (success) and encryption type RC4 (0x17)
• Microsoft Defender for Identity generates a “Suspected AS-REP Roasting activity” alert
• Look for anomalies - a high number of AS-REQ requests from a single source in a short time

Prevention:

• Enable Kerberos Pre-Authentication for all accounts:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Set-ADAccountControl -DoesNotRequirePreAuth $false

• Use strong, long passwords (25+ characters) for accounts that must have pre-auth disabled
• Switch to AES encryption instead of RC4

Kerberoasting - attacking steps 3 and 4

How it works: Any authenticated domain user can request a TGS ticket for any service registered in AD (having an SPN - Service Principal Name). The TGS ticket is encrypted with the service account password hash. The attacker retrieves the ticket and cracks it offline - without triggering account lockout, without needing to communicate with the domain controller.

Why it is so effective: Requesting a TGS ticket is a normal Kerberos operation. It does not generate alerts in a standard configuration. And service accounts often have weak passwords unchanged for years. In our penetration tests, we manage to crack service account passwords in over 60% of cases - typically within a few hours.

Detection:

• Monitor EventID 4769 with encryption type RC4 (0x17) - modern systems should use AES
• Look for multiple TGS requests from a single account in a short time (a roasting sweep)
• Defender for Identity detects the “Suspected Kerberos SPN exposure” pattern
• In Advanced Hunting in Microsoft Defender XDR, create rules correlating AS requests with TGS requests

Prevention:

• Deploy Group Managed Service Accounts (gMSA) - automatic rotation of strong passwords
• For accounts that must have classic SPNs - passwords of at least 25 characters, rotation every 90 days
• Enforce AES encryption for Kerberos, disable RC4 where possible
• Regularly audit accounts with SPNs

For more on service account password security, see our article Password security - why 22% of breaches start with stolen credentials.

Silver Ticket - a forged service ticket

How it works: If an attacker knows the password hash of a service account (e.g., obtained through Kerberoasting), they can independently generate a TGS ticket for the service handled by that account - without communicating with the KDC. Such a forged ticket is called a Silver Ticket.

What the attacker gains: Access to a specific service with arbitrary privileges. For example, a Silver Ticket for a SQL Server service account allows authentication as a database administrator. A Silver Ticket for a computer account allows access to that server’s resources.

Limitations: A Silver Ticket works against only one service. It does not grant access to the entire domain. The ticket expires according to the Kerberos policy (default 10 hours).

Detection:

• A Silver Ticket does not generate a request on the domain controller - detection requires monitoring on the target host
• Look for logons with tickets that have no corresponding TGS requests on the DC
• PAC (Privilege Attribute Certificate) validation on the target server can detect a forged ticket

Prevention:

• Protect service account passwords (gMSA, strong passwords with rotation)
• Enable PAC validation on critical servers
• Monitor anomalies in service logons

Golden Ticket - the key to the kingdom

How it works: A Golden Ticket is a forged TGT generated using the KRBTGT account hash. The KRBTGT account is a special Active Directory account whose key is used to encrypt and sign all TGT tickets in the domain. An attacker with the KRBTGT hash can generate a TGT for any user - including non-existent ones - with arbitrary privileges.

How attackers obtain the KRBTGT hash:

• DCSync attack (requires replication rights - typically Domain Admin)
• Extraction from domain controller memory
• ntds.dit backup

Why this is critical: A Golden Ticket gives the attacker full control over the domain, works even after user passwords are changed, and is valid for the default ticket lifetime (10 hours) but can be generated repeatedly as long as the KRBTGT hash remains unchanged. Worse yet, the KRBTGT hash must be changed twice (AD stores both current and previous hashes), and in many organizations the KRBTGT password has not been changed since domain creation.

Detection:

• Defender for Identity detects Golden Tickets based on ticket anomalies (e.g., lifetime longer than domain policy)
• Monitor EventID 4769 with SPN “krbtgt” - normal systems rarely request this
• Correlate logons with TGTs that have no corresponding AS-REQ requests

Prevention:

• Regular KRBTGT password rotation (minimum every 180 days)
• Protect domain controllers from unauthorized access (tiering)
• Monitor replication rights (DCSync)

Kerberos delegation abuse

Kerberos delegation allows a service to act on behalf of a user against other services. There are three variants:

Delegation type	Risk	Control
Unconstrained	Critical - server stores user TGT	Eliminate everywhere except DC
Constrained	Medium - limited to specified services	Audit the allowed services list
Resource-Based Constrained (RBCD)	Low-medium - controlled by target resource	Monitor changes to msDS-AllowedToActOnBehalfOfOtherIdentity attribute

Unconstrained Delegation attack: The attacker compromises a server with UC, then forces domain controller authentication (Printer Bug, PetitPotam) and captures its TGT. We describe this problem in detail in the article Active Directory - most common misconfigurations.

RBCD attack: An attacker with write permissions to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer account can configure delegation allowing a controlled account to impersonate any user against that computer.

Prevention:

• Eliminate Unconstrained Delegation
• Add critical accounts to the Protected Users group
• Monitor delegation configuration changes

The attack chain - how these techniques combine in practice

In real penetration tests, we rarely use a single technique. A typical Kerberos attack chain looks like this:

1. Reconnaissance - identify accounts without preauthentication (AS-REP Roasting) and accounts with SPNs (Kerberoasting)
2. Credential harvesting - offline cracking of AS-REP or TGS tickets
3. Escalation - use compromised service account for further lateral movement
4. Persistence - DCSync and Golden Ticket generation

Breaking this chain at the earliest possible stage is the key to defense.

Checklist: Protecting Kerberos in Active Directory

• Pre-Authentication enabled for all accounts (no DONT_REQUIRE_PREAUTH flags)
• Accounts with SPNs use gMSA or have 25+ character passwords with regular rotation
• AES encryption enforced, RC4 disabled (where possible)
• KRBTGT password changed every 180 days (double rotation)
• Unconstrained Delegation eliminated (except DC)
• Protected Users Group used for privileged accounts
• EventID 4768, 4769, 4771 monitored with anomaly alerts
• Defender for Identity or equivalent tool deployed
• Constrained Delegation audited quarterly
• Delegation attribute changes monitored (EventID 5136)

When Kerberos fails, attackers switch to NTLM

It is worth remembering that securing Kerberos is only part of the equation. When Kerberos is not available, Windows systems automatically fall back to NTLM - a protocol with its own set of vulnerabilities. We cover NTLM relay attacks and migration strategy in a dedicated article NTLM Relay - why it still works and how to defend.

Summary

Kerberos attacks do not require zero-day exploits. They exploit legitimate protocol functionality in ways its designers did not foresee. Defense requires a multi-layered approach - from service account hygiene, through monitoring, to regular rotation of cryptographic keys.

At SEQRED, we test the resilience of Active Directory environments against these attacks as part of internal infrastructure penetration tests and Red Team engagements. Each test concludes with a detailed report containing prioritized recommendations and support for implementation.

---

Sources:

• Microsoft - Mitigating critical threats to AD DS in 2025
• Microsoft Defender for Identity - Kerberos attack detections
• Microsoft - Enterprise Access Model
• Bharath Bandari - Detect Potential Kerberoasting Activity (2026)
• SpecterOps - The Renaissance of NTLM Relay Attacks