Endurecer Kerberos y NTLM en Active Directory

Aviso ético: el contenido de este módulo se explica con fines exclusivamente educativos y de defensa. Todas las técnicas de auditoría, migración de cifrado y rotación de claves descritas aquí deben aplicarse únicamente en entornos de laboratorio propios o en infraestructuras de producción para las que tengas autorización explícita por escrito. Modificar los tipos de cifrado Kerberos o rotar la cuenta krbtgt en un dominio de producción sin planificación puede provocar cortes de servicio; sigue siempre el proceso de cambio de tu organización.

Qué aprenderás

Cómo funciona el intercambio Kerberos en Active Directory: AS-REQ/AS-REP, el TGT, TGS-REQ/TGS-REP y el papel del PAC.
Cómo funciona NTLM (desafío-respuesta) y por qué sigue presente en la mayoría de los dominios.
Qué es msDS-SupportedEncryptionTypes y cómo eliminar DES y RC4-HMAC en favor de AES128/AES256.
Cómo rotar la cuenta krbtgt de forma segura con el script oficial de Microsoft y cuándo hacerlo con doble rotación.
Cómo configurar la política Kerberos (vida máxima del TGT, del ticket de servicio y renovación) desde GPO.
Por qué los SPN en cuentas de usuario habilitan kerberoasting y cómo mitigarlo con contraseñas largas o gMSA.
Cómo restringir NTLM de forma gradual con «Network security: Restrict NTLM», auditando con los eventos 8001-8004 del canal Microsoft-Windows-NTLM/Operational.
Qué son el Channel Binding y Extended Protection for Authentication (EPA) y por qué mitigan los ataques de relay NTLM.

Desarrollo

1. Cómo funciona Kerberos en Active Directory

Kerberos es el protocolo de autenticación por defecto en Active Directory desde Windows 2000, y sustituye a NTLM como mecanismo primario siempre que cliente y servidor son capaces de usarlo (equipos unidos al dominio, resolución de nombres correcta y ausencia de acceso por IP directa, entre otros requisitos). Se apoya en un tercero de confianza — el KDC (Key Distribution Center), que en AD corre en cada controlador de dominio como parte del servicio Kerberos Key Distribution Center — y en criptografía simétrica derivada de las contraseñas o claves de las cuentas.

El intercambio completo tiene dos fases claramente diferenciadas, cada una compuesta por un mensaje de petición y uno de respuesta:

Fase 1 — Autenticación inicial: AS-REQ / AS-REP

Cuando un usuario inicia sesión, su equipo envía un AS-REQ (Authentication Service Request) al servicio AS del KDC, dirigido al Authentication Service. Desde Windows Server 2008, este mensaje incluye preautenticación Kerberos (RFC 4120, PA-ENC-TIMESTAMP): una marca de tiempo cifrada con la clave derivada de la contraseña del usuario. El KDC descifra esa marca de tiempo con la clave que tiene almacenada para esa cuenta (derivada del hash de la contraseña); si el descifrado es correcto y la marca de tiempo está dentro de la ventana de tolerancia (5 minutos por defecto, gobernada por la política «Maximum tolerance for computer clock synchronization»), el KDC sabe que el solicitante conoce la contraseña sin que esta viaje por la red.

Si la preautenticación es válida, el KDC responde con un AS-REP que contiene:

Un TGT (Ticket Granting Ticket), cifrado con la clave secreta de la cuenta krbtgt (no con la clave del usuario). El TGT contiene el PAC (ver más abajo), el nombre del principal, la hora de expiración y la clave de sesión.
Una copia de la clave de sesión y otros datos, cifrados con la clave del usuario para que solo él pueda leerlos.

El equipo cliente cachea el TGT en memoria (LSASS) y ya no necesita volver a pedir la contraseña del usuario durante la validez del ticket.

Fase 2 — Obtención de tickets de servicio: TGS-REQ / TGS-REP

Cuando el usuario necesita acceder a un recurso de red (un recurso compartido SMB, un sitio web con autenticación integrada, una base de datos SQL Server), el cliente envía un TGS-REQ al servicio TGS (Ticket Granting Service, que también corre en el KDC) presentando el TGT y solicitando un ticket para el SPN (Service Principal Name) del recurso destino. El KDC valida el TGT (puede descifrarlo porque conoce la clave de krbtgt) y responde con un TGS-REP que contiene el ticket de servicio, cifrado esta vez con la clave de la cuenta que ejecuta el servicio destino (la cuenta de equipo, una cuenta de servicio tradicional o una gMSA).

El cliente presenta este ticket de servicio directamente al servidor de destino en el mensaje AP-REQ, sin volver a contactar con el KDC. El servidor lo descifra con su propia clave y, si es válido, concede acceso.

El PAC (Privilege Attribute Certificate)

El PAC es una estructura de datos que Microsoft añadió como extensión propietaria a Kerberos (documentada en [MS-PAC]) e incluye tanto en el TGT como en los tickets de servicio. Contiene la información de autorización que Kerberos «puro» no transporta: el SID del usuario, los SID de los grupos a los que pertenece (incluidos los de grupos universales de otros dominios del bosque), privilegios y, en versiones recientes, información de claims para control de acceso dinámico. Gracias al PAC, un servidor de recursos no necesita consultar a un controlador de dominio la pertenencia a grupos del usuario en cada acceso: la información ya viaja firmada dentro del ticket.

