Why Your SPN Monitoring Misses Kerberoasting: A Protocol-Level Reality Check

Many security teams check the box on “Active Directory hardening” by configuring alerts for Service Principal Name (SPN) modifications or monitoring LDAP directory searches. While these controls look good on a compliance checklist, they fail to address the fundamental reality of how Kerberoasting operates.

Kerberoasting is not an exploit of a software vulnerability; it is the abuse of legitimate, built-in features of the Kerberos protocol. Because of this, detection strategies that rely solely on identifying “suspicious” SPN queries or registry changes are fundamentally blind to the actual extraction of credentials. To defend against this technique, we must understand the precise protocol exchanges that occur and why standard monitoring boundaries fail.

The Mechanics: How the Protocol is Abused

To understand why simple monitoring fails, we have to look at the exact steps an adversary takes to perform Kerberoasting. The entire attack relies on the fact that any domain-authenticated user can request a service ticket for any registered SPN in the Active Directory forest, and the Key Distribution Center (KDC) will oblige without checking if the user actually has permission to access that service.

Step 1: Directory Enumeration (LDAP Querying)

The adversary must first find target accounts. They query the Domain Controller via LDAP (Lightweight Directory Access Protocol) for user objects that have a non-null servicePrincipalName attribute.

In Active Directory, computer accounts have SPNs automatically managed by the system, but user accounts (which often represent service accounts) can also have SPNs mapped to them manually. Since service accounts are frequently granted elevated privileges (such as local administrator on SQL databases or domain administrator status) and often have weaker, human-generated passwords, they are the primary targets.

Step 2: The Ticket Granting Service (TGS) Request

Once a list of target SPNs is compiled, the client requests a service ticket for those SPNs from the KDC. This is done via a standard TGS-REQ message.

Under the hood, the client sends:

• Its Ticket Granting Ticket (TGT), proving its identity.
• The requested SPN (e.g., MSSQLSvc/sql01.corp.internal:1433).

The KDC validates the TGT, identifies the user account associated with the requested SPN, and returns a TGS-REP (Ticket Granting Service Response). This response contains the service ticket, which is encrypted using the master key (the NTLM hash or AES key) of the target service account.

Step 3: Ticket Extraction and Offline Cracking

Once the client receives the TGS-REP containing the encrypted ticket, the data is stored in the local memory of the requesting machine. The adversary extracts this encrypted blob from memory.

Because the ticket is encrypted using the password hash of the service account, the adversary can take this blob offline. They do not need to interact with the Domain Controller or any network resource again. They attempt to decrypt the ticket by guessing passwords, hashing them, and attempting to decrypt the structure. If the decryption succeeds, the guessed password is correct.

The Fallacy of SPN-Monitoring-Only

A common detection strategy is to monitor for active LDAP queries searching for servicePrincipalName attributes, or to monitor changes to SPNs. Here is why this strategy provides a false sense of security:

1. LDAP Queries are Standard Behavior: Every time a legitimate application or user attempts to connect to a resource (like a web server, database, or file share), the operating system performs an LDAP query to resolve the SPN. Distinguishing between a legitimate system resolving a single SPN and an attacker querying for all of them requires analyzing query volume and structure, which is notoriously difficult to baseline in large environments.
2. Reconnaissance is Optional: An attacker does not actually need to run an LDAP query to execute Kerberoasting. If they already know or can guess the SPN of a target service (such as common SQL or Exchange service names), they can request the TGS ticket directly without ever performing an LDAP search.
3. SPN Modification is Irrelevant: Monitoring for changes to SPNs (e.g., Event ID 5136) only flags when a new SPN is registered or modified. Kerberoasting targets existing, long-standing service accounts that have had their SPNs configured for months or years. No modification occurs during the attack.

Engineering High-Fidelity Detections

To successfully detect Kerberoasting, the focus must shift from the reconnaissance phase (LDAP) to the execution phase (TGS Requests). Every Kerberoasting attempt must request a ticket, leaving a footprint on the Domain Controller.

1. Monitoring Event ID 4769 (A Kerberos service ticket was requested)

Every time a TGS is requested, the Domain Controller generates Security Event ID 4769. However, because thousands of these events are generated every hour in a typical enterprise, you must filter for anomalous patterns:

• Encryption Type Downgrade (0x17): Modern environments should default to AES encryption (Types 0x11 or 0x12). Attackers often explicitly request RC4 encryption (0x17) because RC4-encrypted tickets are significantly faster to crack offline than AES-encrypted tickets. A sudden spike in TGS-REQ events using RC4 encryption is a strong indicator of compromise.
• Volume Anomalies: A normal user machine typically requests tickets only for the services it needs to access. An adversary running a Kerberoasting tool will request tickets for dozens or hundreds of SPNs in a matter of seconds. Look for a single source IP or user account requesting an unusually high number of 4769 events within a tight time window.
• Target Account Specificity: Correlate 4769 events with high-privilege service accounts (e.g., accounts where the adminCount attribute is set to 1, or members of sensitive groups) being requested by low-privileged workstations or standard user accounts that have no business interacting with those services.

2. Network-Level Anomalies

If you are performing network security monitoring, analyze the Kerberos traffic (port 88). Look for a high volume of TGS-REP packets sent to a single host containing the cipher text of multiple different services. Because the offline cracking phase occurs entirely on the adversary’s system, the network-level signature begins and ends with the concentration of these ticket responses.