AD Security - Kerberos Abuse Prevention

Why Kerberos is such a popular target

From an attacker’s perspective, Kerberos offers two major advantages. First, it is everywhere. Every domain-joined system relies on it. Second, much of the abuse can be performed using standard domain user privileges.

Kerberoasting activity generates normal Kerberos service ticket requests (Event ID 4769), which makes it difficult to detect unless abnormal patterns are monitored.

The goal is rarely to break Kerberos itself. The goal is to extract credentials, reuse them and move closer to privileged access.

Kerberoasting and why it still works 

Kerberoasting remains one of the most reliable techniques for attackers inside a Windows domain. The idea is simple. Service accounts that run under user accounts have Service Principal Names registered in Active Directory. Any authenticated domain principal with a valid TGT can request service tickets for SPNs in the domain.

The returned service ticket contains data encrypted with the service account’s long-term Kerberos key, which is derived from the account’s password. The attacker cannot decrypt them directly, but they can take them offline and attempt to crack them.

In many environments, service account passwords are long-lived, rarely changed and sometimes created before modern password policies were enforced. This makes them ideal candidates for offline password cracking.

From an attacker’s point of view, Kerberoasting is low-risk and high-reward. It does not require elevated privileges and leaves little evidence beyond normal Kerberos traffic.

Abusing Kerberos in Practice: From SPN Enumeration to Password Cracking

In this phase of the attack, Kerberos is actively abused to obtain service account credentials through a Kerberoasting technique. The objective is to demonstrate how a low-privileged domain user can extract service tickets and subsequently crack them offline to recover plaintext passwords.

The first step consists of enumerating all domain accounts that have a Service Principal Name (SPN) configured. This is achieved using the GetUserSPNs tool, which queries Active Directory for accounts associated with Kerberos services.

Once the SPNs are identified, a service ticket (TGS) is requested for the targeted account. Kerberos allows any authenticated domain user to request a service ticket for an SPN without requiring elevated privileges. The returned ticket is encrypted with the service account’s long-term key, which is derived from the account’s password hash.

The extracted service ticket is then exported and prepared for offline password cracking. Since the ticket encryption relies on the service account’s password, weak or reused passwords can be exploited without generating additional noise in the domain environment.

Using Hashcat, the Kerberos TGS hash is cracked offline. This process does not interact with the domain controller.

As a result of this attack, the plaintext password for the service account rosalie is successfully recovered. This demonstrates how Kerberoasting can directly lead to credential compromise and potentially enable lateral movement or privilege escalation within the domain.

This practical example highlights why Kerberoasting remains an effective attack vector in many Active Directory environments, especially where service accounts are configured with weak or long-lived passwords.

Mitigating Kerberoasting risks

Reducing Kerberoasting risk starts with service account hygiene, but it should not stop at password strength alone. Accounts with Service Principal Names are often treated as “just service accounts”, while in reality they frequently have far more permissions than strictly required.

In many environments, SPNs are assigned to regular user accounts that were never designed to be long-lived service identities. Over time, these accounts accumulate group memberships, delegated permissions or even local administrative rights on servers. If such an account is compromised through Kerberoasting, the attacker does not just gain a password, but immediate access to systems or sensitive parts of the domain.

A proper mitigation therefore also requires reviewing what these accounts can actually do. Accounts with SPNs should be treated as high-risk identities. Their group memberships should be reviewed, excessive privileges removed and access limited to only what the associated service genuinely requires.

Where possible, service accounts should not be members of high privileged groups. Their permissions should be scoped to specific systems rather than broadly granted across the environment.

Password strength and rotation remain critical. Service account passwords should be long, complex and rotated regularly. Where possible, traditional service accounts should be replaced with Managed Service Accounts or Group Managed Service Accounts. These accounts automatically rotate passwords and significantly reduce exposure to offline cracking.

It is also important to review whether SPNs are still needed at all. Over time, SPNs are often left behind after applications are decommissioned or reconfigured. Removing unnecessary SPNs immediately reduces the Kerberoasting attack surface.

Kerberoasting cannot be fully eliminated in Active Directory, but its practical impact can be significantly reduced by combining strong credentials, minimal permissions and disciplined service account management.

Kerberos pre-authentication misconfigurations

Another frequently abused Kerberos weakness is disabled pre-authentication. Kerberos pre-authentication exists to prove that a user knows their password before the Key Distribution Center responds.

