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

El fallback kerberos rc4 active directory se produce cuando 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. 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.

Qué significa el fallback de Kerberos RC4 en Active Directory

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 una GPO incorrecta. La documentación actual de Microsoft señala varias causas raíz distintas, y no todas se remedian de la misma manera.

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 el tipo de cifrado predeterminado para las claves de sesión en cuentas que aún no estaban marcadas 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 de servicio no se comportan igual. Microsoft Support dice que los equipos Windows configuran automáticamente msDS-SupportedEncryptionTypes para sus cuentas de máquina según la política Kerberos local, pero las cuentas de usuario, las group Managed Service Accounts y otras cuentas de AD no tienen ese valor configurado automáticamente. Esa diferencia es una de las principales razones por las que las cuentas de servicio siguen apareciendo en las investigaciones de RC4.

Cómo detectar el fallback de Kerberos RC4

En la mayoría de los entornos, la detección comienza 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 RC4 en Kerberos se registran en los registros de seguridad de los KDC para Windows Server 2019 y versiones posteriores, y que Windows Server 2016 también obtuvo visibilidad del uso de RC4 en estos eventos después de la actualización acumulativa de enero de 2025.

Empiece con estas fuentes de datos:

Si ya centraliza la telemetría de los DC, esto debería figurar junto a los eventos de Kerberos tratados en Supervisión de Active Directory: los Event IDs de seguridad que importan, no en un informe ad hoc independiente.

Qué le dice realmente el Event ID 4769

El 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 que lo rodean.

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, a partir de Windows Vista y Windows Server 2008, los valores de cifrado esperados para el ticket de servicio son 0x11 y 0x12, que son algoritmos de la familia AES.

Eso convierte a 4769 en una de las formas más claras de demostrar que RC4 se sigue emitiendo.

Esa distinción importa porque es fácil construir la remediación equivocada si se mezclan los valores del evento con los valores de la máscara de bits de AD.

Cuando investigue 4769, hágalo junto con el contexto de la cuenta que lo rodea:

• Si Ticket Encryption Type es de la familia RC4 y la cuenta de servicio no tiene claves AES, el historial de contraseñas suele ser el problema real.
• Si el cliente o el destino no anuncia AES, normalmente hay un problema de política o de compatibilidad de plataforma.
• Si los campos del evento sugieren que una cuenta solo admite el comportamiento predeterminado, revise si la cuenta realmente tiene un valor bruto de msDS-SupportedEncryptionTypes 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 el soporte de AES-SHA1 a Windows Kerberos y la contraseña nunca se restableció después de añadirse ese soporte, es posible que a la cuenta le falten claves AES-SHA1, y que cambiar la contraseña de la cuenta genera esas claves faltantes.

Una advertencia sobre las fechas, porque las propias páginas de Microsoft se contradicen entre sí. La página de remediación de RC4 afirma que el soporte de AES-SHA1 en Windows Kerberos "se añadió en Windows Server 2003", pero la misma página también llama a Windows Server 2003 la última versión de Windows que no admitía AES-SHA1. Las demás referencias de Microsoft son coherentes con la segunda lectura: la documentación de la política de Kerberos indica que AES128_HMAC_SHA1 y AES256_HMAC_SHA1 "no son compatibles con Windows 2000 Server, Windows XP ni Windows Server 2003", y la documentación del Event ID 4769 indica que 0x11 y 0x12 son "compatibles a partir de Windows Server 2008 y Windows Vista". Trate Windows Vista y Windows Server 2008 como el punto en el que AES-SHA1 pasó a estar disponible, y Windows Server 2003 como la última plataforma Windows sin él.

Por eso la limpieza de RC4 es en parte un problema del ciclo de vida de las contraseñas, y no solo un problema de política de protocolo. También explica por qué el problema suele solaparse con los problemas de higiene de cuentas de servicio descritos en Seguridad de contraseñas en AD: las malas configuraciones que abren el dominio.

msDS-SupportedEncryptionTypes está ausente, incompleto o mal interpretado

