CVE-2026-20833 - What is Kerberos and how to face RC4 deprecation - Theory

Today I bring you some new content, this time theoretical, about Kerberos and the recent CVE-2026-20833, with which Microsoft will remove RC4 as the default encryption type for service accounts. In the coming weeks, I will show you how to perform (or avoid) this hardening step by step in a practical and secure way, so that when April comes around, you won't be affected.

Let's start by defining Kerberos. Kerberos is a user/password based authentication protocol used primarily in Active Directory. In AD, we also have another similar protocol called NTLM, but it is older and less secure than Kerberos due to its design.

Kerberos is based on tickets. After entering your credentials, a master ticket known as a Ticket Granting Ticket or TGT is generated. With this ticket, other tickets can be automatically obtained to access certain resources. These second tickets are called Ticket Granting Service or TGS.

Kerberos has many encryption types. Encryption uses one-way functions (OWF) to create a hash of the user's password, so that it will not have an inverse function to decrypt. This would not prevent possible dictionary attacks, especially if the hash is obtained, since it could be done offline without the security measures of our domain. On the other hand, Kerberos ciphers are also used to encrypt the tickets themselves with the session key.

Each TGS ticket is encrypted several times using the service account password, the end-user account password, the TGT ticket, and the current time or the public key of the certificate, if authenticating with a certificate. Although Kerberos is a user/password based protocol, there is an extension that also allows authentication with a certificate, which can be extended to Windows Hello for Business, allowing login with a PIN, fingerprint, iris recognition, or facial recognition. Even with this extension, Kerberos would still use the user's password to encrypt the tickets.

When the password is changed, a hash is generated in AD for each supported encryption type. Mainly in Kerberos there are up to 5 different encryption types:

• DES_CBC_CRC

• DES_CBC_MD5

• RC4_HMAC_MD5

• AES128_HMAC_SHA1

• AES256_HMAC_SHA1

To simplify things, we will refer to them as DES, RC4, and AES.

The two DES encryptions are the most insecure, and Microsoft stopped using them by default many years ago. Furthermore, they are no longer compatible on Windows Server 2025.

RC4 encryption is more secure than DES encryption, but less secure than AES encryption. That is why Microsoft continues to harden processes to remove it.

AES128 and AES256 were introduced in Windows Server 2008 and Windows 7. Previous operating systems are not compatible with these ciphers, which is why Microsoft has not yet gotten rid of RC4. Although Windows Server 2003 and Windows XP have been out of support for many years, dependence on RC4 remains present in many business environments. Third-party applications may also continue to use it.

In November 2022, Microsoft released an update that began to establish AES256 as the default encryption type for session keys, while RC4 remains the default encryption for tickets. Prior to that date, tickets were issued with RC4 encryption for both by default.

Starting in April 2026, Microsoft will set AES256 as the default encryption type for both tickets and session keys.

This hardening will only affect service accounts that do not have their supported encryption types defined in the msDS-SupportedEncryptionTypes attribute (we will refer to it as msDS-SET for short). By service accounts, we mean any account, user, computer, or MSA, that has at least one SPN.

This hardening does not directly affect trust relationships or domain-joined Windows computers (which define the msDS-SET attribute as soon as they join).

There is a registry key called DefaultDomainSupportedEncTypes, which allows you to modify the default encryption types in service accounts. In other words, it would allow us to remain as we were before hardening if we wish, although we do not recommend it.

In upcoming content, we will look at:

• Deciphering msDS-SupportedEncryptionTypes and etypes

• Remediation for hardening with DefaultSupportedEncryptionTypes

• Searching for affected accounts

• Step by step: procedure for hardening