El PAC va firmado con dos firmas: la Server Signature (verificable por el servidor de recursos con su propia clave) y la KDC Signature (verificable solo por un controlador de dominio, típicamente durante la validación de un ticket entre bosques o cuando el servidor solicita validación explícita vía Netlogon). Estas firmas son la defensa nativa contra la falsificación de privilegios dentro de un ticket (el ataque conocido como Golden Ticket/Silver Ticket abusa precisamente de tener la clave con la que se firma o cifra el PAC; se trata en detalle en el módulo de movimiento lateral).

2. Cómo funciona NTLM (desafío-respuesta)

NTLM es el protocolo heredado de autenticación de Windows, anterior a Kerberos, y sigue activo por compatibilidad: se usa cuando no hay línea de visión a un KDC, cuando el recurso se accede por IP en lugar de por nombre, en autenticación local, en algunos escenarios de confianza entre bosques no transitivos y en aplicaciones antiguas que no soportan Kerberos.

El mecanismo es un desafío-respuesta en tres pasos, sin tercero de confianza directo cuando el servidor puede validar localmente (o con un controlador de dominio como validador, vía Netlogon, cuando el servidor no es el que posee la cuenta):

NEGOTIATE_MESSAGE: el cliente envía una solicitud de autenticación indicando las capacidades que soporta.
CHALLENGE_MESSAGE: el servidor genera un nonce aleatorio de 8 bytes (el «desafío») y lo envía al cliente.
AUTHENTICATE_MESSAGE: el cliente cifra el desafío con una clave derivada del hash de la contraseña del usuario y devuelve esa respuesta. El servidor (o el controlador de dominio, si el servidor delega la validación) repite el mismo cálculo con el hash que tiene almacenado y compara resultados.

Existen dos variantes con seguridad muy distinta:

NTLMv1: usa el hash LM y/o NT junto con DES para cifrar el desafío de 8 bytes. El espacio de claves efectivo es débil y vulnerable a ataques de fuerza bruta y a captura/relay con herramientas ampliamente disponibles. Se considera obsoleto e inseguro.
NTLMv2: introduce un desafío del cliente adicional, incorpora una marca de tiempo y usa HMAC-MD5 sobre el NT hash, lo que dificulta mucho más el cracking offline y añade protección frente a ataques de repetición. Es la variante mínima recomendable hoy.

NTLM no cifra ni firma por defecto el resto de la sesión (a menos que se negocie sellado/firmado adicional), no realiza autenticación mutua real del servidor frente al cliente, y es intrínsecamente vulnerable a ataques de relay: un atacante que intercepta un intento de autenticación NTLM puede reenviarlo («retransmitirlo») a otro servicio antes de que expire, autenticándose como la víctima sin conocer su contraseña. Esta es la razón de fondo por la que el endurecimiento de NTLM (o su eliminación) es una prioridad defensiva.

3. Tipos de cifrado Kerberos: de RC4 y DES a AES

El campo msDS-SupportedEncryptionTypes es un atributo de tipo entero (bitmask) presente en los objetos de usuario, equipo y cuentas de servicio administradas (gMSA) que indica qué tipos de cifrado puede usar esa cuenta para las claves derivadas de Kerberos. Cuando el KDC construye un TGT o un ticket de servicio, negocia el tipo de cifrado más fuerte que estén dispuestos a soportar simultáneamente el cliente, el KDC y la cuenta de destino.

Tipo de cifrado	Valor (bit)	Nivel de seguridad	Recomendación
DES-CBC-CRC / DES-CBC-MD5	0x1 / 0x2	Roto. Claves de 56 bits, trivialmente crackeables hoy.	Deshabilitado por defecto desde Windows Server 2008 R2 / Windows 7. Verificar que ningún objeto legado lo tenga forzado.
RC4-HMAC (RC4-HMAC-MD5, etype 23)	0x4	Débil. El hash NT de la contraseña ES la clave RC4; si se compromete (p. ej. vía DCSync o un Golden Ticket) permite falsificar tickets. Sin salt, vulnerable a cracking offline eficiente.	Eliminar tras auditar. Sigue habilitado por defecto en la mayoría de los dominios por compatibilidad histórica.
AES128-CTS-HMAC-SHA1-96 (etype 17)	0x8	Fuerte. Clave derivada con PBKDF2 e iteraciones (salted), resistente a cracking offline práctico.	Habilitar como mínimo aceptable. Preferible AES256 cuando el hardware/software lo soporte.
AES256-CTS-HMAC-SHA1-96 (etype 18)	0x10	Fuerte (estándar actual). Clave de 256 bits, salted.	Objetivo final para todas las cuentas: usuarios, equipos, cuentas de servicio y gMSA.
Future encryption types	0x20	Reservado para tipos de cifrado futuros no definidos aún.	Dejar en su valor por defecto; no afecta a la negociación actual.

