Kerberos Armoring (FAST): Active Directory Flexible Authentication Secure Tunneling está desactivado por defecto

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling

Kerberos armoring, FAST, Active Directory Flexible Authentication Secure Tunneling: Microsoft agrupa todos estos nombres bajo una sola función, y en un dominio por defecto esa función está desactivada. Las dos directivas de grupo que la activan llegan configuradas como No configurada, de modo que el intercambio de autenticación que transporta material derivado de la contraseña circula por la red sin ningún canal protegido a su alrededor, aunque toda versión de Windows Server compatible ha podido blindarlo desde Windows Server 2012.

FAST está definido en RFC 6113, A Generalized Framework for Kerberos Pre-Authentication. IANA registra su tipo de dato de preautenticación PA-FX-FAST como padata type 136, junto con PA-FX-COOKIE (133), PA-FX-ERROR (137) y PA-ENCRYPTED-CHALLENGE (138). La propia descripción de Microsoft sobre la implementación en Windows es breve y precisa: «Flexible Authentication Secure Tunneling (FAST) proporciona un canal protegido entre el cliente Kerberos y el KDC. FAST se implementa como Kerberos armoring en Windows Server 2012, y solo está disponible para los intercambios del servicio de autenticación (AS) y del servicio de concesión de tickets (TGS)».

Microsoft enumera tres beneficios para los sistemas unidos al dominio, y el primero es la razón de ser de este artículo:

• Protección frente a ataques de diccionario offline. «Kerberos armoring protege los datos de preautenticación del usuario, que son vulnerables a ataques de diccionario offline cuando se generan a partir de una contraseña».
• Errores de Kerberos autenticados. El armoring «protege las autenticaciones Kerberos del usuario frente a la suplantación de errores Kerberos del KDC, que puede forzar una degradación a NTLM o a criptografía más débil».
• Autenticación compuesta (compound authentication), la extensión de identidad de dispositivo utilizada por Dynamic Access Control.

Fuente: What's New in Kerberos Authentication, Microsoft Learn.

Cómo funciona Kerberos armoring

FAST envuelve la solicitud real dentro de un intercambio externo cifrado con una armor key (clave de blindaje). El RFC 6113 indica claramente, en las definiciones ASN.1 tanto de la solicitud blindada como de la respuesta blindada, que «la clave de cifrado es la armor key». Un observador en la red ve el sobre blindado, no los datos de preautenticación que contiene.

Qué intercambios quedan realmente blindados

El origen de la armor key es la parte que suele confundir a la gente. Microsoft: «Kerberos armoring utiliza un ticket-granting ticket (TGT) del dispositivo para proteger los intercambios del servicio de autenticación con el KDC, por lo que el intercambio del servicio de autenticación del equipo no está blindado. El TGT del usuario se utiliza para proteger sus intercambios TGS con el KDC».

Léelo dos veces, porque ahí se define el límite exacto del control:

La autenticación inicial del propio equipo no puede blindarse, porque la armor key es precisamente lo que ese intercambio intenta obtener. A partir de ahí, cada inicio de sesión de usuario en ese equipo sí puede quedar blindado.

El RFC 6113 es explícito sobre el ataque que elimina: «El padata de preautenticación FAST de Kerberos definido en esta sección proporciona una herramienta para reducir significativamente la vulnerabilidad a los ataques de diccionario offline. Combinado con encrypted challenge, FAST obliga a un atacante a montar un ataque de intermediario (man-in-the-middle) exitoso para poder observar el texto cifrado».

Por qué la preautenticación sin blindar es recolectable

Sin FAST, el flujo estándar de preautenticación de Windows es PA-ENC-TIMESTAMP, el tipo de preautenticación 2, que Microsoft documenta como «un tipo normal para la autenticación estándar por contraseña». El cliente demuestra que conoce la contraseña cifrando una marca de tiempo con una clave derivada de esa contraseña, y el KDC devuelve un AS-REP cuya parte cifrada está protegida por esa misma clave derivada de la contraseña.

Ambas mitades son texto cifrado derivado de la contraseña, y el RFC 6113 describe la consecuencia sin rodeos: «Un atacante puede solicitar un AS-REP y probar varias contraseñas para ver si puede descifrar el ticket resultante».

El análisis de Kerberos armoring de Trimarc Security (publicado en julio de 2024) plantea el mismo argumento sobre la economía del ataque: «El proceso de intentar crackear una contraseña usando uno de estos métodos es completamente offline, lo que significa que un atacante puede dedicarle todo el tiempo que necesite».

Aquí es donde las recomendaciones habituales de remediación se quedan cortas. Las soluciones estándar para el AS-REP roasting y el Kerberoasting — contraseñas más largas, group managed service accounts, eliminar el fallback a RC4 — hacen todas que el crackeo sea más difícil. Ninguna de ellas impide que el material se recopile. FAST, en cambio, ataca el propio paso de recopilación, al colocar el intercambio dentro de un canal que quien recopila no puede leer.