When pre-authentication is disabled on an account, this protection layer is removed. An attacker can request Kerberos authentication data for that account without knowing the password. The domain controller responds with encrypted material that can be taken offline and cracked, in a similar way to Kerberoasting.

In practice, accounts with pre-authentication disabled are rarely created for security reasons. They are often legacy users, test accounts or service-related accounts created years ago for compatibility purposes. In many cases, no one remembers why the setting was changed, but the account continues to exist and function normally.

From an attacker’s perspective, these accounts are extremely attractive. No interaction is required beyond a single request, and no failed logon event is generated.

Proof of concept abusing Kerberos pre-authentication

After gaining access to a standard domain user account, an attacker can enumerate Active Directory for users where Kerberos pre-authentication is disabled. This does not require administrative privileges and can be done using standard enumeration techniques.

During this enumeration, the account named “rosalie” stands out. Kerberos pre-authentication is explicitly disabled on this user.

Instead of attempting to log in, the attacker abuses the Kerberos protocol itself. Using the tool GetNPUsers.py, a Kerberos authentication request is sent for the user rosalie. Because pre-authentication is disabled, the domain controller responds with encrypted authentication data without requiring proof of password knowledge.

This interaction blends in with normal Kerberos traffic. No failed logon is generated, no account lockout is triggered and no obvious warning is raised.

The returned data can then be taken offline and cracked. If the password is weak, reused or outdated, it can often be recovered without any further interaction with the domain.

Reviewing the account configuration confirms the root cause. The setting “Do not require Kerberos pre-authentication” is enabled on the user rosalie. This single checkbox significantly weakens the security of the account and turns it into a low-effort entry point for attackers.

In many environments, multiple accounts share this configuration without clear justification, making this a recurring and often overlooked risk.

Correcting pre-authentication issues

The first step is visibility. Identify all accounts where Kerberos pre-authentication is disabled and review why. In most modern environments, there is no valid reason for this setting to remain disabled.

Where possible, pre-authentication should be re-enabled. If an application genuinely requires it to be disabled, that dependency should be carefully reviewed and documented, as it represents a permanent security exception.

Accounts with disabled pre-authentication should also be treated as high risk. They should have strong passwords, limited privileges and additional monitoring.

In many environments, simply correcting this misconfiguration removes an entire class of low-effort attacks.

The script below demonstrates how it is possible to enumerate all domain user accounts for which Kerberos pre-authentication is disabled. Disabling pre-authentication can expose accounts to AS-REP roasting attacks, as authentication responses can be requested without providing valid credentials.

The script loads the Active Directory module and iterates through all domains in the current forest. For each domain, it queries Active Directory for user accounts that have the “Do not require Kerberos pre-authentication” flag set in the userAccountControl attribute. Relevant account information, such as the account status and last logon date, is then collected and presented in a consolidated output.

Import-Module ActiveDirectory
$results = @()
$forest = Get-ADForest

foreach ($domain in $forest.Domains) {
    Write-Host "Scanning domain: $domain" -ForegroundColor Cyan
    $users = Get-ADUser `
        -Server $domain `
        -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=4194304)" `
        -Properties userAccountControl, Enabled, LastLogonDate
    foreach ($user in $users) {
        $results += [PSCustomObject]@{
            Domain          = $domain
            Name            = $user.Name
            SamAccountName  = $user.SamAccountName
            Enabled         = $user.Enabled
            LastLogonDate   = $user.LastLogonDate
        }
    }
}

$results

Weak Kerberos encryption types and legacy compatibility

Kerberos supports multiple encryption types to maintain compatibility with older systems. Unfortunately, this backward compatibility is frequently abused.

Encryption types such as DES and RC4 are considered weak by modern standards. RC4 in particular is still commonly encountered because it was widely used in older Windows versions and remains enabled for compatibility reasons.

From an attacker’s perspective, weak encryption types are valuable because they significantly reduce the effort required to crack Kerberos tickets. RC4-encrypted tickets are much faster to crack than tickets using modern AES encryption.

In many environments, weak enryption remains enabled simply because it always has been.

Disabling weak Kerberos encryption

Hardening Kerberos encryption starts with understanding what is actually required in the environment. Most modern Windows systems fully support AES-based Kerberos encryption.

RC4 and DES should be disabled wherever possible, starting with user and service accounts and followed by domain-level configuration. This change must be planned carefully, especially in environments with legacy systems, but the security benefits are substantial.