El valor combinado más habitual como objetivo de endurecimiento es 24 (0x8 + 0x10 = AES128 + AES256), que deja fuera DES y RC4 por completo.

Consultar el estado actual antes de tocar nada

# Ver el valor bruto y decodificarlo para un usuario
Get-ADUser -Identity "svc-sqlbackup" -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

# Función auxiliar para decodificar el bitmask en texto legible
function Decode-KerbEncTypes {
    param([int]$Value)
    $types = @()
    if ($Value -band 0x1)  { $types += "DES-CBC-CRC" }
    if ($Value -band 0x2)  { $types += "DES-CBC-MD5" }
    if ($Value -band 0x4)  { $types += "RC4-HMAC" }
    if ($Value -band 0x8)  { $types += "AES128-CTS-HMAC-SHA1-96" }
    if ($Value -band 0x10) { $types += "AES256-CTS-HMAC-SHA1-96" }
    if ($types.Count -eq 0) { return "No definido (hereda comportamiento por defecto del dominio, normalmente RC4+AES)" }
    return $types -join ", "
}

# Barrido de todas las cuentas de servicio (SPN en usuario) para priorizar la migración
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
    Select-Object Name, ServicePrincipalName, @{N="EncTypes";E={Decode-KerbEncTypes $_."msDS-SupportedEncryptionTypes"}}

Forzar AES128/AES256 en usuarios, equipos y cuentas de servicio

# Cuenta de usuario / cuenta de servicio tradicional (SPN en usuario)
Set-ADUser -Identity "svc-sqlbackup" -KerberosEncryptionType AES128,AES256

# Cuenta de equipo
Set-ADComputer -Identity "SRV-APP01" -KerberosEncryptionType AES128,AES256

# gMSA (cuenta de servicio administrada de grupo) — mismo cmdlet de usuario aplicado al objeto gMSA
Set-ADServiceAccount -Identity "gmsa-webapp01" -KerberosEncryptionType AES128,AES256

# Verificación tras el cambio
Get-ADUser -Identity "svc-sqlbackup" -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes
# Debe devolver 24 (0x8 AES128 + 0x10 AES256)

Importante: cambiar msDS-SupportedEncryptionTypes no cambia por sí solo la clave AES almacenada para la cuenta si esta nunca se ha calculado. La clave AES se deriva y almacena la primera vez que la cuenta cambia su contraseña (o se fuerza con Set-ADAccountPassword/ksetup/reinicio de la cuenta de equipo) después de que el atributo permite AES. Por eso el proceso correcto en cuentas de servicio es: (1) fijar el atributo a AES128,AES256; (2) rotar la contraseña de la cuenta; (3) verificar en el siguiente TGS-REQ que el etype negociado es 17 o 18 (se ve en la traza de red o en el evento 4769 con «Ticket Encryption Type: 0x11/0x12»).

Endurecer la negociación a nivel de dominio (con cuidado)

La directiva de GPO «Network security: Configure encryption types allowed for Kerberos» (bajo Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options) controla qué tipos de cifrado puede negociar cada equipo al que se aplica. Marcar solo AES128_HMAC_SHA1 y AES256_HMAC_SHA1 en esta directiva, aplicada primero a un grupo piloto de servidores y estaciones, es la forma segura de ir retirando RC4 sin desactivarlo de golpe en todo el dominio.

4. La cuenta krbtgt y su rotación periódica

La cuenta krbtgt es una cuenta especial, deshabilitada e invisible en el uso normal, cuya clave secreta cifra y firma todos los TGT emitidos por todos los controladores de dominio del dominio (la clave se replica a todos los DC). Si un atacante obtiene el hash NT de krbtgt, puede fabricar TGT válidos para cualquier cuenta y cualquier pertenencia a grupos sin necesidad de conocer contraseñas reales — el ataque conocido como Golden Ticket, con validez limitada solo por la vida del ticket que el atacante decida fijar en el ticket falsificado.

Por esta razón, Microsoft recomienda rotar la contraseña de krbtgt de forma periódica (una referencia habitual en la industria es cada 180 días, alineada con la vida máxima recomendada de contraseñas de cuentas críticas) y, de forma obligatoria, tras cualquier incidente en el que se sospeche compromiso de credenciales privilegiadas o exfiltración de la base de datos NTDS.dit.

El proceso NO es simplemente Set-ADAccountPassword sobre krbtgt. krbtgt tiene historial de dos claves (actual y anterior) para no invalidar de golpe los TGT ya emitidos con la clave previa mientras siguen siendo válidos. Por eso Microsoft publica un script dedicado — el New-KrbtgtKeys.ps1 (script del equipo de Microsoft, distribuido históricamente en el repositorio de PowerShell Gallery/GitHub de Microsoft para este propósito específico) — que aplica las comprobaciones de seguridad necesarias (replicación sana, tiempo mínimo transcurrido desde el último cambio, etc.) antes de rotar.

# Comprobación previa: verificar el estado de replicación de todos los DC antes de tocar krbtgt
repadmin /replsummary
repadmin /showrepl * /csv > replsummary.csv