Microsoft Support dice que si una cuenta no tiene configurado msDS-SupportedEncryptionTypes, o está establecido en 0, los controladores de dominio asumen un valor predeterminado de 0x27 o usan la configuración 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 una casilla de RC4 en la propia cuenta.

Use los propios comandos de Microsoft para inspeccionar lo que realmente está configurado.

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

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

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 heredados que aún no admiten AES

La documentación de la política de Kerberos de Microsoft sigue advirtiendo que la configuración Network security: Configure encryption types allowed for Kerberos "podría afectar la compatibilidad con equipos cliente o con servicios y aplicaciones". Por separado —y esto proviene de la guía de detección y remediación de RC4 de Microsoft, no de la página de políticas— Microsoft dice que la última versión de Windows que no admitía AES-SHA1 fue Windows Server 2003, y recomienda migrar a una versión de Windows que sí lo admita.

Aquí es donde el fallback de RC4 se convierte en un problema de ingeniería y no en una simple casilla que marcar. Si deshabilita RC4 antes de entender qué clientes y servicios todavía lo necesitan, cambia un problema de seguridad por una interrupción de la autenticación.

Casos límite de integración con Linux

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

La razón documentada es más específica que "Linux causa RC4". Microsoft dice que el problema ocurre porque el atributo operatingSystemVersion se interpreta de una manera que hace que el KDC trate la cuenta como si los tipos de cifrado admitidos no estuvieran definidos, lo que provoca que el KDC use en su lugar los tipos de cifrado admitidos asumidos.

Las soluciones documentadas por Microsoft son igual de específicas: eliminar el atributo operatingSystemVersion, establecer su valor de modo que el primer carácter no sea un dígito, o pasar a una versión del sistema que cumpla con la especificación.

Este es un caso límite que vale la pena conocer porque demuestra que algunos hallazgos de RC4 se deben a la semántica de los metadatos del directorio, y no solo a una deriva evidente de las políticas.

Cómo remediar dependencias RC4 de forma segura

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

1. Demuestre dónde se está emitiendo RC4 antes de cambiar los valores predeterminados

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

2. Regenere las claves AES faltantes donde esa sea la causa real

Si a una cuenta antigua de usuario o de servicio le faltan claves AES, Microsoft dice que cambiar la contraseña de la cuenta las genera. Eso debería ocurrir antes de hacer cambios más amplios del lado del KDC. Para las 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 trabajo de cracking offline cuando también hay contraseñas débiles o reutilizadas.

3. Separe la configuración bruta de AD del comportamiento efectivo del KDC

Revise el atributo bruto msDS-SupportedEncryptionTypes y compárelo con lo que muestra el evento. Si el atributo está vacío o en 0, es posible que el KDC esté usando DefaultDomainSupportedEncTypes en su lugar. Si una cuenta de equipo está estableciendo el valor automáticamente según la política local, corrija la política del dispositivo. Si una cuenta de usuario o de servicio necesita un valor explícito, cambie esa cuenta de forma deliberada en lugar de cambiar primero todo el valor predeterminado del dominio.

4. Elimine las dependencias heredadas antes de endurecer la política de Kerberos

Si el cliente, servicio, appliance o stack no Windows realmente no admite AES, la propia guía de Microsoft recomienda migrarlo o reemplazarlo cuando sea posible. Por eso la documentación de la GPO de Kerberos sigue advirtiendo sobre el impacto en la compatibilidad. La limpieza de RC4 debe eliminar primero las dependencias heredadas, no fingir que no existen.

5. Use Protected Users solo donde realmente encaje

Microsoft documenta que Protected Users restringe a sus miembros a usar AES para Kerberos, deja de crear claves DES o RC4, e impide DES o RC4 en la preautenticación de Kerberos. Eso hace que el grupo sea útil para determinadas cuentas humanas que ya pueden operar limpiamente con AES.