Service accounts should also be reviewed for the encryption types they support. In Active Directory, the attribute msDS-SupportedEncryptionTypes determines which Kerberos encryption types an account can use. In many environments this attribute is not explicitly configured. In those cases, the effective encryption behavior depends on domain defaults, patch level and available keys, and may still permit RC4 instead of consistently enforcing AES.

Where possible, accounts should be configured to support only modern AES encryption types. Enforcing AES-based encryption significantly increases the computational effort required for offline password cracking and reduces the effectiveness of Kerberos abuse techniques such as Kerberoasting.

By enforcing modern encryption types, organizations significantly increase the cost and time required for offline Kerberos attacks. Even if tickets are obtained, cracking them becomes far less practical.

Why Kerberos hardening is often overlooked

Kerberos is often perceived as complex and fragile. Many organizations are hesitant to change Kerberos-related settings out of fear of breaking authentication.

As a result, legacy configurations persist long after the systems that required them are gone. These settings quietly remain exploitable, even in otherwise well-maintained environments.

Kerberos abuse often goes unnoticed because it looks like normal authentication traffic. Without targeted monitoring, it blends in perfectly.

What needs to change

Kerberos hardening requires deliberate review rather than blanket changes. Service accounts need ownership, SPNs need justification and legacy encryption settings need to be challenged.

Kerberos should be treated as part of the attack surface, not just a background protocol that “just works”.

By addressing Kerberoasting risks, correcting pre-authentication misconfigurations and disabling weak encryption types, organizations remove some of the most reliable privilege escalation paths used in real-world attacks.

Kerberos logging is not enabled by default

Detection is often the weakest part of Kerberos security. While domain controllers do log authentication activity, the level of detail is not always sufficient to detect abuse in practice.

Many environments rely on standard security events such as 4768 and 4769, assuming this provides enough visibility. In reality, without proper audit configuration, these logs lack context and are often not centrally collected or actively monitored.

Kerberos abuse does not generate obvious failures. Techniques like Kerberoasting produce legitimate ticket requests, which blend in with normal authentication traffic. Without the right logging in place, this activity remains effectively invisible.

Improving visibility starts with enabling the correct audit policies on domain controllers. Kerberos-specific auditing is not fully enabled by default and should be explicitly configured through Advanced Audit Policy:

• Audit Kerberos Authentication Service
• Audit Kerberos Service Ticket Operations
• Audit Account Logon

These settings can be configured via Group Policy under:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Account Logon & Logon/Logoff

Logging alone is not enough. Events should be forwarded to a central platform and monitored for patterns such as unusual volumes of service ticket requests or access to uncommon services.

Without this level of visibility, Kerberos remains a blind spot. Not because the activity is hidden, but because it is indistinguishable from normal behaviour unless you are specifically looking for it.

These weaknesses are rarely the result of a single misconfiguration. They typically exist due to legacy configurations, unclear ownership, or missing periodic reviews. Regular audits of accounts, SPNs, and Kerberos-related settings are necessary to prevent attacks such as Kerberoasting from succeeding.

Closing thoughts

To reduce the risk of Kerberos abuse, some fundamental changes are required in how Active Directory accounts are configured and maintained.

First, accounts should not have Kerberos pre-authentication disabled unless there is a very clear and documented reason to do so. Any account with this setting enabled should be considered high risk and reviewed carefully. In most environments, there is no technical justification for leaving pre-authentication disabled.

Service accounts also need more attention. Weak or rarely changed passwords are one of the main reasons Kerberoasting is still effective. Service account passwords should be long, complex, and unique. Where possible, standard service accounts should be replaced with Group Managed Service Accounts (gMSAs), which remove the need for manual password management altogether.

SPNs should be reviewed regularly. Unused or forgotten SPNs are common in Active Directory environments and unnecessarily increase the attack surface. If a service is no longer in use, its SPN should be removed.

Detection is another area that often falls short. Requesting Kerberos service tickets is normal behaviour, which makes abuse difficult to spot. However, large volumes of ticket requests or unusual access patterns can still be indicators of malicious activity and should be monitored.

These weaknesses are rarely the result of a single misconfiguration. They typically exist due to legacy configurations, unclear ownership, or missing periodic reviews. Regular audits of accounts, SPNs, and Kerberos-related settings are necessary to prevent attacks such as Kerberoasting from succeeding.