# Ejecución del script oficial de Microsoft (modo simulación primero)
.New-KrbtgtKeys.ps1 -Scope Domain -Simulate

# Rotación real (primera pasada)
.New-KrbtgtKeys.ps1 -Scope Domain

# Confirmar que la replicación ha propagado el cambio a todos los DC antes de la SEGUNDA pasada
repadmin /replsummary

# Segunda pasada (recomendada tras un incidente confirmado, para invalidar
# también los tickets falsificados con la clave "anterior" a la primera rotación).
# Esperar como mínimo el tiempo de vida máxima del TGT (por defecto 10 horas)
# más el margen de replicación entre la primera y la segunda pasada.
.New-KrbtgtKeys.ps1 -Scope Domain

La doble rotación (dos pasadas separadas por, como mínimo, el tiempo de vida máxima del TGT más el margen de replicación) es obligatoria en respuesta a incidente: una sola pasada deja viva la clave «anterior» durante el periodo de gracia, y un Golden Ticket fabricado con la clave comprometida seguiría siendo válido hasta esa segunda rotación. En un bosque con varios dominios, krbtgt existe por dominio y hay que rotarla en cada uno; adicionalmente, cada dominio tiene una cuenta krbtgt separada para tickets entre bosques (krbtgt_TRUSTNAME) si hay confianzas configuradas, que también debe considerarse.

5. Duración de tickets: política Kerberos

La política Kerberos se configura en GPO bajo Computer Configuration → Windows Settings → Security Settings → Account Policies → Kerberos Policy, y solo tiene efecto real cuando se vincula al nivel del dominio (los controladores de dominio ignoran esta política si se aplica a una OU distinta del dominio raíz). Los parámetros clave:

Maximum lifetime for user ticket (vida máxima del TGT): por defecto 10 horas. Pasado ese tiempo, el cliente debe volver a autenticarse (o renovar el TGT si aún está dentro de la ventana de renovación).
Maximum lifetime for service ticket (vida máxima del ticket de servicio, TGS): por defecto 600 minutos (10 horas), no puede superar la vida máxima del TGT.
Maximum lifetime for user ticket renewal: por defecto 7 días. Ventana total durante la cual un TGT puede renovarse sin volver a pedir credenciales completas.
Maximum tolerance for computer clock synchronization: por defecto 5 minutos. Si el reloj de un equipo se desincroniza más de ese margen respecto al DC, la preautenticación falla (error KRB_AP_ERR_SKEW).

Reducir la vida máxima del TGT (por ejemplo, a 4-6 horas en entornos de alta sensibilidad) limita la ventana de uso de un TGT robado, a costa de más reautenticaciones. Es un ajuste de compromiso que debe evaluarse junto con el impacto en la experiencia de usuario y en aplicaciones que mantienen sesiones largas.

6. SPN management: por qué un SPN en una cuenta de usuario es peligroso

Un SPN (Service Principal Name) identifica de forma única una instancia de servicio en el dominio (formato servicio/host:puerto, p. ej. MSSQLSvc/sql01.corp.local:1433) y se registra en el atributo servicePrincipalName del objeto que ejecuta ese servicio. Cuando el SPN está en una cuenta de equipo, la clave con la que se cifra el ticket de servicio se deriva de la contraseña del equipo: una cadena aleatoria de 120 caracteres, rotada automáticamente cada 30 días por defecto. Prácticamente imposible de crackear offline.

Cuando el SPN está registrado en una cuenta de usuario tradicional (el patrón clásico de «cuenta de servicio» para SQL Server, IIS con autenticación integrada, aplicaciones legacy), la clave del ticket se deriva de la contraseña que un humano eligió para esa cuenta. Cualquier usuario autenticado del dominio (sin privilegios especiales) puede solicitar un TGS-REQ para ese SPN — es una operación normal y no auditada por defecto salvo por el evento 4769 — y quedarse con el ticket de servicio cifrado. Ese ticket puede llevarse offline e intentar crackear la contraseña de la cuenta de servicio sin generar más tráfico ni bloqueos: es el ataque de kerberoasting, que se trata en profundidad en el módulo de movimiento lateral y persistencia. Aquí interesa la base defensiva:

