Fallback Kerberos RC4 Active Directory: cómo detectarlo, por qué sigue ocurriendo y cómo eliminarlo

El fallback kerberos rc4 active directory describe la situación en la que un controlador de dominio sigue emitiendo material Kerberos con RC4 porque el cliente, el servicio, las claves de la cuenta o la configuración efectiva de tipos de cifrado no permiten que el intercambio se mantenga en AES. Eso sigue importando en 2026 porque los tickets de servicio respaldados por RC4 mantienen vigente la parte de cracking offline de Kerberoasting, incluso en dominios que ya parecen modernos sobre el papel.

Este artículo no es una segunda guía sobre Kerberoasting. Tampoco cubre el ángulo de Silver Ticket. Es una guía de detección y remediación para demostrar dónde se sigue usando RC4, por qué el KDC sigue eligiéndolo y cómo eliminar esa dependencia sin romper la autenticación.

Fallback Kerberos RC4 Active Directory: qué significa realmente

En la práctica, el fallback de Kerberos RC4 no es una sola configuración. Es el resultado de que el KDC elija RC4 para un ticket o una clave de sesión porque AES no está disponible, no se anuncia, todavía no se ha generado para la cuenta o queda excluido por la configuración efectiva.

Microsoft lo explica ahora con claridad. En su guía actual de Kerberos, Microsoft dice que RC4 está siendo retirado, que las actualizaciones de Windows publicadas el 8 de noviembre de 2022 o después cambiaron el comportamiento predeterminado de Kerberos para preferir AES-SHA1 en cuentas donde no se había configurado explícitamente un tipo de cifrado, y que RC4 sigue apareciendo en cuentas que no admiten AES-SHA1. Por eso este tema encaja tanto en una revisión de seguridad AD orientada a la evidencia como en un plan de hardening AD orientado a prioridades.

Por qué RC4 sigue apareciendo en entornos AD modernos

El error más común es asumir que ver RC4 en un ticket siempre significa que hay un único GPO mal configurado. La documentación actual de Microsoft apunta a varias causas raíz distintas, y no todas se remedian de la misma forma.

Aquí importan dos puntos de Microsoft.

Primero, los cambios de Kerberos del 8 de noviembre de 2022 no eliminaron RC4 en todas partes. Microsoft Support dice que esas actualizaciones establecieron AES como tipo de cifrado predeterminado para claves de sesión en cuentas que no estaban marcadas previamente con un tipo de cifrado predeterminado, mientras que Microsoft Learn dice que RC4 sigue apareciendo en cuentas que no admiten AES-SHA1.

Segundo, las cuentas de equipo y las cuentas de usuario o servicio no se comportan igual. Microsoft Support dice que los equipos Windows establecen automáticamente msDS-SupportedEncryptionTypes para sus cuentas de máquina según la policy local de Kerberos, pero las cuentas de usuario, group Managed Service Accounts y otras cuentas de AD no reciben ese valor automáticamente. Esa diferencia es una de las razones principales por las que las cuentas de servicio siguen apareciendo en investigaciones de RC4.

Cómo detectar el fallback de Kerberos RC4

En la mayoría de los entornos, la detección empieza en los controladores de dominio, no en el host del servicio que finalmente recibe el ticket. Microsoft Learn dice que los detalles de uso de Kerberos RC4 se registran en los Security logs de los KDC en Windows Server 2019 y posteriores, y que Windows Server 2016 también ganó visibilidad de RC4 en estos eventos tras la cumulative update de enero de 2025.

Empiece con estas fuentes de datos:

Si ya centraliza la telemetría de DC, esto debe vivir junto a los eventos de Kerberos cubiertos en Supervision Seguridad AD: Event IDs y SIEM, no en un informe ad hoc aparte.

Qué dice realmente Event ID 4769

Event ID 4769 es el lugar más práctico para demostrar el fallback de Kerberos RC4 porque Microsoft documenta tanto el valor de cifrado del ticket como los campos de contexto circundantes.

