New Kerberos Attack Vector : Disabled SPN Kerberoasting

New Kerberos Attack Vector : Disabled SPN Kerberoasting

Speakers: Yeonwoo Park, Researcher, RaonSecure Co.,Ltd - Team SaturnX

Conference: DefCamp

YouTube: https://www.youtube.com/watch?v=XxCdNBLbEng

Overview

In a compelling presentation at DefCamp, Yeonwoo Park, a seasoned red team operator from RaonSecure's Team SaturnX, unveiled a novel Kerberos attack vector dubbed "Disabled SPN Kerberoasting." This research exposes a critical design flaw within Microsoft's Active Directory security implementation, allowing attackers to forcefully obtain Service Principal Names (SPNs) from disabled accounts. The discovery challenges long-held assumptions about the security posture of inactive accounts and provides a new avenue for credential compromise within enterprise environments.

Park's talk meticulously dissects the intricacies of the Kerberos authentication flow, revealing a subtle yet profound inconsistency in how the Key Distribution Center (KDC) handles service ticket requests for disabled accounts. While existing Kerberoasting techniques target active accounts, this new method bypasses standard security checks, enabling the acquisition of service tickets for accounts that have been intentionally deactivated. This is particularly concerning as disabled accounts, especially legacy service accounts or those belonging to departed employees, often retain powerful permissions and may be protected by weak or reused passwords, making them prime targets for attackers.

The significance of this research lies in its ability to unlock a previously overlooked trove of potential attack surface. Defenders often rely on disabling accounts as a primary security measure, assuming that such accounts pose no further threat. Park's work demonstrates that this assumption is flawed, highlighting the need for a more comprehensive approach to managing inactive identities and their associated SPNs. For red teams, it offers a potent new technique to escalate privileges and gain persistence, underscoring the continuous need for vigilance and adaptation in the cybersecurity landscape.

Background

▶ Watch: Speaker intro, new Kerberos attack vector (2:00)

To fully appreciate the "Disabled SPN Kerberoasting" attack, it's essential to understand the fundamentals of Kerberos authentication and the existing Kerberoasting technique. Kerberos is the default authentication protocol used in Microsoft Active Directory (AD) environments, providing secure authentication over untrusted networks. It relies on shared secret keys and tickets to verify user identities and grant access to services.

A core component of Kerberos is the Service Principal Name (SPN). An SPN is a unique identifier for a service instance that is used by Kerberos to authenticate a service. For example, a SQL Server running on a domain-joined machine might have an SPN like MSSQLSvc/sqlserver.domain.com:1433. When a user attempts to access this SQL service, their client requests a service ticket for this specific SPN from the Key Distribution Center (KDC), which is typically a Domain Controller. The KDC generates this service ticket, encrypting it with the NTLM hash of the service account under which the SQL Server is running.

Kerberoasting is a well-known attack that leverages this process. An attacker, possessing valid domain credentials (even low-privileged ones), can request service tickets for any registered SPN within the domain. Since these service tickets are encrypted with the target service account's NTLM hash, an attacker can extract the encrypted portion of the ticket (specifically, the etype 23 hash) and attempt to crack it offline using tools like Hashcat. If successful, the attacker obtains the plaintext password for the service account, which often holds elevated privileges or access to sensitive resources. The effectiveness of Kerberoasting hinges on the fact that service tickets are issued to any authenticated user, regardless of whether they have permissions to actually use the service.

The prevailing understanding has been that Kerberoasting primarily targets active accounts with registered SPNs. Disabled accounts, by definition, are inactive and generally assumed to be incapable of issuing Kerberos tickets. They are often considered a "safe" way to decommission accounts without fully deleting them, preserving their history or associated data. However, this assumption creates a blind spot. Many organizations disable old service accounts, former employee accounts, or legacy application accounts, often neglecting to remove their associated SPNs or review their past permissions. These disabled accounts might still have powerful group memberships (e.g., Domain Admins) and could be protected by weak or easily guessable passwords, making them high-value targets if their Kerberos tickets could be obtained. The problem, as Yeonwoo Park's research reveals, lies in a subtle inconsistency within the KDC's logic that allows this very scenario to unfold.

