Guía paso a paso - Hardening de Kerberos (KB5073381)

Pasos iniciales

1. Recopilar las cuentas de usuario, equipo o servicio con al menos un SPN y el atributo msDS-SET vacío.

2. Listar los equipos con un OperatingSystemVersion numérico inferior a 6. Dichos equipos no utilizarán el campo msDS-SET.

3. Recopilar eventos 4768 y 4769 para obtener el uso de RC4 (etype 0x17) tanto en ticket como en clave de sesión. A ser posible, ayudarse de herramientas de SIEM. En entornos pequeños ambién es posible ayudarse de los scripts oficiales Get-KerbEncryptionUsage.ps1 y List-AccountKeys.ps1.

4. Instalar la actualización acumulativa de enero en DCs. Esta actualización activa la auditoría que nos ayudará a prever problemas con la llegada del hardening.

5. Obtener los eventos 201, 202, 206 y 207 en DCs. Estos nos avisarán de problemas con los cifrados en equipos cliente y/o en cuentas de servicio.

6. Obtener el evento 205 o revisar que la clave de registro DefaultDomainSupportedEncTypes no esté creada en ningún DC. De estar creada, entender qué valor tiene y pensar en ponerla a futuro a valor 0x18 (solo AES).

Comunicación a responsables de cuentas

Con toda la auditoría obtenida, ya podemos iniciar acciones de comunicación a los responsables de las cuentas con posible afectación. A todos ellos les informaremos cuándo se forzará el hardening y propondremos una fecha anterior para migrar o corregir sus cuentas con anterioridad:

• Servicios con SPN y sin msDS-SET: Migrar sus servicios a AES con msDS-SET a valor 24.

• Equipos con OperatingSystemVersion inferior a 6: Limpiar este atributo y aplicar valor 24 a msDS-SET.

• Equipos sin soporte a AES (msDS-SET inferior a 8): Si son Windows, revisar GPO de Kerberos para habilitar AES. Si son Linux, recomendar la revisión de módulos instalados.

• Eventos 201 y 206: Avisar a los responsables de las máquinas (fijarse en la IP del Client Address) de que están usando RC4. Podemos revisar en AD si el msDS-SET de la máquina está configurado para no soportar AES o si tiene el OperatingSystemVersion a valor 5 o inferior. También podemos guiarnos de los eventos 4769 para ver si hay otros tickets en AES emitidos para dicha máquina. Es posible que sólo sea una aplicación y no toda la máquina en sí la que no soporte AES. En dicho caso, los responsables de la máquina deberán revisar configuraciones relacionadas con Kerberos (krb5.conf por ejemplo).

• Eventos 202 y 207: Es necesario comprobar si las cuentas de servicio son compatibles con AES, si hay que configurar los servicios para que lo usen (keytab) y hacer reset de contraseña.

Situación previa al hardening

La situación idónea antes de iniciar tareas de hardening es:

• Actualización acumulativa de enero o posterior instalada en todos los DCs.

• No tener eventos 201, 202, 206 o 207 en los últimos 7-14 días.

• En los eventos 4768 y 4769 de los últimos 7-14 días no ver ningún ticket o clave de sesión en RC4 (etype 0x17).

• Clave de registro DefaultDomainSupportedEncTypes no existe o tiene valor 0x18 o similar.

• Todas las cuentas con SPN ya dan soporte a AES en msDS-SET.

• Todos los equipos dan soporte a AES a través de GPO y msDS-SET.

• No hay equipos con OperatingSystemVersion inferior a 6 o, de haberlos, todos ellos son compatibles con AES y comprobamos su uso de AES en los eventos 4768-4769.

Hardening progresivo

De cara a evitar el mayor impacto posible, podemos optar a realizar un hardening progresivo en el que de menos a más, vamos realizando varias acciones con unos 7-14 días entre acción y acción, de cara a evaluar posibles impactos. Las claves de registro es mejor crearlas a través de una GPO sobre la OU de Domain Controllers:

1. Crear la clave de registro DefaultDomainSupportedEncTypes con valor 0x18 (24) en los DCs. Si algo fallase, usar la misma GPO para contraprogramar y así borrarla o volver al valor anterior.

2. Si todo ha ido bien, crear la clave de registro RC4DefaultDisablementPhase con valor 2 (forzado) en los DCs. Si algo fallase, usar la misma GPO aplicando valor 1 (auditoría).

3. Si todo sigue yendo bien, en principio ya no hay peligro. Podemos proceder a instalar la actualización acumulativa de abril en DCs, la cual no debería suponer ningún impacto.

4. Si sigue sin haber problemas, instalar la acumulativa de Julio en DCs, momento a partir del cual ya no habrá marcha atrás.