RC4DefaultDisablementPhase - Cómo identificar las cuentas afectadas por el hardening de Kerberos

Con un comando, os ayudamos a obtener un listado de cuentas a las que les afectará el próximo hardening de Kerberos, con la llegada de la clave de registro RC4DefaultDisablementPhase, así como repasamos los nuevos eventos lanzados por Microsoft en la actualización acumulativa de Enero.

El hardening de Kerberos documentado en el KB5073381 está cada vez más cerca de forzarse. En sólo unas semanas Microsoft lanzará una actualización acumulativa que establecerá AES256 como cifrado predeterminado en cuentas de servicio. A estas alturas es recomendable tener avanzada la auditoría de uso de RC4, tema del que trataré en este contenido. Y ¡ojo!, porque se vienen sorpresas...

Comando para identificar las cuentas con posible afectación

Hay tres criterios para identificar cuentas que podrían darnos problemas de autenticación con el hardening de Kerberos:

Es una cuenta de usuario, máquina o servicio. No influye en relaciones de confianza.
La cuenta tiene registrado uno o más SPN.
La cuenta no tiene establecido el campo msDS-SupportedEncryptionTypes, o lo tiene a valor 0.

Este punto de partida es esencial para una completa visión de la posible afectación. Y para obtener todas las cuentas, podemos beneficiarnos de un comando que he preparado:

get-adobject -filter "(-not msDS-SupportedEncryptionTypes -bor 0x1f) -and ServicePrincipalName -like '*' -and (objectclass -eq 'computer' -or objectclass -eq 'user' -or objectclass -eq 'msDS-ManagedServiceAccount' -or objectclass -eq 'msDS-GroupManagedServiceAccount' -or objectclass -eq 'msDS-DelegatedManagedServiceAccount')"

Con el resultado de este comando, deberemos ir avisando a los responsables de cada una de las cuentas para que confirmen con sus proveedores de aplicaciones que estas últimas son compatibles con cifrado AES256.

Eventos dedicados al hardening

Si en los Controladores de Dominio ya hemos instalado la actualización acumulativa de Enero 2026 o alguna de las posteriores, contamos con eventos de auditoría que nos ayudarán parcialmente en el hardening. La aparición de unos u otros depende parcialmente de si tenemos configuradas las siguientes claves de registro en Controladores de Dominio:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC
DefaultDomainSupportedEncTypes
Valores: msDS-SupportedEncryptionTypes

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\kerberos\parameters
RC4DefaultDisablementPhase
Valores: Sin auditoría (0), Modo Auditoría (1), Forzado de hardening (2).

Los eventos están enumerados del 201 al 209 y aparecerán en el log de Sistema de los DCs. Su aparición nos alertará de situaciones a regularizar, poniendo el acento en equipos cliente que no soportan AES y cuentas de servicio que no disponen de hashes AES en AD. Este es el resumen de sus condiciones de aparición:

Evento 201

Máquina cliente sólo puede usar RC4.
Servicio sin msDS-SupportedEncryptionTypes definido.
DC sin DefaultDomainSupportedEncTypes definido.
RC4DefaultDisablementPhase con valor 1.

Evento 202

Servicio sin claves AES.
Servicio sin msDS-SupportedEncryptionTypes definido.
DC sin DefaultDomainSupportedEncTypes definido.
RC4DefaultDisablementPhase con valor 1.

Evento 203

Máquina cliente sólo puede usar RC4.
Servicio sin msDS-SupportedEncryptionTypes definido.
DC sin DefaultDomainSupportedEncTypes definido.
RC4DefaultDisablementPhase con valor 2.

Evento 204

Servicio sin claves AES.
Servicio sin msDS-SupportedEncryptionTypes definido.
DC sin DefaultDomainSupportedEncTypes definido.
RC4DefaultDisablementPhase con valor 2.

Evento 205

DC con DefaultDomainSupportedEncTypes definido con un valor sin AES.

Evento 206