Lo que el armoring sí cambia de forma estructural es la posición del recolector no autenticado. Cuando el KDC está configurado para rechazar los mensajes Kerberos sin blindar, una AS-REQ generada por una herramienta que no dispone de un TGT de dispositivo no puede blindarse, por lo que se rechaza antes de que se devuelva ningún AS-REP. Ese comportamiento se deriva directamente de la opción documentada «Fail unarmored authentication requests», descrita más abajo.

Las directivas de grupo que están desactivadas por defecto

Tres directivas rigen este comportamiento, repartidas en dos nodos de Plantillas administrativas. Las tres vienen como No configurada de fábrica.

Las rutas de registro, los nombres descriptivos y las descripciones citadas provienen de las referencias de Policy CSP ADMX_kdc y Kerberos.

Las cuatro opciones del KDC

La directiva del KDC tiene cuatro opciones, y las diferencias entre ellas no son cosméticas:

Dos consecuencias merecen estar en una nota adhesiva antes de que nadie toque la UO de controladores de dominio:

🚨 Peligro: la propia advertencia de Microsoft sobre la directiva del KDC: «Cuando se establece 'Fail unarmored authentication requests', los equipos cliente que no admiten Kerberos armoring dejarán de poder autenticarse ante el controlador de dominio». Cualquier cliente Kerberos que no pueda blindar sus mensajes —appliances, hosts que no son Windows, sistemas embebidos, cualquier cosa anterior a Windows 8 / Windows Server 2012— deja de autenticarse. Haz el inventario antes de imponer la directiva, no después.

La segunda: las dos opciones estrictas no hacen absolutamente nada por debajo del nivel funcional de dominio Windows Server 2012, y lo hacen sin avisar. Microsoft indica que ambas opciones «provocan fallos intermitentes de autenticación o de control de acceso si en el dominio hay algún controlador de dominio que no ejecute Windows Server 2012. Por lo tanto, ninguna de estas dos opciones surtirá efecto hasta que el dominio esté configurado en el nivel funcional Windows Server 2012. Hasta entonces, los controladores de dominio que ejecuten Windows Server 2012 se comportarán como si estuviera configurada la opción Supported». Un dominio que siga en el nivel funcional 2008 R2 puede configurar «Fail unarmored» y obtener en su lugar el comportamiento de Supported: armoring ofrecido a los clientes que lo solicitan, nada impuesto.

Detección

El estado del armoring se puede medir desde tres ángulos independientes: la configuración, la telemetría de autenticación en vivo y los eventos de salud del KDC.

Indicadores que revelan el estado del armoring

La tabla de tipos de preautenticación y las recomendaciones de monitorización provienen de la referencia de Microsoft para 4768(S, F) A Kerberos authentication ticket (TGT) was requested, que recomienda generar una alerta cuando el «valor no es 138 cuando Kerberos Armoring está habilitado para todas las comunicaciones Kerberos de la organización». Los eventos 33 y 34 y los contadores de rendimiento de FAST están documentados en What's New in Kerberos Authentication.

Comprobar si las directivas están configuradas

Empieza por el estado de configuración. Ejecuta esto en un controlador de dominio:

# Las opciones de imposición (enforcement) requieren nivel funcional de dominio Windows Server 2012 o superior
Get-ADDomain | Select-Object DNSRoot, DomainMode

# Lado KDC: si no devuelve nada, la directiva está en No configurada
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\KDC\Parameters' `
                 -Name EnableCbacAndArmor -ErrorAction SilentlyContinue

Luego el lado del cliente, en una estación de trabajo o en un servidor miembro:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
                 -Name EnableCbacAndArmor, RequireFast -ErrorAction SilentlyContinue

Medir cuántos inicios de sesión están realmente blindados

La configuración solo indica la intención. Para medir lo que realmente ocurre, agrupa las solicitudes de TGT en vivo por tipo de preautenticación en un controlador de dominio:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4768 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            PreAuthType = ($x.Event.EventData.Data |
                Where-Object { $_.GetAttribute('Name') -eq 'PreAuthType' }).'#text'
        }
    } |
    Group-Object PreAuthType |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Seleccionar el campo por su atributo Name en lugar de por índice posicional es importante: Microsoft distribuyó una versión actualizada del Event 4768 con campos adicionales en la actualización acumulativa de enero de 2025 para Windows Server 2016 y versiones posteriores, por lo que las posiciones de los campos difieren entre versiones del evento.

Para extraer directamente solo las solicitudes sin blindar:

