A lo largo de la historia de Active Directory, los atacantes han ido descubriendo continuamente nuevas formas de explotar las vulnerabilidades del protocolo de autenticación Kerberos. Para ayudar a reducir los riesgos asociados al «kerberoasting», Microsoft dejará de recomendar el uso del cifrado RC4 a partir de abril de 2026. Si aún no ha identificado las aplicaciones de su entorno que podrían verse afectadas por este cambio, es hora de poner esa tarea en lo más alto de su lista de cosas por hacer. En esta publicación se explica el proceso y se le indican recursos que pueden resultarle útiles.
¿Por qué va a dejar de utilizar Microsoft el cifrado RC4?
Las tácticas, técnicas y procedimientos (TTP) que aprovechan Kerberos pueden clasificarse en tres categorías:
- Ataques de «roasting», como AS-REQ Roasting y Kerberoasting
- Abuso de la delegación, incluyendo la delegación Kerberos sin restricciones y la delegación restringida basada en recursos
- Abuso de entradas, incluyendo Golden Ticket, Silver Ticket, Diamond Ticket, Sapphire Ticket, Bronze Bit, Pass-the-Ticket, etc.
El «kerberoasting» se ha convertido en una de las técnicas de ataque más habituales. En los últimos años, Microsoft ha introducido medidas de defensa contra los ataques de «kerberoasting», y han aparecido numerosos artículos sobre este tema y sobre cómo mitigarlo. En esta entrada no vamos a profundizar en los detalles técnicos del ataque, pero, a grandes rasgos, así es como funciona:
- Un atacante solicita un ticket de servicio para un nombre de entidad de servicio (SPN) válido.
- El Centro de Distribución de Claves de Kerberos (KDC) emite el ticket de servicio utilizando el cifrado RC4, un algoritmo menos seguro que el AES-SHA1 (y, por lo tanto, más fácil de descifrar).
- El atacante retira este ticket de la red y utiliza un método de ataque por fuerza bruta para recuperar la contraseña de la cuenta.
- El atacante utiliza la cuenta comprometida para desplazarse lateralmente y elevar sus privilegios.
Debido al uso generalizado de RC4 en los ataques de tipo «kerberoasting», Microsoft ha anunciado que dejará de utilizar este método de cifrado; las auditorías comenzarán en enero de 2026, la aplicación de la medida con reversión manual tendrá lugar en abril de 2026 y la aplicación total se producirá en julio de 2026.
Sin embargo, muchas empresas siguen utilizando aplicaciones propias o de terceros que no admiten tipos de cifrado más seguros, como AES-128 y AES-256. Si su organización se encuentra en esta situación, deberá localizar las cuentas de esas aplicaciones y configurar el cifrado AES para cada una de ellas.
¿Qué aplicaciones utilizan RC4?
Entonces, ¿cómo se sabe qué aplicaciones utilizan RC4 como tipo de cifrado de Kerberos?
Deberá auditar el Servicio de autenticación de Kerberos y las operaciones de tickets de servicio de Kerberos para registrar los ID de evento 4768 (eventos del Servicio de autenticación) y 4769 (operaciones de tickets de servicio) en el registro de eventos de Seguridad. (Microsoft introdujo los ID de evento adicionales 201-209, también conocidos como «fortalecimiento de KDC», con los parches de enero de 2026 en el registro de eventos del sistema para respaldar aún más la iniciativa de retirada de RC4. Sin embargo, los eventos 4768 y 4769 pueden considerarse los eventos «principales», por lo que esta publicación se centra en el seguimiento de estos dos eventos.)
Analicemos esos acontecimientos.
ID de evento 4768
La figura 1 muestra un ejemplo de un mensaje del ID de evento 4768.
Se ha solicitado un ticket de autenticación Kerberos (TGT).
Información de la cuenta:
Nombre de la cuenta: jdoe
Nombre del dominio proporcionado: CHILD
ID de usuario: S-1-5-21-1873250772-3107742394-1596888999-1114
Tipos de cifrado compatibles con MSDS: 0x27 (DES, RC4, AES-Sk)
Claves disponibles: AES-SHA1, RC4
Información del servicio:
Nombre del servicio: krbtgt
ID del servicio: S-1-5-21-1873250772-3107742394-1596888999-502
Tipos de cifrado compatibles con MSDS: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Claves disponibles: AES-SHA1, RC4
Información del controlador de dominio:
Tipos de cifrado admitidos por MSDS: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Claves disponibles: AES-SHA1, RC4
Información de red:
Dirección del cliente: ::ffff:10.1.1.250
Puerto del cliente: 53904
Tipos de cifrado anunciados:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
DES-CBC-MD5
Información adicional:
Opciones de ticket: 0x40810010
Código de resultado: 0x0
Tipo de cifrado del ticket: 0x12
Tipo de cifrado de sesión: 0x12
Tipo de preautenticación: 2
Tipo de cifrado de preautenticación: 0x12
--Resto omitido por brevedad.--
Figura 1. Ejemplo de resultado del ID de evento 4768
Este ejemplo contiene varios conjuntos de información relevante.
Información de la cuenta
- Nombre de la cuenta. La identidad que solicita el Ticket Granting Ticket (TGT)
- Nombre del dominio proporcionado. El dominio en el que reside la identidad
- ID de usuario. El nombre descriptivo (o SID) de la identidad
- MSDS-SupportedEncryptionTypes. Los tipos de cifrado que puede utilizar la cuenta
Información sobre el servicio
- Nombre del servicio. El principal de servicio solicitado (en este caso, krbtgt)
- ID del servicio. El nombre descriptivo (o SID) de la entidad de servicio solicitada
- MSDS-SupportedEncryptionTypes. Los tipos de cifrado que puede utilizar la cuenta de servicio
Información sobre el controlador de dominio (DC)
- MSDS-SupportedEncryptionTypes. Los tipos de cifrado que admite el servidor de dominio
Información adicional
- Opciones de ticket: 0x40810010 (reenvíable, renovable, canónico, renovable-ok), tal y como se muestra en la figura 2.
- Tipo de cifrado del ticket: 0x12 (AES256), tal y como se muestra en la figura 3.
- Tipo de cifrado de sesión. 0x12 (AES256), tal y como se muestra en la figura 3.
- Tipo de cifrado de preautenticación: 0x12 (AES256), tal y como se muestra en la figura 4.
ID de evento 4769
La figura 5 muestra un ejemplo de un mensaje del ID de evento 4769.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {5f752786-c7b3-fb33-0ce8-a54adeea22c3}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: S-1-5-21-1873250772-3107742394-1596888999-1105
MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 53905
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x12
Session Encryption Type: 0x12
Failure Code: 0x0
Transited Services: -
--Remainder snipped brevity--
Figura 5. Ejemplo de resultado del ID de evento 4769
Este ejemplo contiene varios conjuntos de información relevante.
Información sobre el servicio
- Nombre del servicio. El SPN de la solicitud de ticket de servicio (en este caso, para host/childmember.child.contoso.com), tal y como se muestra en la figura 6.
sname-string: 2 elementos\
SNameString: host\
SNameString: childmember.child.contoso.com
Figura 6. Fragmento de un registro de Wireshark en el que se muestra el SPN de la solicitud del ticket de servicio
- ID de servicio. El nombre descriptivo (o SID) del sujeto de seguridad que registró el SPN
- MSDS-SupportedEncryptionTypes. Los tipos de cifrado que puede utilizar la cuenta de servicio
Información sobre DC
- MSDS-SupportedEncryptionTypes. Los tipos de cifrado que admite el servidor de dominio
Información adicional
- Opciones de entradas. 0x40810000
- Tipo de cifrado del ticket. 0x12 (AES256)
- Tipo de cifrado de sesión. 0x12 (AES256)
Cuando se utiliza RC4 para el cifrado, los resultados son ligeramente diferentes a los de los ejemplos anteriores. La figura 7 muestra el mensaje del evento ID 4769 para un equipo cliente que utiliza únicamente el cifrado RC4.
A Kerberos service ticket was requested.
Account Information:
Account Name: jdoe@CHILD.CONTOSO.COM
Account Domain: CHILD.CONTOSO.COM
Logon GUID: {df8a66a8-8c1d-061e-b216-f935b45eb88a}
MSDS-SupportedEncryptionTypes: N/A
Available Keys: N/A
Service Information:
Service Name: CHILDMEMBER$
Service ID: CHILD\CHILDMEMBER$
MSDS-SupportedEncryptionTypes: 0x4 (RC4)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Client Address: ::ffff:10.1.1.250
Client Port: 51299
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
RC4-HMAC-NT
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Session Encryption Type: 0x17
Failure Code: 0x0
Transited Services: -
--Remainder snipped for brevity--
Figura 7. Resultado del ID de evento 4769 en un equipo cliente que utiliza únicamente RC4
Las partes en negrita muestran las diferencias clave entre este caso y los ejemplos anteriores. Analicémoslas.
Información sobre el servicio
- Nombre del servicio: CHILDMEMBER$ (igual que en el ejemplo anterior)
- ID del servicio. El nombre descriptivo (o SID) de la entidad de servicio solicitada
- Tipos de cifrado compatibles con MSDS. 0x4 (RC4)
Información adicional
- Opciones de entradas. 0x40810000 (igual que en el ejemplo anterior)
- Tipo de cifrado del ticket: 0x17 (RC4-HMAC)
- Tipo de cifrado de sesión. 0x17 (RC4-HMAC)
Cómo realizar una auditoría de tu entorno para detectar aplicaciones que utilicen RC4
Como muestra el ejemplo anterior sobre RC4, para detectar el cifrado RC4 en tu entorno, debes revisar los registros de eventos (preferiblemente los registros SIEM) en busca de solicitudes (AS-REQ) y respuestas (AS-REP) del servicio de autenticación, así como de solicitudes (TGS-REQ) y respuestas (TGS-REP) del servicio de concesión de tickets, con los tipos de cifrado de ticket y de sesión 0x17.
Para ayudarte con esta tarea, hemos creado consultas de ejemplo tanto para Microsoft Sentinel como para Splunk. Puedes utilizar estos ejemplos como plantillas para auditar tu propio entorno.
Dependiendo de cómo hayas configurado el reenvío de eventos para Sentinel, deberás consultar DeviceEvents o WindowsEvent. Por ejemplo, si utilizas el reenvío de eventos de Windows para recopilar registros de eventos y reenviarlos a Sentinel, deberás consultar WindowsEvent y buscar únicamente las instancias de los ID de evento 4768 y 4769 que coincidan con 0x17 en el «Tipo de cifrado de ticket» o en el «Tipo de cifrado de sesión».
Puedes utilizar la siguiente consulta para buscar en Sentinel. Esta consulta se ha ampliado para incluir otras columnas de datos.
WindowsEvent
| where EventID in ('4768', '4769')
| where TimeGenerated between (ago(60d) .. now())
| extend EventDataJson = parse_json(EventData)
| extend TargetUserName = EventDataJson.TargetUserName
| extend TargetDomainName = EventDataJson.TargetDomainName
| extend IpAddress = EventDataJson.IpAddress
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
| extend ServiceName = EventDataJson.ServiceName
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
| extend TicketEncryption = EventDataJson.TicketEncryptionType
| extend TicketOptions = EventDataJson.TicketOptions
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
A continuación, te ofrecemos un breve resumen de la consulta:
WindowsEvent
Cómo se almacena la consulta en esta implementación de Sentinel (en tu entorno podría tratarse de DeviceEvents, tal y como se ha descrito anteriormente)
| where EventID in ('4768', '4769')
Búsquedas de los ID de evento 4768 y 4769
| where TimeGenerated between (ago(60d) .. now())
Se remonta a 60 días atrás (puedes configurar el valor que desees)
| extend EventDataJson = parse_json(EventData)
Da formato a la columna «EventData» en JSON y analiza el JSON para utilizarlo en el resto de la consulta
| extend TargetUserName = EventDataJson.TargetUserName
Especifica la identidad que solicita el ticket
| extend TargetDomainName = EventDataJson.TargetDomainName
Especifica el dominio en el que reside la identidad solicitante
| extend IpAddress = EventDataJson.IpAddress
Muestra la dirección IP del cliente, si aparece en el evento
| extend ServiceAvailableKeys = EventDataJson.ServiceAvailableKeys
Indica las claves de cifrado disponibles para el servicio
| extend ServiceName = EventDataJson.ServiceName
Especifica el SPN al que se refiere la solicitud de ticket
| extend SessionKeyEncryption = EventDataJson.SessionKeyEncryptionType
Especifica el tipo de cifrado de la clave de sesión que el cliente (solicitante) utilizará para interactuar con el propietario del ticket
| extend TicketEncryption = EventDataJson.TicketEncryptionType
Especifica el tipo de cifrado del TGT o del ticket de servicio
| extend TicketOptions = EventDataJson.TicketOptions
Proporciona información adicional sobre las opciones de los tickets de la solicitud, lo que puede resultar útil para identificar opciones como los tickets de remisión, los de delegación, los reenviados, los de representación, etc.
| where SessionKeyEncryption == '0x17' or
TicketEncryption == '0x17'
Busca un cifrado de clave de sesión o un cifrado de ticket que sea RC4-HMAC (0x17)
| project TimeGenerated, EventID, TargetUserName, TargetDomainName, IpAddress, ServiceName, TicketEncryption, SessionKeyEncryption, TicketOptions, ServiceAvailableKeys, EventDataJson
Indica los campos que se mostrarán en la visualización de resultados
La figura 8 muestra un ejemplo de los resultados de esta consulta.
En Splunk, esta misma consulta tendría el siguiente aspecto:
index="wineventlog" LogName="Security" EventCode IN ("4768", "4769") earliest=-60d@d latest=now
| search Session_Encryption_Type="0x17" or Ticket_Encryption_Type="0x17"
| tabla _time Código_evento Nombre_cuenta Dominio_cuenta Dirección_cliente nombre_servicio Tipo_cifrado_ticket Tipo_cifrado_sesión Opciones_ticket, _raw
Antes de utilizar estas consultas en su entorno, asegúrese de que tiene habilitada la auditoría de tickets de servicio. Si no está habilitada, los servidores de dominio no generarán los eventos correspondientes (los ID de evento 4768 y 4769, así como los ID de evento 201-209, relacionados con el refuerzo de seguridad del KDC).
La mejor forma de habilitar la auditoría de tickets de servicio es actualizar una política de grupo existente o añadir una nueva asignada a la unidad de organización (OU) de tu controlador de dominio (DC). Debe realizar esto para cada dominio de su bosque de AD. La ruta de acceso a la configuración correspondiente es Configuración del equipo > Configuración de Windows > Configuración de seguridad > Configuración avanzada de la política de auditoría > Políticas de auditoría > Inicio de sesión de cuenta. Habilite las subcategorías Auditar el servicio de autenticación Kerberos y Auditar las operaciones de tickets del servicio Kerberos tanto para éxitos como para fallos ( Figura 9).
Si nunca ha configurado una política de auditoría avanzada en sus dominios, asegúrese también de habilitar la política «Auditoría: Forzar la configuración de la subcategoría de la política de auditoría (Windows Vista o posterior) para anular la configuración de la categoría de la política de auditoría» en «Configuración del equipo > Configuración de Windows > Configuración de seguridad > Políticas locales > Opciones de seguridad». Esta política suele configurarse en la misma política de grupo que la «Auditoría de tickets de servicio».
Nota: Si no ves ningún evento de ticket de servicio 4769 en los registros de eventos de seguridad de tus controladores de dominio, tampoco verás las advertencias de refuerzo de seguridad del KDC (201-209) en el registro del sistema.
Consejo de validación: Obliga temporalmente a un dispositivo a admitir únicamente RC4 y solicita un ticket de servicio desde una cuenta que no contenga ningún valor en msDS-SupportedEncryptionTypes. Si la auditoría está configurada correctamente, deberías ver las advertencias correspondientes. Para obtener más información, consulta el artículo de Microsoft Learn«Detectar y corregir el uso de RC4 en Kerberos».
Una vez que se haya comprobado que la auditoría de Kerberos funciona correctamente, comienza el verdadero trabajo: analizar los eventos que se reciben y solucionar los problemas de las cuentas o los sistemas afectados.
La principal dificultad para eliminar RC4 radica en las cuentas de servicio heredadas cuyas contraseñas no se han cambiado en muchos años. Dado que RC4 en Active Directory está vinculado al hash NT, cualquier cuenta cuya contraseña no se haya restablecido tras la introducción de AES (es decir, tras el lanzamiento de Windows Server 2008 y Windows Vista) podría seguir teniendo únicamente claves compatibles con RC4.
La única forma de solucionar esto es restableciendo dos veces la contraseña de la cuenta de servicio, lo que obliga a Active Directory a generar las claves AES necesarias. Sin embargo, también tendrás que saber dónde se utiliza esa cuenta de servicio en tu entorno; por ejemplo, para iniciar el servicio correspondiente en un servidor miembro concreto o para ejecutar una tarea programada.
Si ves advertencias relacionadas con el refuerzo de seguridad de KDC (eventos 201-209 en el registro del sistema) junto a los eventos 4768 o 4769, esta publicación de LinkedIn de Jerry Devore, de Microsoft, ofrece una excelente descripción general de cómo solucionar el problema en las cuentas y los sistemas correspondientes, donde msds-SET = msDS-SupportedEncryptionTypes (Tabla 1).
| Par de eventos | Qué significa | Causa principal | Solución rápida |
|---|---|---|---|
| 201/203 | Cliente solo para RC4 + msds-SET vacío | Dispositivo heredado o keytab | Habilita AES en el cliente O bien establece msds-SET en 28 |
| 202/204 | La cuenta carece de clave AES + msds-SET vacío | Contraseña anterior | Restablecer la contraseña de la cuenta (dos veces) |
| 205 | Tipos de cifrado compatibles con el dominio predeterminado que se utilizan | Se ha anulado la configuración del Registro | Elimina la anulación si es posible |
| 206/208 | Cliente solo RC4 + msds-SET solo AES | Incompatibilidad del cliente | Añadir RC4 a msds-SET (valor 28) |
| 207/209 | La cuenta carece de clave AES + AES msds-SET | No se ha restablecido la contraseña | Restablecer la contraseña de la cuenta (dos veces) |
Lo esencial para los administradores de TI
- Comprueba ahora qué cuentas y dispositivos siguen vinculados a RC4.
- Actualice las cuentas de servicio a configuraciones compatibles con AES antes de que se aplique la normativa de forma generalizada o se deje de utilizar el algoritmo RC4.
- Elimine o actualice los sistemas heredados que no sean compatibles con AES.
- Utiliza los registros de eventos de forma proactiva para detectar los dispositivos problemáticos antes de que fallen, algo que sin duda ocurrirá tras aplicar las actualizaciones de julio de 2026.
¿Necesitas más ayuda?
La retirada de RC4 es un paso positivo en la lucha contra el «kerberoasting», pero requiere actuar con rapidez. Si tienes alguna duda sobre estas cuestiones o necesitas ayuda para migrar las cuentas de tus aplicaciones, estamos a tu disposición.
