Strengthening Security: Disabling RC4 for Kerberos Ticket Generation

Introduction

From a security perspective, disabling the ability to generate a Kerberos Ticket using RC4 encryption is crucial for preventing attackers from easily obtaining password hashes. This blog post explores the steps and considerations involved in disabling RC4 for enhanced security. Additionally, two valuable resources on Kerberoasting attacks are provided for further information.

Kerberoasting Attack

This tutorial explains what Kerberoasting is and how to detect, mitigate and respond to these attacks.

Netwrix

Understanding Kerberoasting attacks and how to prevent them

Learn how Kerberoasting attacks on Active Directory unfold, why attackers love them, and key ways to combat them and improve security.

The Quest BlogMatthew Vinton

Disabling RC4 Encryption for Kerberos Ticket Generation: To effectively disable RC4 encryption in the domain, it is recommended to utilize Group Policy. Follow these steps:

1. Open the Group Policy Management (gpmc.msc) and navigate to Group Policy Objects.
2. Select a Group Policy that is applied to all computer objects in the domain (preferably a group of computers).
3. Right-click on the desired group policy object and choose "Edit" to open it.
4. Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
5. Open the policy "Network security: Configure encryption types allowed for Kerberos."
6. Deactivate the following entries by unchecking them and confirm by clicking "OK":

• DES_CBC_CRC
• DES_CBC_MD5
• RC4_HMAC_MD5

Enabling Kerberos Logging for Auditing: To ensure that RC4 encryption is disabled, it is recommended to enable Kerberos logging. This allows auditing of Kerberos tickets. If you use Microsoft Sentinel as your SIEM, you can leverage the following query from my github to find relevant Kerberos security events.

The Challenges Encountered

While following the above advice, disabling RC4 on workstations via Group Policy was successful without any issues. However, when attempting to do the same on servers, problems arose with SQL and other authentication methods, leading to the decision to revert the changes. Initially, it was suspected that modifying the passwords, which were originally set using RC4, would resolve the issue. However, this was not the case.

Investigating Domain Trust

Considering the use of an empty root design, which was a previous recommendation but is no longer suggested, the domain trust was examined to verify whether RC4 was involved. However, this analysis proved inconclusive in finding a resolution. You should review your trust to make sure that you have AES enabled. the steps listed below allow you to review your trust configuration and ensure that AES is enabled.

Configure the trust to support AES128 and AES 256 encryption instead of RC4 encryption

This method resembles method 1 in that you configure the trust attributes.

In the case of Windows forest trusts, both sides of the trust support AES. Therefore, all ticket requests on the trust use AES. However, a third-party Kerberos client that inspects the referral ticket might notify you that the ticket uses an encryption type that the client does not support. In order to continue to allow such a client to inspect the ticket, update it to support AES.

When you use this method, configure the trust by using the Active Directory Domains and Trusts MMC snap-in. To use this method, follow these steps:

1. In Active Directory Domains and Trusts, navigate to the trusted domain object (in the example,contoso.com). Right-click the object, select Properties, and then select Trusts.
2. In the Domains that trust this domain (incoming trusts) box, select the trusting domain (in the example, child.domain.com).

Select Properties, select The other domain supports Kerberos AES Encryption, and then select OK.

The Solution

Further investigation revealed that when Service Principal Names (SPNs) are assigned to accounts, the authentication method defaults to RC4. To disable RC4 for group managed service accounts, utilize the following command:

Set-ADServiceAccount gmsa-test01 -SamAccountName gmsa-newname -KerberosEncryptionType AES128, AES256

For regular user accounts, ensure that the account supports Kerberos AES 128 and 256-bit encryption, which disables the use of RC4.

The provided resource below discusses Kerberos encryption types and RC4 in more detail.

Decrypting the Selection of Supported Kerberos Encryption Types

In recent months Microsoft support has received a lot of questions regarding disabling RC4 for the encryption of Kerberos tickets. If I had to guess the CIS L1 Baseline and RFC 8429 guidance to disable RC4 is likely responsible for much of that interest. While RC4 has not been formally deprecate…

TECHCOMMUNITY.MICROSOFT.COMJerry Devore

Upon applying these changes to accounts configured with SPNs, Kerberos ceased using RC4 and instead utilized AES 256. Remarkably, this behavior of defaulting to the lowest encryption type with SPNs had not been widely discussed prior to reading the above article.

Conclusion

By diligently following the recommended steps to disable RC4 for Kerberos ticket generation, organizations can bolster their security posture and mitigate the risks associated with Kerberoasting attacks. Understanding the challenges faced during implementation and discovering viable solutions will aid others seeking to disable RC4 encryption effectively.