Dos detalles importan de inmediato:

1. Microsoft documenta Ticket Encryption Type = 0x17 como RC4-HMAC, y 0x18 como RC4-HMAC-EXP.
2. Microsoft también dice que, desde Windows Vista y Windows Server 2008, los valores esperados de cifrado para tickets de servicio son 0x11 y 0x12, que son algoritmos de la familia AES.

Eso convierte a 4769 en una de las maneras más limpias de demostrar que RC4 sigue emitiéndose.

Nota: no confunda Ticket Encryption Type = 0x17 en Event ID 4769 con msDS-SupportedEncryptionTypes = 0x18 o DefaultDomainSupportedEncTypes = 0x18. En Event 4769, 0x17 y 0x18 son valores de ticket de la familia RC4. En el contexto del bitmask de AD y KDC, 0x18 significa solo AES128 más AES256.

Esa distinción importa porque es fácil construir la remediación equivocada si se mezclan valores de evento con bitmasks de AD.

Cuando investigue 4769, úselo junto con el contexto de la cuenta:

• Si Ticket Encryption Type pertenece a la familia RC4 y la cuenta de servicio no tiene claves AES, el historial de contraseñas suele ser la causa real.
• Si el cliente o el destino no anuncia AES, normalmente está implicada la compatibilidad de policy o de plataforma.
• Si los campos del evento sugieren que una cuenta solo admite el comportamiento predeterminado, revise si esa cuenta realmente tiene un valor msDS-SupportedEncryptionTypes sin procesar en AD o si el KDC está recurriendo al valor predeterminado del dominio.

Causas raíz comunes detrás de la emisión de tickets RC4

Cuentas antiguas sin claves AES regeneradas

Microsoft Learn dice que si una cuenta de usuario se creó antes de que se añadiera soporte AES-SHA1 a Windows Kerberos y la contraseña nunca se restableció después de ese cambio, la cuenta puede carecer de claves AES-SHA1. Microsoft relaciona esto con la introducción histórica del soporte AES en Windows Server 2003 y dice explícitamente que cambiar la contraseña de la cuenta genera las claves que faltan.

Por eso la limpieza de RC4 es en parte un problema de ciclo de vida de contraseñas y no solo de policy de protocolo. También explica por qué este tema suele solaparse con los problemas de higiene de cuentas de servicio descritos en Active Directory Password Security: Misconfigurations That Matter.

msDS-SupportedEncryptionTypes está ausente, incompleto o mal interpretado

Microsoft Support dice que, si una cuenta no tiene definido msDS-SupportedEncryptionTypes, o está definido como 0, los controladores de dominio suponen un valor predeterminado de 0x27 o usan el ajuste de registro DefaultDomainSupportedEncTypes. Microsoft Learn también dice que el KDC usa el valor predeterminado del dominio cuando la máquina de origen o de destino no tiene un valor definido.

Eso significa que RC4 puede seguir apareciendo sin que un administrador haya marcado explícitamente ninguna casilla RC4 en la propia cuenta.

Use los comandos de Microsoft para inspeccionar qué está realmente configurado.

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

Esa consulta proviene de Microsoft Support y sirve específicamente para encontrar cuentas donde DES o RC4 están habilitados explícitamente pero AES no.

Para revisar un solo objeto, Microsoft Learn muestra este patrón:

$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"

Dispositivos y servicios legacy que todavía no admiten AES

La documentación de Microsoft sobre la policy de Kerberos sigue advirtiendo que el ajuste Network security: Configure encryption types allowed for Kerberos puede afectar a la compatibilidad con equipos cliente, servicios y aplicaciones. La misma guía de Microsoft Learn dice que la última plataforma Windows que no admitía AES-SHA1 fue Windows Server 2003 y recomienda migrar los dispositivos que siguen dependiendo de ese comportamiento antiguo.

