A partir de la actualización de octubre de 2026, Windows 11 24H2 y Windows Server 2025 bloquearán las credenciales derivadas de NTLMv1 sin que ningún administrador cambie nada, según el KB5066470. Es el primer plazo con fecha dentro de la retirada de NTLM. El plan completo lo anunció Microsoft el 29 de enero de 2026 y acaba con la autenticación NTLM por red bloqueada en la próxima versión principal de Windows Server y de su cliente, salvo que alguien la reactive a propósito. En el segundo semestre de 2026 llegan, entre medias, IAKerb y el KDC local, pensados para que Kerberos funcione donde Windows todavía recurre a NTLM.
NTLM forma parte de Windows desde 1993 y Kerberos lo relevó como protocolo por defecto en los dominios hace más de veinte años. Con todo, en casi todos los directorios que auditamos en Hard2bit lo encontramos activo: en el servidor de ficheros al que alguien conecta por dirección IP, en la impresora que se autentica en el dominio o en la aplicación de contabilidad cuyo proveedor cerró hace años. Retirarlo sin dejar a nadie sin acceso lleva meses, y las herramientas para empezar ya vienen con Windows.
¿Por qué sigue habiendo NTLM en una red que ya usa Kerberos?
Kerberos exige lo que NTLM nunca pide: un nombre de servicio registrado en el directorio (el SPN), un controlador de dominio alcanzable en ese momento y un cliente que sepa pedir el tíquet. Si falta cualquiera de esas condiciones, Windows degrada la negociación y usa NTLM sin que el usuario lo perciba. Desplegar Kerberos no elimina NTLM; lo deja en los huecos.
Microsoft ha catalogado esos huecos en la auditoría mejorada de NTLM de Windows 11 24H2 y Windows Server 2025, que anota en cada intento el motivo por el que se usó NTLM. Esa lista de motivos es el inventario de causas que hay que corregir:
- El destino se indicó por dirección IP en lugar de por nombre, con lo que no hay SPN que buscar (motivo 7). En lo que vemos, lo provocan sobre todo scripts, accesos directos a recursos compartidos y trabajos de copia de seguridad.
- El nombre de destino está vacío, no se resuelve o está duplicado en el directorio (motivos 5, 6 y 8). Dos servicios con el mismo SPN hacen que Kerberos falle y que el cliente caiga a NTLM.
- Se autentica una cuenta local, no de dominio (motivo 2). Es el caso de las cuentas locales de administración y de los servidores en grupo de trabajo, que no tienen KDC al que pedir tíquets.
- El equipo no alcanza ningún controlador de dominio (motivo 9): usuarios en una VPN antes de iniciar sesión, servidores en una DMZ, equipos que acceden a un recurso interno desde fuera o sucursales con el enlace caído.
- La aplicación llama a NTLM directamente (motivo 1). Lo hace software antiguo, y alguno no tanto, que lleva el proveedor de seguridad NTLM fijado en el código en lugar de usar Negotiate.
- Se usa autenticación por bucle local (motivo 10), habitual en servicios que se llaman a sí mismos, o una sesión nula (motivo 11).
Hay un segundo grupo que no aparece en esa lista porque no es Windows quien lo genera: los dispositivos que solo hablan NTLM, como NAS, impresoras multifunción, escáneres que dejan documentos en carpetas compartidas, sistemas de gestión de edificios y equipos industriales con integración SMB. Explicamos en su día por qué el EDR no ve lo que pasa en esos dispositivos; con NTLM ocurre lo mismo, y además son los más difíciles de sustituir.
Qué ha anunciado Microsoft y qué fechas importan
Microsoft declaró NTLM obsoleto (deprecated) en junio de 2024, como recogió entonces BleepingComputer. Desde entonces ha ido publicando el plan por piezas, y hay que distinguirlas porque no todas afectan a los mismos sistemas.
NTLMv1 ya no existe en las versiones actuales, pero quedan restos
Windows 11 24H2 y Windows Server 2025 eliminaron el protocolo NTLMv1. Lo que queda son credenciales derivadas de su criptografía, que usan protocolos de nivel superior como MS-CHAPv2 en redes inalámbricas y cableadas y en conexiones VPN con inicio de sesión único. El KB5066470 introduce el valor de registro BlockNtlmv1SSO con dos modos: auditoría, que genera el evento 4024 cada vez que se usan, y bloqueo, que las impide y registra el 4025.
Desde octubre de 2026 el valor por defecto pasará a bloqueo en los equipos donde nadie lo haya desplegado. Con Credential Guard activo el cambio es irrelevante, porque Credential Guard ya impide ese uso, y Microsoft lo recomienda como la protección más completa.
La auditoría mejorada dice quién, por qué y dónde
El KB5064479 describe los nuevos eventos del registro Microsoft-Windows-NTLM/Operational. Los clientes anotan cada autenticación NTLM saliente con el proceso que la pidió, el destino y el motivo (eventos 4020 y 4021); los servidores, cada autenticación entrante y si tuvo éxito (4022 y 4023); y los controladores de dominio, todo el tráfico NTLM del dominio, incluido el que cruza entre dominios (4030 a 4033).
Cada pareja tiene una versión informativa y otra de aviso, y el aviso significa degradación: NTLMv1, protección extendida de autenticación no admitida o comprobación de integridad ausente. Las directivas vienen activadas: «NTLM Enhanced Logging» en cliente y servidor, y «Log Enhanced Domain-wide NTLM Logs» en los controladores.
Segundo semestre de 2026: IAKerb y KDC local
IAKerb y el KDC local son las capacidades que Microsoft describió en su plan de evolución de la autenticación y que sitúa en la fase dos de la retirada. IAKerb permite que un cliente sin conectividad directa con el controlador de dominio se autentique con Kerberos a través de un servidor que sí la tiene, apoyándose en las garantías criptográficas de Kerberos para proteger los mensajes en tránsito. El KDC local añade Kerberos a las cuentas locales, con AES desde el primer momento. Entre las dos cubren los motivos 2 y 9 de la lista anterior, que de momento solo se pueden rodear.
Fase tres: bloqueado por defecto
En la siguiente versión principal de Windows Server y de su cliente, NTLM seguirá dentro del sistema, pero la autenticación NTLM por red estará bloqueada y habrá que reactivarla de forma explícita mediante nuevas directivas. Microsoft no ha dado fecha para esa versión. Lo que sí ha dicho es que la fase uno, la de auditar, empieza ya, con herramientas que Windows ya trae.
La objeción: «si quitamos NTLM se rompe media red»
Es la frase que oímos en casi todos los proyectos, y tiene parte de razón. Bloquear NTLM a ciegas deja fuera exactamente a los sistemas de la lista de motivos de la sección anterior. Hay una segunda objeción más elaborada: «ya usamos NTLMv2, tenemos la firma SMB activada y las contraseñas son largas; el riesgo residual no justifica el proyecto».
La primera objeción no va contra el destino sino contra el método, y el método es el resto de este artículo. La segunda merece una respuesta técnica, porque parte de una idea equivocada sobre dónde está el riesgo.
Qué permite NTLM a un atacante mientras siga activo
NTLMv2 mejoró la criptografía de NTLMv1, pero conservó el diseño: un desafío del servidor, una respuesta del cliente calculada a partir del hash de la contraseña y ninguna vinculación fuerte entre esa respuesta y el servidor al que iba dirigida. De ahí salen las familias de abuso que siguen apareciendo en incidentes.
Retransmisión: la víctima se autentica ante el atacante y este reenvía la autenticación
El MSRC lo describe así: se fuerza a una víctima a autenticarse en un punto arbitrario y se retransmite esa autenticación a un servicio vulnerable. El forzado llega por una ruta UNC en un correo o un documento, por una llamada RPC a un servidor que responde con su cuenta de máquina o por un nombre envenenado en la red local. El destino preferido es un servicio que acepte NTLM sin exigir firma ni vinculación de canal: LDAP, la autoridad de certificación de AD CS o un servidor Exchange. Microsoft cita como precedentes CVE-2023-23397 (Outlook contra Exchange), CVE-2021-36942 (LSARPC contra AD CS) y ADV190023 (WPAD contra LDAP).
En su guía de amenazas críticas a Active Directory de diciembre de 2025, Microsoft coloca la retransmisión de autenticación como la segunda de seis amenazas, justo después de las vulnerabilidades sin parchear, y la describe como el paso que convierte un primer acceso en movimiento lateral y, en el peor caso, en control total del dominio.
Captura y descifrado por fuerza bruta fuera de línea
Cualquier respuesta NTLMv2 que un atacante consiga capturar puede atacarse por fuerza bruta sin volver a tocar el dominio. Con NTLMv1 el cálculo es trivial; con NTLMv2 depende de la contraseña, y las contraseñas de cuentas de servicio y de dispositivos suelen ser las más antiguas de la organización. Es el mismo problema que el Kerberoasting que analizamos en los ataques al Active Directory híbrido: la contraseña sale de la red en una forma que se puede atacar sin prisa.
Pass-the-hash
Con NTLM, el hash de la contraseña es la credencial. Quien lo extrae de un equipo comprometido puede autenticarse como ese usuario en cualquier sistema que acepte NTLM, sin conocer la contraseña. Credential Guard dificulta extraer el hash de la memoria y Kerberos con AES impide reutilizarlo como clave; NTLM mantiene la vía abierta mientras exista un servicio que lo acepte. Cómo se extraen y reutilizan esas credenciales comprometidas lo tratamos en el glosario; aquí importa que es el protocolo el que lo permite.
La respuesta a la segunda objeción, por tanto, es que la firma SMB reduce la retransmisión en el servicio donde se aplica y NTLMv2 encarece el descifrado, pero ninguna de las dos toca el resto. El riesgo vive en el servicio que quedó sin firma, en el dispositivo que solo habla NTLMv1 y en el hash que sale de un portátil comprometido, y ninguno de los tres se arregla con una contraseña más larga.
Cómo auditar NTLM: qué eventos mirar y qué preguntas responder
La auditoría tiene que terminar con tres respuestas: qué cuentas usan NTLM, contra qué servidores y por qué motivo. Contar eventos sin llegar a esas respuestas solo produce gráficos.
Las directivas clásicas y el evento 8004
Desde Windows Server 2008 R2 existen tres directivas bajo Opciones de seguridad que registran sin bloquear: «Auditar el tráfico NTLM entrante», «Auditar la autenticación NTLM en este dominio» y «Tráfico NTLM saliente hacia servidores remotos» en modo auditoría. Escriben en el mismo registro operativo de NTLM y, en los controladores de dominio, generan el evento 8004, el que Microsoft Defender for Identity consume para enriquecer sus alertas. La documentación de la directiva de dominio advierte de que el registro puede crecer deprisa; hay que dimensionarlo antes de elegir «Habilitar todo».
La auditoría mejorada: filtrar por motivo
En los equipos que ya generan la auditoría mejorada, la información útil está en los eventos 4020 a 4023 y 4030 a 4033. Una consulta que agrupe los 4020 y 4021 por el campo de motivo y por proceso responde con bastante precisión qué parte del NTLM de la red se debe a direcciones IP, qué parte a cuentas locales y qué parte a aplicaciones identificables.
Los 4022 y 4023 en cada servidor dicen quién sigue llegando por NTLM a ese sistema, y los 4032 y 4033 del controlador cubren el dominio completo. Los eventos de aviso, los impares, van primero en la cola de correcciones.
Centralizar o perder la señal
Estos registros no llegan solos al SIEM: el canal Microsoft-Windows-NTLM/Operational no forma parte del registro de seguridad y hay que recogerlo de forma explícita. El criterio de qué fuentes enviar al SIEM y con qué retención lo desarrollamos en otro artículo; este canal entra en la categoría de alta prioridad durante el proyecto y puede bajar de nivel cuando termine. Sin centralización, la auditoría se convierte en una colección de visores de eventos abiertos uno por uno.
Cómo retirar NTLM por fases sin dejar a nadie fuera
El orden importa más que la velocidad. Antes de bloquear el protocolo hay que quitarle al atacante la retransmisión, que es lo que hace daño ahora mismo y no depende de que NTLM desaparezca.
Primero, cerrar la retransmisión aunque NTLM siga
- Firma SMB obligatoria en servidores y clientes. Windows 11 24H2 y Windows Server 2025 ya la exigen por defecto; en las versiones anteriores hay que activarla por directiva.
- Firma LDAP y vinculación de canal en los controladores de dominio. Windows Server 2025 activa la vinculación por defecto en modo «cuando sea compatible», según el MSRC; el objetivo es «siempre» en cuanto no queden clientes antiguos.
- Protección extendida de autenticación en AD CS, Exchange e IIS. En Exchange 2019 CU14 y en el AD CS de Windows Server 2025 viene activada; en versiones anteriores, y en IIS en todos los casos, hay que activarla manualmente.
- Desactivar LLMNR, NBT-NS y la detección automática de proxy WPAD, y bloquear SMB saliente hacia Internet en el perímetro. Sin nombres que envenenar ni rutas UNC hacia fuera, forzar la autenticación pierde sus vías más fáciles.
Segundo, corregir las causas según el motivo
Cada motivo de la auditoría mejorada tiene una acción asociada. Las conexiones por IP se corrigen sustituyendo la dirección por un nombre DNS con SPN registrado, y los SPN duplicados se resuelven revisando el directorio. Las cuentas locales de administración pasan a gestionarse con LAPS y a usarse solo en consola, a la espera del KDC local.
Los usuarios que no alcanzan ningún controlador necesitan una VPN que se establezca antes del inicio de sesión, o tienen que esperar a IAKerb. Para las aplicaciones que llaman a NTLM directamente hay que hablar con el fabricante y, si no hay parche, aislarlas. Los dispositivos que solo hablan NTLM se sustituyen o se confinan en un segmento aparte con una cuenta dedicada que no pueda usarse en ningún otro sitio.
Tercero, bloquear por ámbitos y con excepciones
Las mismas directivas que auditan tienen su versión de bloqueo, y dos de ellas admiten listas de excepciones por nombre: la de tráfico saliente hacia servidores remotos y la de autenticación en el dominio. La de tráfico entrante en un servidor no las admite; ese servidor deniega NTLM a todo el mundo o a nadie. El orden que menos riesgo introduce empieza por las cuentas privilegiadas: meterlas en el grupo Protected Users les impide autenticarse con NTLM (y les aplica otras restricciones) y es el cambio con mejor relación entre riesgo eliminado y molestia causada.
Después se deniega NTLM entrante en los controladores de dominio y luego en los servidores de aplicaciones, uno a uno. Las excepciones que la auditoría justifique se cargan en la directiva de dominio o en la de salida de los clientes. El último paso es denegarlo en el dominio para las cuentas de dominio. Cada paso sale con la directiva de reversión preparada y con el SOC avisado de que los errores de autenticación de esa semana pueden ser el proyecto y no un ataque.
Con lo que no se puede arreglar, una excepción documentada, con fecha de caducidad y con el sistema aislado, es aceptable; una excepción sin responsable se convierte en el NTLM permanente de la red. Y el bastionado de un servidor no equivale al del dominio: las autenticaciones que se fuercen desde ese servidor o desde sus usuarios siguen pudiendo retransmitirse a cualquier otro servicio del dominio que acepte NTLM.
Qué debe estar hecho en octubre y qué puede esperar a la próxima versión de Windows
Antes de octubre de 2026 hay que revisar los eventos 4024 en todos los equipos que ya los generan, porque son la mejor aproximación a lo que dejará de funcionar cuando BlockNtlmv1SSO pase a bloqueo. Suelen ser redes Wi-Fi y VPN con MS-CHAPv2 e inicio de sesión único. La solución es EAP-TLS con certificados; si no llega a tiempo, al menos hay que avisar de que, a partir de esa actualización, los usuarios tendrán que escribir la contraseña.
Para la versión de Windows que traiga NTLM bloqueado por defecto no hay fecha, y eso es una ventaja: el trabajo de auditoría y de corrección de causas se puede hacer sin presión de calendario. Lo que no tiene sentido es esperar a la fecha para empezar, porque las tres respuestas de la auditoría tardan semanas en estabilizarse y las correcciones que dependen de fabricantes, meses.
A la dirección técnica le corresponde nombrar un responsable del proyecto, fijar un criterio de excepción y aceptar que durante unas semanas el registro de NTLM será una de las fuentes más consultadas de la organización. En Hard2bit este trabajo forma parte de las auditorías de infraestructura y red, porque el inventario de NTLM y el de servicios sin firma ni protección extendida son el mismo documento.
Retirar la autenticación NTLM por red no hace inmune al dominio, pero sí le quita al atacante una de las técnicas con las que más veces hemos visto pasar de un portátil comprometido a un dominio comprometido. Y la excepción sin responsable que quede al final del proyecto será, con el tiempo, el único NTLM que le haga falta.
Este artículo tiene carácter divulgativo. Las directivas, valores de registro y eventos descritos proceden de la documentación pública de Microsoft vigente a 4 de septiembre de 2026; las fechas del calendario de retirada de NTLM son las que Microsoft ha publicado y la propia compañía las califica de provisionales. Cualquier cambio en directivas de autenticación debe probarse en un ámbito reducido, con una vía de reversión y con el equipo de operaciones informado, antes de aplicarse al dominio.