Get-WinEvent -LogName Security -MaxEvents 50 -FilterXPath @"
*[System[EventID=4768] and EventData[Data[@Name='PreAuthType'] != '138']]
"@

Envía ese mismo flujo de eventos 4768 a la herramienta que ya utilices para la monitorización de eventos de Active Directory. La proporción del tipo 138 frente a todo lo demás es el único número que indica realmente cuánto ha avanzado una implementación.

Remediación

La implementación por fases

Despliega en este orden. La recomendación de Trimarc es inequívoca respecto a la secuencia: «Asegúrate de que Kerberos Armoring esté habilitado primero para los clientes… Este cambio debe aplicarse a todos los clientes antes de configurarse en los controladores de dominio».

1. Confirma el nivel funcional del dominio. Get-ADDomain | Select-Object DomainMode debe indicar Windows Server 2012 o superior antes de que las opciones de imposición hagan nada. Si todavía estás por debajo, esto se convierte primero en un proyecto de actualización del nivel funcional.

2. Habilita la directiva de cliente en todos los clientes. Configuración del equipo > Directivas > Plantillas administrativas > Sistema > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring → Enabled. Vincúlala a las UO de estaciones de trabajo y servidores miembro, no solo a un grupo piloto. Verifica que la directiva se aplicó realmente — una GPO rota o mal delimitada es el motivo más habitual por el que una implementación se detiene en silencio:

gpupdate /force
gpresult /h C:\Temp\kerberos-armoring.html

3. Configura la directiva del KDC en Supported en la UO de controladores de dominio. Configuración del equipo > Directivas > Plantillas administrativas > Sistema > KDC > KDC support for claims, compound authentication and Kerberos armoring → Enabled, opción Supported. Si después un controlador de dominio registra el evento de sistema 33, la resolución documentada por Microsoft es ejecutar gpupdate /force en un controlador de dominio.

4. Mide antes de imponer. Vigila los contadores de rendimiento KDC AS Requests with FAST y KDC armored TGS Requests, así como la distribución de tipos de preautenticación en el 4768. Cada principal que siga mostrando el tipo 2 es un cliente que dejará de funcionar en cuanto se imponga la directiva.

5. Inventaría los clientes que no pueden blindar. El soporte de armoring empieza con los clientes Windows 8 y Windows Server 2012. Los appliances, los hosts Linux y UNIX, los dispositivos de red y las pilas Kerberos heredadas necesitan cada uno una decisión explícita: actualizarlos, eximirlos mediante la delimitación por UO, o aceptar que la imposición los dejará fuera.

6. Solo entonces impón la directiva. En el lado del KDC, pasa a Fail unarmored authentication requests. En el lado del cliente, habilita Fail authentication requests when Kerberos armoring is not available. Haz esto de uno en uno, con un plan de reversión, y nunca los dos en la misma ventana de cambio.

Capacidad y coste antes de imponer la directiva

Despliega suficientes controladores de dominio capaces de blindar para soportar la carga antes de imponer la directiva. La referencia de ADMX_kdc advierte que un «número insuficiente de controladores de dominio que admitan esta directiva provoca fallos de autenticación siempre que se requiera Dynamic Access Control o Kerberos armoring».

Por último, presupuesta el coste. Microsoft es directa en esa misma referencia: «Kerberos armoring cifra por completo los mensajes Kerberos y firma los errores Kerberos, lo que se traduce en un mayor tiempo de procesamiento, pero no cambia el tamaño del ticket de servicio». Aquí el problema no es el crecimiento de los tickets; es la CPU del DC.

Cómo lo detecta EtcSec

El catálogo de vulnerabilidades de EtcSec recoge este control como dos comprobaciones independientes, porque la mitad del cliente y la mitad del KDC fallan de forma independiente, y un dominio puede tener perfectamente una sin la otra:

• KERBEROS_ARMORING_DC_DISABLED — Kerberos Armoring (FAST) no impuesto en los DC
• KERBEROS_ARMORING_CLIENT_DISABLED — Kerberos Armoring (FAST) no exigido en los clientes
• ANSSI_R27_KERBEROS_PREAUTH_NOT_FAST — la variante de este mismo control orientada a cumplimiento normativo (compliance)

Esas comprobaciones están correlacionadas con las entradas de superficie de ataque que realmente mitigan —ASREP_ROASTING_RISK, KERBEROASTING_RISK y KERBEROS_RC4_FALLBACK—, de modo que un informe muestra a la vez las cuentas expuestas al crackeo offline y si el control a nivel de protocolo que limita la recopilación está activado. Ese emparejamiento es la clave: una auditoría que reporta cuentas vulnerables a roasting sin reportar el estado del armoring solo describe la mitad del problema. Si estás realizando una revisión más amplia, este control encaja de forma natural junto al resto de una auditoría de seguridad de Active Directory.