Key Findings

▶ Watch: Hidden Kerberos secret: CNAME/SNAME optional, TGT is service ticket (8:50)

Yeonwoo Park's research introduces a significant new attack vector, Disabled SPN Kerberoasting, by exposing a critical flaw in Microsoft's Kerberos implementation. The key findings can be summarized as follows:

1. The TGT is Not Special; It's a Service Ticket: A fundamental revelation is that the Ticket Granting Ticket (TGT), often perceived as a unique type of Kerberos ticket, is in reality merely a service ticket issued for the special KRBTGT account. This account, with its well-known Relative ID (RID) of 502, also has a registered SPN (changepassword). This understanding is crucial because it demystifies the TGT and establishes a baseline for how all service tickets are processed.

1. AS-REQ and TGS-REQ Follow Similar Logic for Service Ticket Issuance: Park demonstrates that the Authentication Service Request (AS-REQ), traditionally used to obtain a TGT, and the Ticket Granting Service Request (TGS-REQ), used to obtain service tickets, share underlying logic for issuing service tickets. This functional overlap is exploited in the attack.

1. Inconsistent Exception Handling for Disabled Accounts: The core of the vulnerability lies in a critical inconsistency within the KDC's logic concerning disabled accounts.

• When an attacker attempts to request a service ticket for a disabled account with an SPN using a TGS-REQ, the KDC correctly identifies the account as disabled (unless it's the KRBTGT account) and denies the request, returning an NT_STATUS_ACCOUNT_DISABLED error. This check is implemented.
• However, when the same request (i.e., requesting a service ticket for a non-KRBTGT disabled account with an SPN) is made using an AS-REQ (leveraging the functional similarity described above), the KDC's exception handling code for disabled accounts is missing. This means the specific check that prevents TGS-REQs for disabled accounts (other than KRBTGT) from being issued is not present in the AS-REQ processing path for non-KRBTGT service tickets.

1. Bypass of Disabled Account Restrictions: Due to this missing exception handling, an attacker can bypass the restriction on obtaining service tickets for disabled accounts. By crafting an AS-REQ that targets a disabled account with an SPN, the KDC will issue a service ticket for that account, despite its disabled status.

1. Enabling Disabled SPN Kerberoasting: This bypass allows attackers to perform Kerberoasting on disabled accounts. Once the service ticket is obtained, it contains the NTLM hash of the disabled account, which can then be extracted and cracked offline. This opens up a significant attack surface, as disabled accounts are often neglected, may retain powerful permissions, and can be protected by weak or reused passwords.

These findings reveal a fundamental flaw in how Active Directory enforces security for inactive identities, demonstrating that "disabled" does not necessarily mean "secure" when it comes to Kerberos service tickets.

Technical Deep Dive

▶ Watch: Reverse engineering reveals Microsoft's flawed exception handling (14:40)

The "Disabled SPN Kerberoasting" attack is rooted in a nuanced understanding of the Kerberos protocol and a critical implementation oversight within the Active Directory Key Distribution Center (KDC). To fully grasp the vulnerability, it's essential to dissect the Kerberos authentication flow and the specific logic uncovered by Yeonwoo Park.

Kerberos Authentication Flow Revisited

The standard Kerberos authentication process involves two primary stages:

1. Pre-authentication (AS-REQ/AS-REP):

• A client (user) sends an Authentication Service Request (AS-REQ) to the KDC (Domain Controller), requesting a Ticket Granting Ticket (TGT). This request includes the client's username and a timestamp encrypted with the client's NTLM hash.
• The KDC decrypts the timestamp using the client's NTLM hash. If valid, it generates a TGT (encrypted with the KRBTGT account's NTLM hash) and a TGT session key (encrypted with the client's NTLM hash).
• The KDC sends back an Authentication Service Reply (AS-REP) containing the TGT and the TGT session key. The TGT itself is opaque to the client.

1. Service Ticket Request (TGS-REQ/TGS-REP):

• Once the client has a TGT, it can request access to specific services. It sends a Ticket Granting Service Request (TGS-REQ) to the KDC. This request includes the TGT and the Service Principal Name (SPN) of the desired service (e.g., MSSQLSvc/server.domain.com). The request also includes the current time encrypted with the TGT session key.
• The KDC decrypts the TGT using the KRBTGT account's NTLM hash and verifies its validity. It then decrypts the timestamp using the TGT session key.
• If valid, the KDC issues a Service Ticket for the requested SPN. This service ticket is encrypted with the NTLM hash of the service account that the SPN is registered to. It also issues a service ticket session key, encrypted with the TGT session key.
• The KDC sends back a Ticket Granting Service Reply (TGS-REP) containing the service ticket and the service ticket session key.

The "Hidden Secret" of Kerberos: TGT as a Service Ticket

Park's initial insight challenges the notion of the TGT as a unique entity. He demonstrates that the KDC_REQ_BODY structure used in both AS-REQ and TGS-REQ allows for flexible CNAME (client name) and SNAME (service name) fields, both using the PrincipalName structure. He showed that requesting KRBTGT as the SNAME in a TGS-REQ successfully yields a ticket. This proves that the TGT is, in essence, a service ticket for the KRBTGT account, which itself has an SPN (changepassword). This realization is foundational to understanding how AS-REQ can be coerced into requesting other service tickets.

Furthermore, Park highlights that standard Kerberoasting tools like Impacket's getuserspn.py are designed to skip disabled accounts. The getuserspn.py script inspects the userAccountControl attribute in the service response and, if it indicates ACCOUNT_DISABLED, it filters out that entry. To overcome this, an attacker would need to modify the script to include disabled accounts in its output, allowing for the enumeration of potential targets.

The Critical Inconsistency: AS-REQ vs. TGS-REQ

The core of the vulnerability lies in the KDC's differing handling of disabled accounts between AS-REQ and TGS-REQ.

1. TGS-REQ for Disabled Accounts (Expected Behavior):

When a TGS-REQ is made for a disabled account (e.g., "Mickey" with SPN "defcam"), the KDC's internal logic, specifically observed through reverse engineering the KDC sbc.d file, contains a check. This check involves a conditional statement that, under certain circumstances, calls the fextended_error function. Crucially, this conditional statement includes logic to check if the object value does not match 502 (which is the Relative ID, or RID, for the KRBTGT account). If the account is not KRBTGT and is disabled, the fextended_error function is invoked with the argument -1073741710 (or 0xC000010E in hexadecimal), which corresponds to the NT_STATUS_ACCOUNT_DISABLED error. This is why a standard TGS-REQ (like Get-ST from Impacket) for a disabled account like "Mickey" fails with a "service could not be found" error – the KDC explicitly denies it because the account is disabled.

1. AS-REQ for Disabled Accounts (The Bypass):

Park's key discovery is that while TGS-REQ has this explicit check for disabled accounts (excluding KRBTGT), the **AS-REQ path for issuing service tickets for non-KRBTGT accounts lacks this specific exception handling code.**

Since Park established that AS-REQ and TGS-REQ follow similar underlying logic for issuing service tickets, and that AS-REQ can effectively be used to request any service ticket (not just for KRBTGT), this missing check becomes exploitable. An attacker can craft an AS-REQ that requests a service ticket for a disabled account's SPN. Because the KDC doesn't perform the NT_STATUS_ACCOUNT_DISABLED check in this specific AS-REQ context for non-KRBTGT accounts, it proceeds to issue the service ticket.

Resulting Vulnerability: This bypass allows an attacker to obtain a valid Kerberos service ticket for a disabled account that has an SPN registered. This ticket, like any other service ticket, is encrypted with the NTLM hash of the disabled account. The attacker can then extract this hash and attempt to crack it offline using tools like Hashcat, effectively performing "Disabled SPN Kerberoasting."

Demo / Proof of Concept

▶ Watch: Proof-of-concept demonstration of the attack (18:20)

Yeonwoo Park provided a clear demonstration of the "Disabled SPN Kerberoasting" attack, illustrating the bypass in action. The proof of concept (PoC) involved setting up a controlled Active Directory environment and executing a series of steps to acquire a service ticket from a disabled account.

The demonstration began by establishing two key accounts:

1. defcam 2025: This account served as the requesting user, demonstrating that no special privileges were required to initiate the attack. It was a standard domain user.
2. Mickey: This was the target account. Initially, Mickey was created as a regular domain user. A test service with the SPN defcam was then assigned to the Mickey account using PowerShell. Crucially, immediately after assigning the SPN, the Mickey account was explicitly disabled.

The next step in the PoC mirrored the necessary modification to enumeration tools. Park explained that standard tools like Impacket's getuserspn.py would typically filter out disabled accounts. Therefore, the PoC utilized a modified version (or a custom script performing similar logic) to enumerate services within the domain and specifically identify those owned by disabled accounts. This step allowed the attacker to discover the Mickey account with its defcam SPN, despite its disabled status.

With the target identified, the core of the PoC involved requesting a service ticket for the Mickey account's defcam SPN using the AS-REQ bypass mechanism. As explained in the technical deep dive, this request effectively circumvents the KDC's usual checks for disabled accounts because the specific exception handling logic is missing in the AS-REQ path for non-KRBTGT service tickets.

The demonstration confirmed that the conditional branching for disabled accounts was indeed bypassed. The KDC, instead of denying the request with an NT_STATUS_ACCOUNT_DISABLED error, successfully issued a service ticket for the Mickey account. The issued ticket was then output in a format directly compatible with Hashcat, a widely used password cracking tool. This visually confirmed that the encrypted hash of the Mickey account had been successfully obtained, ready for offline cracking.

This demo conclusively proved that an attacker, even with low-privileged credentials, could enumerate and obtain Kerberos service tickets for disabled accounts with SPNs, thus making them vulnerable to offline password cracking.

Defensive Implications

▶ Watch: Mitigation: Enumerate and clean up SPNs from disabled accounts (22:30)

The "Disabled SPN Kerberoasting" attack vector unveiled by Yeonwoo Park carries significant defensive implications, forcing organizations to re-evaluate their strategies for managing inactive accounts and Kerberos security. The primary risk stems from the common practice of simply disabling accounts, especially service or administrative accounts, without fully decommissioning or cleaning up their associated privileges and configurations.

Risk Profile:

• High-Privilege Legacy Accounts: Many organizations have legacy service accounts, deployment accounts, or accounts for former employees that were granted extensive permissions (e.g., Domain Admin rights) during their active tenure. When these accounts become obsolete, they are often merely disabled rather than properly removed and their SPNs unregistered.
• Weak or Reused Passwords: Disabled accounts are frequently overlooked in password rotation policies. Their passwords might be weak, easily guessable, or follow predictable patterns (e.g., CompanySolution2023). If cracked, these passwords can often be reused against other active accounts or services within the domain.
• Persistent Attack Surface: Disabling an account is typically seen as a way to neutralize its threat. This research demonstrates that a disabled account with an SPN remains a persistent attack surface, even if it cannot log in interactively.

Defensive Strategies:

1. Proactive Identification of Disabled SPNs:

The most crucial defensive measure is to actively identify all disabled accounts that still have Service Principal Names (SPNs) registered to them. This requires going beyond standard enumeration scripts that often filter out disabled accounts.

• PowerShell Enumeration: Administrators should regularly use PowerShell commands to query Active Directory for this specific condition. A command similar to this can be effective:

This command retrieves all user accounts with an SPN, then filters for those that are disabled, and finally displays their SamAccountName and ServicePrincipalName.

1. Remediation of Identified Accounts:

Once disabled accounts with SPNs are identified, immediate action is required:

• Reactivate Temporarily: To modify the account, it might be necessary to temporarily reactivate it.
• Remove SPNs: The critical step is to remove all associated SPNs from the account. This can be done using Set-ADUser:

• Re-disable (or Delete): After removing the SPNs, the account can be re-disabled. For accounts that are truly no longer needed, outright deletion is the strongest security posture, ensuring no residual attack surface.

1. Comprehensive Account Decommissioning Policies:

Organizations must implement robust policies for account decommissioning that go beyond simply disabling accounts. This policy should mandate:

• SPN Cleanup: Before disabling or deleting any account, especially service accounts, all associated SPNs must be unregistered.
• Permission Review: All group memberships and delegated permissions should be revoked.
• Password History/Complexity: Review password history and ensure strong, unique passwords are used for all service accounts, even those intended for short-term use.

1. Enhanced Password Policies and Monitoring:

• Unique Passwords: Enforce policies that prevent the reuse of password patterns across different accounts.
• Account Lockout Policies: While the attack is offline, strong account lockout policies for active accounts can help mitigate the impact of password spray attacks that might follow a successful Kerberoasting of a disabled account.
• Kerberos Event Logging: Monitor Kerberos event logs for unusual activity, such as a high volume of AS-REQs for non-existent or unusual SPNs, which might indicate enumeration attempts.

By proactively identifying and remediating disabled accounts with SPNs, and by adopting more stringent account decommissioning procedures, organizations can significantly reduce their attack surface against this novel Kerberoasting technique.

Key Takeaways

• Disabled SPN Kerberoasting is a New Attack Vector: Yeonwoo Park's research introduces a novel method for attackers to obtain Kerberos service tickets from disabled Active Directory accounts that still have Service Principal Names (SPNs) registered.
• The TGT is a Service Ticket: The Ticket Granting Ticket (TGT) is not a unique entity but rather a service ticket for the special KRBTGT account, which itself possesses an SPN. This demystification is key to understanding the underlying flaw.
• Inconsistent KDC Logic is the Root Cause: The vulnerability stems from a critical inconsistency in the Key Distribution Center's (KDC) exception handling. While Ticket Granting Service Requests (TGS-REQs) correctly deny service tickets for most disabled accounts, Authentication Service Requests (AS-REQs) lack this specific check when requesting service tickets for non-KRBTGT disabled accounts.
• Bypass of Disabled Account Security Checks: This inconsistency allows an attacker to bypass the security measure intended to prevent service ticket issuance for disabled accounts, enabling them to acquire the account's NTLM hash for offline cracking.
• High-Value Targets Overlooked: Disabled accounts, particularly old service accounts or those with historical administrative privileges, are often neglected and may retain powerful permissions or be protected by weak/reused passwords, making them prime targets for this attack.
• Proactive Remediation is Essential: Defenders must actively enumerate all accounts (including disabled ones) for registered SPNs. Any disabled account found with an SPN should be temporarily reactivated, have its SPN removed, and then be re-disabled or ideally, fully decommissioned.

About the Speaker(s)

Yeonwoo Park is a dedicated security researcher and red team operator currently working with RaonSecure Co.,Ltd as part of their Team SaturnX. He holds a CRT certification, reflecting his expertise in penetration testing. Park has a profound interest in Active Directory and the Kerberos authentication protocol, areas where he has conducted significant research leading to the discovery of new attack vectors. He maintains a personal pentest wiki where he analyzes and organizes penetration testing and red teaming techniques, aligning them with the MITRE ATT&CK framework. His work, as demonstrated by this presentation, contributes valuable insights into securing complex enterprise environments.