Auditar y reducir SPN en cuentas de usuario. Inventariar con setspn -Q */* | Select-String "CN=" o con Get-ADUser -Filter { ServicePrincipalName -like "*" } y migrar a gMSA todo lo que la aplicación soporte.
Contraseñas largas y aleatorias para las cuentas de servicio que no puedan migrarse. 25+ caracteres aleatorios (gestionados por un vault, no memorizados) hacen el cracking offline inviable en la práctica, incluso con RC4. No es sustituto de migrar a AES ni de reducir el número de SPN en usuarios, pero mitiga el riesgo inmediato.
Migrar a gMSA (group Managed Service Account) siempre que la aplicación lo soporte (SQL Server, IIS Application Pools, servicios de Windows compatibles con Service Accounts modernas). La gMSA gestiona una contraseña de 240 bytes rotada automáticamente por AD (por defecto cada 30 días), sin que ningún humano la conozca ni tenga que gestionarla, eliminando el vector de kerberoasting práctico sobre esa cuenta.
Forzar AES en toda cuenta de servicio con SPN, como se describió en la sección 3, para que un ticket robado no pueda atacarse con las herramientas de cracking RC4 más eficientes (el cracking de AES es computacionalmente mucho más costoso, aunque una contraseña débil sigue siendo débil frente a un diccionario dirigido).

7. Restricción de NTLM: LmCompatibilityLevel y Restrict NTLM

LmCompatibilityLevel: el primer escalón

El valor LmCompatibilityLevel (configurable vía GPO como «Network security: LAN Manager authentication level», o directamente en el registro en HKLMSYSTEMCurrentControlSetControlLsa) determina qué variantes de LM/NTLM puede enviar un cliente y cuáles acepta un servidor:

Nivel	Descripción
0	Enviar respuestas LM y NTLM; nunca usar seguridad de sesión NTLMv2.
1	Enviar LM y NTLM; usar seguridad de sesión NTLMv2 si el servidor la soporta.
2	Enviar solo respuesta NTLM (sin LM).
3	Enviar solo respuesta NTLMv2. (Recomendado como mínimo en clientes modernos)
4	Enviar solo NTLMv2; el DC rechaza LM.
5	Enviar solo NTLMv2; el DC rechaza LM y NTLM (solo NTLMv2). Nivel objetivo recomendado.

Desde Windows Vista/Server 2008 el valor por defecto de fábrica ya es 3 en el cliente, pero conviene verificarlo explícitamente y llevarlo a 5 en todo el dominio antes de abordar la restricción de NTLM propiamente dicha, ya que «Restrict NTLM» no sustituye a este ajuste: LmCompatibilityLevel decide qué variante de NTLM se permite; Restrict NTLM decide si se permite NTLM en absoluto y hacia/desde quién.

«Network security: Restrict NTLM»: bloqueo gradual con auditoría previa

El conjunto de directivas «Restrict NTLM» (introducidas en Windows Server 2008 R2/Windows 7) permite auditar y, después, bloquear el uso de NTLM de forma progresiva, con excepciones granulares. Las directivas relevantes, todas bajo Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options:

Network security: Restrict NTLM: Audit Incoming NTLM Traffic — registra en el equipo que RECIBE la autenticación NTLM cada intento, sin bloquear nada. Es el primer paso obligatorio.
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers — configurada en el CLIENTE, controla/audita el NTLM que ese equipo envía hacia otros servidores. Valores: «Allow all», «Audit all» y «Deny all».
Network security: Restrict NTLM: Incoming NTLM traffic — configurada en el SERVIDOR/DC que recibe, decide si se permite, se audita o se deniega el NTLM entrante, con opciones intermedias como «Deny all domain accounts» o «Deny all accounts».
Network security: Restrict NTLM: NTLM authentication in this domain — aplicada en los DC, controla el NTLM que pasa por Netlogon a nivel de dominio.
Network security: Restrict NTLM: Add server exceptions in this domain y Add remote server exceptions for NTLM authentication — listas de excepciones (por nombre de servidor) que se exceptúan del bloqueo mientras se completa la migración de aplicaciones concretas que aún dependen de NTLM.

El proceso recomendado, en orden, es:

Activar solo auditoría («Audit Incoming NTLM Traffic» en todos los servidores y «Audit all» en «Outgoing NTLM traffic to remote servers» en los clientes) durante varias semanas.
Recolectar los eventos generados en el canal Microsoft-Windows-NTLM/Operational (deshabilitado por defecto; hay que habilitarlo con wevtutil o desde el Visor de eventos) en todos los equipos, idealmente centralizados vía forwarding a un colector o SIEM.
Identificar aplicaciones/servidores legítimos que aún dependen de NTLM y añadirlos como excepciones explícitas.
Pasar de «Audit» a «Deny» de forma incremental: primero en un grupo piloto, después en el resto, dejando las excepciones necesarias como último reducto documentado y con plan de migración.

Los eventos del canal NTLM: 8001-8004

El canal Microsoft-Windows-NTLM/Operational registra, cuando está habilitado y las directivas de auditoría/bloqueo NTLM están activas, los siguientes IDs de evento clave:

Event ID	Significado
8001	Auditoría de NTLM SALIENTE bloqueado (o que sería bloqueado en modo audit) desde este equipo hacia un servidor remoto, generado por la directiva «Outgoing NTLM traffic to remote servers».
8002	Auditoría de NTLM ENTRANTE aceptado en este equipo cuando se ha activado «Restrict NTLM: Incoming NTLM traffic» (en modo audit o allow con auditoría).
8003	Auditoría de NTLM ENTRANTE bloqueado (o que sería bloqueado en modo audit) en este equipo por la directiva de tráfico entrante.
8004	Auditoría de autenticación NTLM ENTRANTE en un controlador de dominio, generada por «NTLM authentication in this domain», cuando el DC valida (vía Netlogon) una autenticación NTLM que un servidor le ha reenviado para verificar.

Cada uno de estos eventos incluye el nombre del cliente, el nombre del servidor de destino, el nombre de dominio y el proceso que originó la solicitud (cuando aplica), lo que permite construir un inventario exacto de qué aplicaciones dependen todavía de NTLM antes de bloquearlo.

# Habilitar el canal operativo de NTLM (está deshabilitado por defecto)
wevtutil set-log "Microsoft-Windows-NTLM/Operational" /enabled:true

# Ruta del canal para consulta directa en el Visor de eventos / PowerShell
# Aplicaciones y servicios de registro > Microsoft > Windows > NTLM > Operational

# Consultar eventos de bloqueo/auditoría saliente (8001) de los últimos 7 días
Get-WinEvent -FilterHashtable @{
    LogName   = "Microsoft-Windows-NTLM/Operational"
    Id        = 8001,8002,8003,8004
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated -Descending

Channel Binding y Extended Protection for Authentication (EPA)

Incluso con NTLMv2, un ataque de relay sigue siendo posible si el protocolo de aplicación (LDAP, HTTP, SMB) no ata la autenticación al canal de transporte concreto por el que viaja. Extended Protection for Authentication (EPA), también llamado Channel Binding Tokens (CBT), añade a la respuesta NTLM/Kerberos un hash del canal TLS subyacente (el Channel Binding Token, derivado del certificado del servidor). Si un atacante intenta retransmitir esa autenticación a un canal TLS distinto (por ejemplo, capturarla en HTTP/LDAP sin TLS y reenviarla a LDAPS, o entre dos túneles TLS diferentes), el CBT no coincide y el servidor rechaza la autenticación.

Puntos de aplicación relevantes en AD:

LDAP Channel Binding en controladores de dominio (valor recomendado por Microsoft desde el aviso ADV190023: «Always» tras periodo de auditoría) mitiga relay hacia LDAP/LDAPS, el vector usado en ataques de relay hacia AD CS (ver módulo de PKI/AD CS) y otros.
SMB Signing (firma de paquetes SMB, distinta de EPA pero con el mismo objetivo de fondo: impedir que un mensaje interceptado se reproduzca o modifique en tránsito) debe forzarse en servidores y, cuando sea posible, en clientes.
EPA en servicios web con autenticación integrada (IIS) y en SQL Server, activable en la configuración de cada servicio, exige que el CBT coincida con el certificado TLS presentado.

Channel Binding y SMB Signing no sustituyen a la restricción de NTLM: son controles complementarios. Restrict NTLM reduce la superficie eliminando NTLM donde no hace falta; Channel Binding protege lo que queda de NTLM (y de Kerberos sobre canales no protegidos) frente al relay.

8. Comparativa: legacy (2003, NTLMv1/RC4) vs moderno (AES + NTLM restringido + Kerberos Armoring/FAST)

Aspecto	Entorno legacy (ej. dominio arrastrado desde Windows Server 2003)	Entorno moderno endurecido
Cifrado Kerberos por defecto	RC4-HMAC (etype 23), a veces DES aún presente en cuentas muy antiguas	AES256-CTS-HMAC-SHA1-96 / AES128 como mínimo (msDS-SupportedEncryptionTypes = 24)
NTLM	NTLMv1 permitido o incluso preferido (LmCompatibilityLevel bajo), sin auditoría de uso	NTLMv2 exclusivamente (nivel 5), tráfico auditado vía canal NTLM/Operational y restringido con «Restrict NTLM»
krbtgt	Sin rotación documentada, a veces con años de antigüedad desde la creación del dominio	Rotación periódica (referencia ~180 días) más rotación doble obligatoria tras incidente
Cuentas de servicio	SPN en cuentas de usuario con contraseñas cortas o sin rotar, vulnerables a kerberoasting con RC4	Migradas a gMSA donde es posible; contraseñas largas gestionadas por vault donde no; AES forzado
Protección contra relay	Sin SMB Signing forzado, sin LDAP Channel Binding, sin EPA	SMB Signing obligatorio, LDAP Channel Binding en «Always», EPA en servicios críticos
Robustez frente a preautenticación	Kerberos Armoring/FAST no disponible (requiere Windows Server 2012+ funcional y Compound Authentication habilitada)	Kerberos Armoring (FAST, RFC 6113) habilitado vía GPO «Kerberos client support for claims, compound authentication and Kerberos armoring», que cifra el AS-REQ inicial usando el TGT del equipo, mitigando ataques de fuerza bruta offline contra la preautenticación y habilitando políticas de acceso condicional basadas en el estado del dispositivo

Laboratorio: auditar NTLM saliente y migrar una cuenta de servicio a AES

Entorno mínimo: un controlador de dominio (Windows Server 2019/2022) y al menos un cliente/servidor miembro, en una red aislada de laboratorio (VMware Workstation, Hyper-V o VirtualBox). No lo ejecutes contra un dominio de producción sin autorización y ventana de cambio.

Parte A — Auditar tráfico NTLM saliente

# 1. En el equipo cliente de prueba: habilitar el canal de eventos NTLM
wevtutil set-log "Microsoft-Windows-NTLM/Operational" /enabled:true

# 2. Configurar la directiva local (o vía GPO de prueba) para auditar salida:
#    Computer Configuration > Windows Settings > Security Settings >
#    Local Policies > Security Options >
#    "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers"
#    = "Audit all"
# (o por registro, equivalente a la directiva anterior)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "RestrictSendingNTLMTraffic" -Value 1 -PropertyType DWord -Force

# 3. Generar tráfico NTLM de prueba: acceder por IP a un recurso compartido
#    (forzar NTLM evitando la resolución de nombres que usaría Kerberos)
net use \10.10.10.5c$ /user:LABtestuser

# 4. Revisar el evento 8001 generado
Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-NTLM/Operational"; Id=8001} |
    Format-List TimeCreated, Message

Parte B — Migrar una cuenta de servicio de RC4 a AES

# 1. Crear la cuenta de servicio de prueba con un SPN
New-ADUser -Name "svc-labtest" -SamAccountName "svc-labtest" `
    -AccountPassword (ConvertTo-SecureString "TempPassw0rd!2026Lab" -AsPlainText -Force) `
    -Enabled $true
setspn -A HTTP/labapp01.lab.local svc-labtest

# 2. Comprobar el tipo de cifrado antes del cambio (probablemente vacío/heredado, o RC4)
Get-ADUser svc-labtest -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

# 3. Forzar AES128 + AES256
Set-ADUser -Identity svc-labtest -KerberosEncryptionType AES128,AES256

# 4. Rotar la contraseña para que se calcule la clave AES (imprescindible)
Set-ADAccountPassword -Identity svc-labtest -Reset `
    -NewPassword (ConvertTo-SecureString "N3wStr0ngerPassw0rd!2026" -AsPlainText -Force)

# 5. Solicitar un ticket de servicio de prueba y verificar el etype negociado
klist get HTTP/labapp01.lab.local
klist
# En la salida, comprobar "KeyType" o "Etype": debe mostrar AES256-SHA1 (18) o AES128-SHA1 (17)

# 6. Confirmar también en el evento de seguridad 4769 (Kerberos Service Ticket Operations)
#    del controlador de dominio, campo "Ticket Encryption Type": 0x12 = AES256, 0x11 = AES128
Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4769} -MaxEvents 20 |
    Where-Object { $_.Message -match "svc-labtest" } |
    Select-Object TimeCreated, Message

Errores comunes

Quitar RC4 sin auditar primero. Deshabilitar RC4-HMAC a nivel de dominio (o forzar solo AES en la GPO de tipos de cifrado permitidos) sin haber verificado qué aplicaciones, confianzas o dispositivos aún dependen de él rompe autenticaciones en producción: impresoras de red antiguas, appliances de terceros, algunas confianzas entre bosques con dominios que no soportan AES, y aplicaciones que fijan el etype explícitamente en su configuración. El proceso correcto es auditar (evento 4769, campo Ticket Encryption Type) durante semanas, no días, antes de bloquear.
No rotar krbtgt tras un incidente confirmado. Si hay evidencia de exfiltración de NTDS.dit, compromiso de una cuenta de administrador de dominio o uso de DCSync no autorizado, no rotar krbtgt (dos veces) deja la puerta abierta a Golden Tickets fabricados con la clave comprometida, que seguirán siendo válidos indefinidamente hasta la rotación (o hasta que expire su vida útil, que un atacante puede fijar arbitrariamente alta al forjar el ticket).
Rotar krbtgt una sola vez en vez de dos. Una única rotación invalida los TGT legítimos en curso (fuerza reautenticación general) pero, si el objetivo es responder a un incidente, deja viva la clave «anterior» hasta la ventana de gracia expira: un Golden Ticket forjado con la clave comprometida sigue funcionando hasta la segunda rotación.
Pasar «Restrict NTLM» directamente a «Deny» sin fase de auditoría. Bloquear NTLM entrante o saliente sin haber recogido primero los eventos 8001-8004 corta aplicaciones legítimas (impresoras, backups, appliances de gestión, autenticación local a servicios web con IP directa) sin previo aviso, generando incidentes evitables.
Cambiar msDS-SupportedEncryptionTypes sin rotar la contraseña de la cuenta. El atributo por sí solo no genera la clave AES si esta nunca se ha calculado; el ticket seguirá emitiéndose con el mejor etype ya disponible (a menudo RC4) hasta que la contraseña cambie.
Confundir LmCompatibilityLevel con Restrict NTLM. Son controles complementarios, no intercambiables: el primero decide la variante de NTLM permitida (v1 vs v2); el segundo decide si NTLM se permite en absoluto y hacia/desde qué origen o destino.

Ejercicio

En tu laboratorio de Active Directory (no en producción):

Habilita el canal Microsoft-Windows-NTLM/Operational en el controlador de dominio y en al menos un servidor miembro.
Configura «Network security: Restrict NTLM: Audit Incoming NTLM Traffic» en modo auditoría (no bloqueo) en el servidor miembro.
Genera al menos tres eventos NTLM distintos: (a) un acceso SMB por IP directa, (b) una autenticación web con integrated auth apuntando por IP, (c) un runas /netonly con credenciales de un usuario del dominio.
Recupera y documenta los eventos 8002/8003 generados, identificando cliente, proceso y destino de cada uno.
Crea una cuenta de servicio con SPN, verifica su msDS-SupportedEncryptionTypes inicial, migra a AES128+AES256 con Set-ADUser -KerberosEncryptionType, rota su contraseña y confirma con klist y con el evento 4769 que el ticket de servicio se emite ahora con etype AES256 (0x12).
Documenta en un informe breve los pasos, la evidencia (capturas de los eventos) y qué excepciones necesitarías declarar antes de pasar de «Audit» a «Deny» en un entorno real similar al de tu laboratorio.

Preguntas frecuentes

¿Puedo desactivar RC4-HMAC en todo el dominio de un solo cambio de GPO?

Técnicamente sí, mediante «Network security: Configure encryption types allowed for Kerberos» marcando solo AES128/AES256, pero no es recomendable hacerlo de golpe. Primero hay que auditar durante semanas qué principals (equipos, confianzas, aplicaciones) siguen negociando RC4 revisando el evento 4769, migrar o documentar excepciones, y desplegar el cambio de forma progresiva empezando por un grupo piloto. Un cambio abrupto puede romper confianzas entre bosques con dominios que no soportan AES, dispositivos embebidos y aplicaciones legacy que fijan el etype en su configuración.

¿Rotar krbtgt afecta a los usuarios conectados en ese momento?

Una rotación por sí sola no cierra sesiones activas de inmediato, pero invalida los TGT emitidos con la clave anterior en cuanto esta se retira del historial (tras la segunda rotación, o de forma inmediata si solo hay caché de una clave). En la práctica, tras una doble rotación de emergencia hay que contar con que todos los usuarios necesitarán volver a autenticarse (bloqueo de pantalla y desbloqueo, o reinicio de sesión), por lo que conviene planificarlo como una ventana de mantenimiento, salvo en respuesta a incidente donde el coste de la interrupción es aceptable frente al riesgo.

¿AES256 tiene algún impacto de rendimiento notable frente a RC4?

En hardware moderno con soporte de instrucciones AES-NI (prácticamente todos los procesadores Intel/AMD desde hace más de una década), el coste de cómputo de AES256 es marginal comparado con RC4 y no supone un cuello de botella perceptible en la autenticación. El motivo histórico de mantener RC4 no es rendimiento, sino compatibilidad con sistemas y dispositivos antiguos que nunca implementaron soporte AES para Kerberos.

¿Qué diferencia hay entre auditar NTLM entrante y saliente, y cuál debo activar primero?

La auditoría de tráfico ENTRANTE («Restrict NTLM: Incoming NTLM traffic» / evento 8002-8003) se activa en el servidor que recibe la autenticación y muestra quién intenta autenticarse con NTLM contra ese servidor. La auditoría de tráfico SALIENTE («Outgoing NTLM traffic to remote servers» / evento 8001) se activa en el cliente y muestra hacia qué servidores ese equipo envía NTLM. Para construir un inventario completo conviene activar ambas, pero si solo puedes empezar por una, la entrante en los servidores críticos (controladores de dominio, servidores de archivos, servidores de aplicaciones) suele dar visibilidad más rápida sobre quién depende de NTLM para acceder a los recursos que más importa proteger.

¿Migrar una cuenta de servicio a gMSA elimina por completo el riesgo de kerberoasting sobre esa cuenta?

Sí, de forma práctica. Una gMSA gestiona una contraseña de 240 bytes generada aleatoriamente y rotada automáticamente por Active Directory (cada 30 días por defecto), que ningún humano conoce ni puede introducir manualmente. Un ticket de servicio obtenido para el SPN de una gMSA sigue pudiendo solicitarse igual que con cualquier cuenta (kerberoasting es una operación de solicitud legítima de TGS-REQ, no un fallo de permisos), pero el cracking offline de esa clave es computacionalmente inviable dada su longitud y aleatoriedad. La limitación es de compatibilidad: no todas las aplicaciones o versiones de servicio soportan gMSA como cuenta de ejecución.

¿Kerberos Armoring (FAST) sustituye a la restricción de NTLM?

No, son controles distintos con distinto alcance. Kerberos Armoring protege el intercambio AS-REQ/AS-REP inicial de Kerberos frente a ataques de fuerza bruta offline contra la preautenticación, cifrando ese intercambio con el TGT del equipo (requiere que todos los DC del dominio y los clientes lo soporten, funcionalmente disponible desde Windows Server 2012 en modo funcional de dominio adecuado). Restrict NTLM, en cambio, actúa sobre el protocolo NTLM, no sobre Kerberos. Ambos son complementarios dentro de una estrategia de endurecimiento de autenticación: uno refuerza Kerberos, el otro reduce la dependencia de NTLM.

«Network security: Restrict NTLM: Audit Incoming NTLM Traffic — This policy setting allows you to audit NTLM authentication requests that would be blocked if the ‘Network security: Restrict NTLM: Incoming NTLM traffic’ policy setting is set to Deny all accounts or Deny all domain accounts.»

— Microsoft Learn — Network security: Restrict NTLM: Audit Incoming NTLM Traffic

Módulo 5: Endurecer la autenticación — Kerberos y NTLM (de RC4 a AES)