Aquí es donde el fallback RC4 deja de ser una casilla y se convierte en un problema de ingeniería. Si deshabilita RC4 antes de entender qué clientes y servicios siguen necesitándolo, cambia un problema de seguridad por una interrupción de autenticación.

Casos límite de integración Linux

Microsoft documenta ahora un escenario específico de integración Linux en el que AD DS sigue emitiendo tickets cifrados con RC4. En ese caso, Event ID 4769 muestra Ticket Encryption Type: 0x17, y Microsoft dice que forzar msDS-SupportedEncryptionTypes a 24 (0x18) o cambiar el GPO de tipos de cifrado de Kerberos no resuelve el problema.

La razón documentada es más estrecha que decir «Linux causa RC4». Microsoft dice que el problema se produce porque el atributo operatingSystemVersion se interpreta de una forma que hace que el KDC trate la cuenta como si los tipos de cifrado admitidos no estuvieran rellenados, lo que lleva al KDC a usar en su lugar tipos de cifrado asumidos como compatibles.

Ese caso límite merece atención porque demuestra que algunos hallazgos de RC4 se deben a la semántica de metadatos del directorio, no solo a una deriva evidente de policy.

Cómo remediar dependencias RC4 de forma segura

El orden de remediación más seguro es progresivo.

Actionable next steps

Empiece confirmando la emisión RC4, agrupando las cuentas afectadas y tratando esta limpieza dentro del mismo flujo que un plan de hardening AD orientado a prioridades antes de cualquier endurecimiento global.

1. Demostrar dónde se emite RC4 antes de cambiar valores predeterminados

No empiece deshabilitando RC4 en todo el dominio. Empiece demostrando dónde sigue emitiéndose RC4 en 4769 y a qué cuenta o servicio corresponde cada evento. Si ha actualizado los controladores de dominio con las actualizaciones de Windows del 13 de enero de 2026 o posteriores, supervise también los eventos de auditoría Kdcsvc introducidos para la ruta de endurecimiento de tickets de servicio RC4.

2. Regenerar claves AES que faltan cuando esa es la causa real

Si una cuenta antigua de usuario o servicio no tiene claves AES, Microsoft dice que cambiar la contraseña de la cuenta las genera. Eso debe suceder antes de introducir cambios más amplios del lado del KDC. Para cuentas de servicio con SPN, este es también el punto en el que el riesgo se solapa con Kerberoasting: los tickets respaldados por RC4 son más fáciles de convertir en cracking offline cuando también existen contraseñas débiles o reutilizadas.

3. Separar la configuración AD sin procesar del comportamiento efectivo del KDC

Compruebe el atributo msDS-SupportedEncryptionTypes sin procesar y compárelo con lo que muestra el evento. Si el atributo está vacío o vale 0, el KDC puede estar usando DefaultDomainSupportedEncTypes en su lugar. Si una cuenta de máquina establece el valor automáticamente según la policy local, corrija la policy del dispositivo. Si una cuenta de usuario o servicio necesita un valor explícito, cambie esa cuenta de forma deliberada en lugar de cambiar primero el valor predeterminado del dominio completo.

4. Eliminar dependencias legacy antes de endurecer la policy de Kerberos

Si el cliente, el servicio, el appliance o la pila no Windows no admiten realmente AES, la propia guía de Microsoft es migrar o sustituir cuando sea posible. Por eso la documentación del GPO de Kerberos sigue advirtiendo del impacto de compatibilidad. La limpieza de RC4 debe eliminar primero dependencias legacy, no fingir que no existen.

5. Usar Protected Users solo donde realmente encaja

Microsoft documenta que Protected Users restringe a sus miembros a AES para Kerberos, deja de crear claves DES o RC4 y evita DES o RC4 en la preauthentication de Kerberos. Eso hace que el grupo sea útil para cuentas humanas concretas que ya pueden funcionar limpiamente sobre AES.

