Active Directory Risks — RC4 Encrypted Kerberos Tickets

4 min readJun 19, 2023

Imagine completing a 40 hour work week in 3 minutes — that’s what it’s like working 800 times faster.

RC4 encrypted Kerberos tickets allow attackers to crack passwords over 800 times faster than their AES encrypted equivalents. Many environments unintentionally have this enabled, as Microsoft’s default configuration allows downgrading to RC4. The risk from this undefined setting allows a threat actor to crack passwords significantly faster.

Identification

By default, the Group Policy Object for Kerberos encryption types is undefined. This allows attackers to downgrade encryption when requesting a ticket for an associated Service Principal Name (SPN). An SPN is an account associated with a service on the Domain.

Microsoft’s default setting for Kerberos ticket encryption allows RC4

Unless an organization has explicitly set this GPO, they will allow RC4 encryption. Threat actors can exploit this by using the Impacket’s GetUserSPNs.py or ShutdownRepo’s targetedKerberoast.py.

To identify SPNs on your domain, we can use PowerShell to query for any SPNs associated with accounts. Example code to complete this is below.

Get-ADUser -Filter * -Properties SamAccountName, ServicePrincipalNames, Enabled | Where-Object { ($_.ServicePrincipalNames).Count -gt 0 } | Format-Table SamAccountName, ServicePrincipalNames, Enabled

Identifying enabled accounts with SPNs assigned. These accounts can be targeted by kerberoasting.

Sysadmins must understand exactly which accounts have SPNs and why they need them on their domains. If an account does not need an SPN for operational needs, remove it! This eliminates this risk for that account.

Cracking Analysis

To demonstrate the difference in cracking speed, we first need to gather the hashes. In this example, I used Impacket’s scripts to gather the hash for a known vulnerable SPN on my home lab. Since we have a default and undefined policy for Kerberos encryption, the initial ticket we gather is RC4 encrypted. This is a $krb5gs$23$ hash format.

Gathering an RC4 encrypted Kerberos ticket via Impacket’s GetUserSPNs.py script

Running hashcat with mode 13100 cracks the RC4 encrypted tickets. using two GPUs, I’m able to guess 952 million passwords a second — that’s a lot of passwords!

Cracking at 944 million password guesses a second with RC4 encrypted tickets, 25 minutes to crack.

After enforcing AES-256 encryption via GPO, we are now presented with a $krb5tgs$18$ ticket, indicating that it is encrypted with AES.

When loading into hashcat and running in mode 19700, we are now running at only 1.2 million passwords a second. Don’t get me wrong, it’s better than guessing manually — but 800 times slower is not as fun.

Much slower cracking speeds with an AES encrypted ticket. Over 13 days to crack!

If you’ve been paying attention, you’ll notice that RC4 tickets took only 25 minutes to exhaust the keyspace — AES is over 13 days. The computational intensity of AES instead of RC4 slows down our cracking process significantly.

Impact

With RC4 encrypted tickets, it takes less than two seconds to crack the password badpass. With an AES encrypted ticket, the same password takes over 21 minutes. Threat actors can pivot faster and crack more accounts when RC4 encryption is allowed.

As defenders, we want to make exploitation more difficult for attackers. The longer it takes an attacker to execute an attack, the higher our chances are to catch them.

Remediation

To fix this, we can define the GPO to use only AES-256 bit encryption. This is within the Group Policy Management Editor within Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options is the Network security: Configure encryption types allowed for Kerberos.

Ensure AES256_HMAC_SHA1 and Future Encryption Types are selected within the checkboxes.

Ensure only the AES256_HMAC_SHA1 is selected for maximum protection

To add to this, setting strong passwords will enhance the protections and make it more difficult for attackers to leverage.

Identify and understand the purpose of all SPNs on the network. Are they required for operations?
Use strong passwords for accounts with SPNs. When was the password last set? Is the password sufficiently lengthy and complex?
Consider implementing Group Managed Service Accounts (GMSA). This stores SPN passwords within Active Directory and are updated regularly.

We can upgrade to Windows Server 2022 which deprecates RC4 from the domain as well. This is a simple resolution.

References

Enjoyed this post? Consider checking out my book (once it’s published!)