No es una palanca universal de remediación de RC4. Microsoft advierte explícitamente que nunca se deben añadir a Protected Users cuentas de servicios ni de equipos. En otras palabras, Protected Users es un control específico para las cuentas de usuario adecuadas, no un sustituto para corregir la configuración de las cuentas de servicio, los dispositivos o el KDC — el mismo problema de alcance tratado en Cuentas privilegiadas en Active Directory: Protected Users, delegación y brechas en cuentas de servicio.

6. Tenga en cuenta los cambios de 2026 en el valor predeterminado de RC4, que ya se han implementado

La guía de Microsoft sobre tickets de servicio con RC4 añade una segunda cronología que importa operativamente. Sus tres fases ya son pasado, por lo que esto ya no es trabajo de preparación: es el estado que debe asumir en los controladores de dominio actualizados:

• 13 de enero de 2026: se implementó la fase inicial de despliegue, advirtiendo de la aplicación forzosa que vendría y añadiendo eventos de auditoría para el comportamiento predeterminado de RC4 considerado de riesgo.
• 14 de abril de 2026: la fase de aplicación forzosa cambió el valor predeterminado de DefaultDomainSupportedEncTypes para las operaciones del KDC a 0x18, es decir, solo AES-SHA1, para las cuentas que no tienen un valor explícito de msDS-SupportedEncryptionTypes. En esta etapa, la aplicación forzosa todavía se podía revertir manualmente.
• Julio de 2026: las actualizaciones de Windows publicadas en julio de 2026 o después eliminaron el soporte de la subclave de registro RC4DefaultDisablementPhase, por lo que el control de reversión manual desapareció y la aplicación forzosa es ahora el modo permanente.

Si hoy todavía necesita RC4, Microsoft dice que lo configure explícitamente en el atributo msDS-SupportedEncryptionTypes de la cuenta de servicio en lugar de depender del antiguo comportamiento predeterminado, porque el valor predeterminado del dominio ya no lo proporciona.

Validación después de migrar a AES

Habrá terminado cuando cambie la evidencia, no cuando la GPO se vea más limpia.

Valide el cambio en este orden:

1. Confirme que las nuevas entradas del Event ID 4769 para los servicios remediados ya no muestran valores de ticket de la familia RC4.
2. Confirme que en su lugar aparecen los valores de ticket esperados de la familia AES, normalmente 0x11 o 0x12.
3. Confirme que la cuenta ahora tiene claves AES, si el restablecimiento de la contraseña era la corrección prevista.
4. Confirme que la autenticación del servicio sigue funcionando después de los restablecimientos de contraseña, los reinicios del servicio o los cambios en la configuración de la cuenta.
5. En los controladores de dominio actualizados para la ruta de endurecimiento de 2026, confirme que no hay advertencias ni errores relevantes de Kdcsvc 201-209 para las rutas remediadas.
6. Pruebe explícitamente la interoperabilidad con sistemas no Windows. Microsoft dice que la ausencia de eventos de auditoría no garantiza que todos los dispositivos no Windows acepten con éxito la autenticación Kerberos después de la actualización de abril de 2026.

Si quiere hacer seguimiento de esto a lo largo del tiempo en lugar de tratarlo como una limpieza puntual, incorpórelo a un flujo de auditoría recurrente y manténgalo en la misma familia de comprobaciones que las configuraciones incorrectas de seguridad de Active Directory más amplias que impulsan 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 ahora expone operativamente:

• Emisión de tickets de la familia RC4 en la telemetría de tickets de servicio Kerberos
• Cuentas que todavía dependen de configuraciones de cifrado predeterminadas o explícitas capaces de usar RC4
• Principales que carecen de claves AES utilizables debido a la antigüedad de la cuenta o a la deriva del historial de contraseñas
• Rutas de cuentas de servicio donde el fallback de RC4 y la exposición a tickets crackeables se solapan

Eso permite a los equipos volver a medir después de los restablecimientos de contraseña, los cambios en la configuración de las cuentas, la limpieza de servicios heredados y el endurecimiento del KDC, en lugar de tratar RC4 como un elemento de 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
• CVE-2026-20833 in the NVD
• 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