Cliente sólo puede usar RC4.
msDS-SupportedEncryptionTypes o DefaultDomainSupportedEncTypes con valor solo AES.
RC4DefaultDisablementPhase con valor 1.

Evento 207

Servicio sin claves AES.
msDS-SupportedEncryptionTypes o DefaultDomainSupportedEncTypes con valor solo AES.
RC4DefaultDisablementPhase con valor 1.

Evento 208

Cliente sólo puede usar RC4.
msDS-SupportedEncryptionTypes o DefaultDomainSupportedEncTypes con valor solo AES.
RC4DefaultDisablementPhase con valor 2.

Evento 209

Servicio sin claves AES.
msDS-SupportedEncryptionTypes o DefaultDomainSupportedEncTypes con valor solo AES.
RC4DefaultDisablementPhase con valor 2.

Los equipos cliente que sólo pueden usar RC4 deben modificar la política ‘Network Security: Configure Encryption Types allowed for Kerberos’. Por su parte, los servicios sin claves AES requerirán de un reset de contraseña (y probablemente, recreación de keytab) para que se genere sólo una clave RC4. Como curiosidad, si una cuenta sólo dispone de claves AES en AD, probablemente no se le haya cambiado la contraseña desde antes de la entrada de Windows Server 2008 en un DC del dominio… o se ha forzado una situación muy extraña para que no las tenga (no es fácil generar una cuenta sólo con contraseñas en RC4).

Cabe resaltar que estas situaciones de las que alerta Microsoft, especialmente las de los eventos 206 y 207, son situaciones anómalas. Debido a un glitch, sigue siendo posible obtener tickets con cifrado RC4 aún cuando la cuenta de servicio trata de forzar el uso de AES256. Esto se corrige con el hardening, dejando de ser posible aprovecharse de esta pequeña brecha de seguridad.

Obtención de TGS: evento 4769

A mayores de los eventos propios del hardening, también disponemos de los eventos del log de Seguridad que nos informan de la generación de tickets de Kerberos: 4768 (TGT) y 4769 (TGS). Como sólo estamos interesados en servicios, atenderemos únicamente a los eventos 4769. ¿Qué nos aporta a mayores? Nos ayuda a ver con qué servicios se está usando RC4. Debemos fijarnos en el service name para saber qué cuenta de servicio es y en el ticket encryption type (etype). Aquellos que salgan con valor 0x17 (23) o 0x18 (24) evidencian un uso actual de RC4. Lógicamente, con la ingente cantidad de eventos en el log de Seguridad, se hace imprescindible el uso de un SIEM para filtrar información entre millones de eventos.

Conclusión

Hemos visto hasta 3 formas de obtener cuentas y auditoría de cara a evitar impacto en cuanto salga la actualización de abril. Las tres tienen su sentido y son útiles en mayor o menor medida. Pero, ¿por qué necesitamos tanta información?

El comando para identificar cuentas con posible afectación sirve como base para saber qué cuentas nos pueden dar problemas si el servicio no es compatible con AES256. O sea, todas las cuentas afectadas por la modificación del DDSET.
La auditoría de los eventos 201-209 nos ayuda a identificar equipos cliente que no soportan AES y cuentas de servicio sin claves AES. Ambas casuísticas anticipan problemas de autenticación tras el hardening, incluso aquellos problemas derivados de un glitch que Microsoft va a solventar. Sin embargo, servicios que usen keytabs con RC4 podrían pasar desapercibidos en estos eventos.
El evento 4769 muestra información de cada ticket TGS generado. Esto nos sirve para identificar si una cuenta con posible afectación está siendo realmente utilizada para servicios. Es posible que tengamos cuentas con SPNs que no se están utilizando y, por lo tanto, no nos darán afectación con el hardening.

En el próximo contenido, el último de esta serie dedicada al hardening de Kerberos, os mostraré cómo ir afrontando las distintas fases de este hardening, con las actualizaciones acumulativas de enero, abril y julio. ¡Espero que os sea de utilidad!