No es una palanca universal de remediación RC4. Microsoft advierte explícitamente que no se añadan cuentas de servicio ni cuentas de equipo a Protected Users. En otras palabras, Protected Users es un control dirigido para las cuentas de usuario adecuadas, no un sustituto para arreglar cuentas de servicio, dispositivos o configuración de KDC.

6. Prepararse para los cambios predeterminados de RC4 en 2026 con fechas explícitas

La guía de Microsoft sobre tickets de servicio RC4 añade una segunda cronología que importa operativamente:

• January 13, 2026: comienza la fase de despliegue inicial y se añaden eventos de auditoría para el comportamiento RC4 predeterminado de riesgo.
• April 14, 2026: la fase de aplicación cambia el valor predeterminado DefaultDomainSupportedEncTypes para operaciones de KDC a 0x18, es decir, solo AES-SHA1, para cuentas que no tienen un valor explícito de msDS-SupportedEncryptionTypes.
• July 2026: Microsoft dice que se elimina el control temporal de rollback para este comportamiento y la aplicación pasa a ser el modo permanente.

Esa es la cronología actual de Microsoft. Si todavía necesita RC4 después del 14 de abril de 2026, Microsoft dice que debe habilitarse explícitamente en el bitmask msDS-SupportedEncryptionTypes de la cuenta de servicio en lugar de depender del antiguo comportamiento predeterminado.

Validación después de pasar a AES

Ha terminado cuando cambia la evidencia, no cuando el GPO parece más limpio.

Valide el cambio en este orden:

1. Confirmar que las nuevas entradas de Event ID 4769 para los servicios remediados ya no muestran valores de ticket de la familia RC4.
2. Confirmar que en su lugar aparecen los valores esperados de la familia AES, normalmente 0x11 o 0x12.
3. Confirmar que la cuenta ahora tiene claves AES si el restablecimiento de contraseña era la corrección prevista.
4. Confirmar que la autenticación del servicio sigue funcionando tras restablecer contraseñas, reiniciar servicios o cambiar ajustes de cuenta.
5. En controladores de dominio actualizados para la ruta de endurecimiento de 2026, confirmar que no hay advertencias ni errores relevantes de Kdcsvc 201-209 para las rutas remediadas.
6. Probar explícitamente la interoperabilidad no Windows. Microsoft dice que la ausencia de eventos de auditoría no garantiza que todos los dispositivos no Windows sigan funcionando después de la actualización de aplicación del 14 de abril de 2026.

Si quiere seguir esto en el tiempo en lugar de tratarlo como una limpieza puntual, intégrelo en un workflow de auditoría recurrente y manténgalo en la misma familia de controles que las configuraciones incorrectas de seguridad de Active Directory más comunes que alimentan la deriva de identidad.

Cómo detecta EtcSec el fallback de Kerberos RC4

EtcSec detecta el fallback de Kerberos RC4 correlacionando la evidencia que Microsoft expone ahora de forma operativa:

• emisión de tickets de servicio Kerberos de la familia RC4
• cuentas que todavía dependen de configuraciones de cifrado predeterminadas o explícitas compatibles con RC4
• principales que carecen de claves AES utilizables después de deriva por antigüedad de la cuenta o historial de contraseñas
• rutas de cuentas de servicio en las que se solapan el fallback RC4 y la exposición a tickets susceptibles de cracking

Eso permite a los equipos volver a medir tras restablecer contraseñas, cambiar ajustes de cuentas, limpiar servicios legacy y endurecer el KDC, en lugar de tratar RC4 como una revisión puntual.

Referencias primarias

• Detect and remediate RC4 usage in Kerberos
• Event 4769: A Kerberos service ticket was requested
• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833
• Protected Users security group
• Preventing Kerberos change password that uses RC4 secret keys
• Linux accounts can't get AES-encrypted tickets in AD DS
• Network security: Configure encryption types allowed for Kerberos