Firma SMB deshabilitada: riesgo NTLM relay y mitigación

¿Qué es la firma SMB deshabilitada?

La firma SMB deshabilitada normalmente significa que los clientes Windows, los servidores, o ambos, no exigen tráfico SMB firmado. En los sistemas Windows modernos, el control exacto es el ajuste RequireSecuritySignature en el cliente SMB y en el servidor SMB.

La documentación de Microsoft sobre la firma SMB es explícita sobre lo que hace esta función. La firma SMB añade una firma a cada mensaje SMB utilizando la clave de sesión y el conjunto de cifrado. Si un atacante manipula el mensaje en tránsito, la firma deja de coincidir. Microsoft también indica que la firma SMB ayuda a proteger frente a ataques de relay y de suplantación.

Por eso el problema de seguridad no es simplemente "compartición de archivos sin firmar". Cuando la firma SMB no se exige en las rutas donde debería exigirse, el entorno queda más expuesto a la interceptación adversary-in-the-middle y a oportunidades de relay NTLM.

Para este artículo, el alcance es Windows SMB 2.x y 3.x en entornos de Active Directory, con énfasis en la exposición al relay, la verificación y el endurecimiento práctico. El objetivo no es afirmar que la firma SMB por sí sola resuelve todas las rutas de relay, sino señalar que deshabilitarla o no exigirla elimina una de las protecciones a nivel de protocolo que Microsoft construyó específicamente para detener la manipulación y el relay en el tráfico SMB.

Cómo funciona la firma SMB

Microsoft describe la firma SMB como una función de seguridad que utiliza la clave de sesión y el conjunto de cifrado para añadir una firma a un mensaje que circula por la conexión SMB. La firma contiene un hash del mensaje completo en la cabecera SMB. Si alguien modifica el mensaje en tránsito, la verificación de la firma falla.

Para SMB 2.x y 3.x, la firma se controla en función de si se exige o no, y no mediante la antigua lógica EnableSecuritySignature de la era SMB1. Microsoft indica que, a partir de SMB 2.02, EnableSecuritySignature se ignora y la firma se controla únicamente por si se exige o no.

Esa distinción importa porque muchos equipos creen que la firma SMB está habilitada si existe un ajuste heredado en algún lugar de la política, incluso cuando el requisito efectivo sigue estando desactivado.

Cuándo se utiliza realmente la firma SMB

Microsoft resume el comportamiento con claridad:

la firma se utiliza cuando el cliente SMB la exige
la firma se utiliza cuando el servidor SMB la exige
la firma no se utiliza únicamente cuando ni el cliente SMB ni el servidor SMB la exigen

Esto significa que el estado vulnerable es más amplio que un único servidor de archivos mal configurado. Si ninguno de los dos lados exige la firma, la sesión puede continuar sin firmar.

Por qué la firma SMB importa en entornos AD

SMB no es solo un protocolo de compartición de archivos. Los entornos de Active Directory dependen de él para flujos de trabajo habituales, como el acceso a SYSVOL y NETLOGON, los recursos compartidos administrativos y el acceso operativo a archivos entre endpoints y servidores.

Microsoft señala explícitamente que los controladores de dominio exigen la firma SMB de forma predeterminada en las conexiones que reciben, especialmente en SYSVOL y NETLOGON. Ese valor predeterminado existe por una razón: el tráfico SMB sin firmar en la infraestructura de identidad es mucho más fácil de manipular o de reenviar.

Firma SMB deshabilitada frente a firma SMB no requerida

En la práctica, los equipos suelen usar estas dos etiquetas indistintamente, pero el matiz técnico importa.

Deshabilitada normalmente significa que el administrador estableció explícitamente RequireSecuritySignature en False en el cliente, en el servidor, o en ambos.
No requerida significa que el endpoint todavía puede firmar si el otro lado lo exige, pero también aceptará una sesión sin firmar cuando ninguno de los dos lados la requiera.

Desde la perspectiva del riesgo, ambos estados pueden generar el mismo problema operativo: sesiones SMB a las que se permite continuar sin firmar.

Por eso muchas auditorías las agrupan en un único hallazgo. La pregunta real no es si una casilla dice "habilitado". La pregunta real es si el cliente o el servidor rechazarán el SMB sin firmar.

Por qué la firma SMB deshabilitada sigue siendo importante

Este control sigue siendo importante porque Microsoft continúa describiendo la firma SMB como una defensa frente a la manipulación de mensajes, la suplantación y el relay, y porque muchas rutas de relay todavía dependen de conseguir que un servidor acepte tráfico sin esta protección.

El SMB sin firmar ofrece a los adversarios una ruta de protocolo más débil

Si un cliente y un servidor pueden negociar una sesión sin firmar, un atacante presente en la red tiene más margen para interferir con el tráfico o para reenviar material de autenticación hacia otro host.

NTLM todavía existe en entornos reales

Incluso en organizaciones que avanzan hacia Kerberos y protocolos más robustos, Microsoft sigue documentando el bloqueo de NTLM sobre SMB como un paso de endurecimiento independiente para Windows 11 24H2 y Windows Server 2025. Esa es una señal clara de que la degradación de protocolo y la autenticación heredada siguen siendo operativamente relevantes.

Los dispositivos de terceros y el acceso de tipo invitado suelen debilitar la ruta

La guía de Microsoft sobre la firma SMB es directa aquí: si un servidor SMB de terceros no admite la firma, algunos equipos deshabilitan la firma en Windows solo para restaurar la compatibilidad. Microsoft advierte explícitamente contra usar eso como solución temporal, porque implica confiar en un acceso de tipo invitado o sin firmar a un recurso remoto.

Condiciones previas para una exposición real por firma SMB

Un hallazgo SMB_SIGNING_DISABLED adquiere una importancia material cuando se superponen las siguientes condiciones.

1. Ninguno de los dos lados exige la firma en una ruta relevante

La exposición central es que tanto el cliente SMB como el servidor SMB pueden continuar sin exigir firmas.

2. NTLM sigue estando disponible en la ruta

La guía de Microsoft sobre SMB recomienda repetidamente Kerberos por encima de NTLMv2 y desaconseja el uso de direcciones IP o registros CNAME, porque esos patrones alejan la autenticación de Kerberos y la acercan a NTLM. Esto importa porque el SMB sin firmar combinado con rutas orientadas a NTLM es una combinación clásica que facilita el relay.

3. El atacante puede situarse en la ruta o influir sobre ella

Los ataques de relay e interceptación no son magia remota. El atacante debe poder coaccionar o posicionar el tráfico a través de un sistema que controle, o de algún otro modo abusar de una ruta en la que pueda reenviar credenciales.

4. Los recursos compartidos administrativos o de alto valor son alcanzables

Un relay contra un recurso compartido inofensivo es un problema. Un relay contra un servidor de administración, un recurso compartido administrativo o un servicio de archivos sensible es otro distinto. Si esos sistemas también son alcanzables por una higiene operativa deficiente, el radio de impacto crece. Por eso conviene revisar Cuentas privilegiadas obsoletas: un riesgo oculto en Active Directory junto con los ajustes de red relacionados con el relay.

5. El entorno todavía contiene clientes heredados, dispositivos o flujos de trabajo de invitado

La presión operativa para dar soporte a dispositivos NAS antiguos, appliances, escáneres o patrones de acceso de tipo invitado es una de las principales razones por las que la firma acaba sin exigirse.

La cadena de ataque

Una ruta de ataque práctica que involucra la firma SMB deshabilitada suele tener este aspecto.

Paso 1: encontrar una ruta SMB sin firmar

El atacante identifica un par de servidor y cliente donde ninguno de los dos exige la firma SMB.

Paso 2: coaccionar o interceptar la autenticación

El atacante hace que un sistema o usuario objetivo se autentique por SMB en una ruta que puede observar o influir.

Paso 3: reenviar el intento de autenticación

Si las condiciones más amplias lo permiten, el atacante reenvía el intento de autenticación hacia otro servicio SMB u otro endpoint de protocolo que acepte la identidad reenviada.

Paso 4: usar de inmediato el acceso resultante

El relay es útil porque el atacante no necesita crackear la contraseña primero. Si el relay tiene éxito, puede actuar con el acceso de la víctima en tiempo real.

Por eso este hallazgo va de la mano con Ataques de relay NTLM: secuestro de autenticación en AD. La firma SMB deshabilitada no es toda la historia del relay, pero es una de las formas más claras de facilitar el relay SMB más de lo debido.

Detección

La detección de este problema tiene dos partes: detección de configuración y detección operativa.

Detección de configuración

El método de validación más directo es comprobar si el cliente o el servidor SMB realmente exigen la firma.

Microsoft documenta las comprobaciones exactas en PowerShell:

Get-SmbClientConfiguration | FL RequireSecuritySignature
Get-SmbServerConfiguration | FL RequireSecuritySignature

Si el valor es False, la firma no se exige en ese lado.

Desde la Directiva de grupo, Microsoft ubica los ajustes relevantes en:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)

Esta es la forma más rápida de convertir una afirmación vaga de auditoría en un sí o un no concreto.

Auditar la compatibilidad antes de aplicar la exigencia

Una mejora práctica en las versiones recientes de Windows es la auditoría de firma y cifrado SMB. Microsoft documenta los siguientes controles de auditoría:

Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Los eventos relacionados se registran en:

Microsoft-Windows-SMBClient/Audit, con los IDs de evento 31998 y 31999
Microsoft-Windows-SMBServer/Audit, con los IDs de evento 3021 y 3022

Esos eventos son especialmente útiles cuando se quiere hacer obligatoria la firma pero antes es necesario descubrir qué sistemas de terceros dejarán de funcionar.

Detección operativa

Si sospecha de un abuso real y no solo de una configuración débil, correlacione:

los hosts donde la firma no se exige
patrones de tráfico SMB con uso intensivo de NTLM
la actividad tipo relay descubierta en Supervisión de Active Directory: Event IDs de seguridad que importan
el acceso inesperado a recursos compartidos administrativos o servicios de archivos sensibles
los sistemas con acceso SMB basado en IP o con patrones de nomenclatura ajenos a Kerberos

No existe un único evento de Windows que indique "el relay NTLM tuvo éxito porque la firma SMB estaba deshabilitada". El mejor enfoque es identificar primero la ruta sin firmar y luego correlacionar la actividad de autenticación y de acceso que la rodea.

Remediación

La remediación principal es sencilla: exigir la firma SMB donde se supone que debe exigirse, y luego reducir los comportamientos de protocolo adyacentes que mantienen viable el relay.

1. Exigir la firma SMB en ambos lados siempre que sea posible

Microsoft documenta los comandos de PowerShell exactos:

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

A nivel de directiva, los ajustes relevantes son:

Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)

Si controla tanto los clientes Windows como los servidores de archivos Windows, esta es la referencia base más limpia.

2. No trate la incompatibilidad de terceros como motivo para normalizar un SMB débil

Microsoft advierte explícitamente contra deshabilitar la firma SMB como solución temporal para servidores de terceros, y contra intentar usar la firma con cuentas de invitado. Si un appliance de terceros no admite correctamente la firma, documéntelo como deuda técnica o aíslelo. No rebaje silenciosamente la línea base de Windows para todo lo demás.

3. Priorice Kerberos y evite los patrones que le empujan hacia NTLM

Microsoft recomienda:

usar Kerberos en lugar de NTLMv2
no conectarse a los recursos compartidos por dirección IP
no usar registros CNAME para el acceso SMB cuando fuercen el comportamiento NTLM

Estos no son detalles cosméticos: reducen directamente la probabilidad de que una ruta sin firmar o débilmente protegida se convierta en una ruta práctica de relay NTLM. La higiene de contraseñas y de protocolo siguen importando en la misma superficie de ataque; por eso Seguridad de contraseñas en Active Directory: configuraciones incorrectas que importan forma parte de la misma revisión.

4. Utilice las funciones de endurecimiento SMB más recientes cuando su plataforma las admita

Microsoft ahora incluye valores predeterminados más estrictos y protecciones adyacentes en las versiones actuales:

Windows 11 24H2 Enterprise, Pro y Education exigen la firma SMB tanto entrante como saliente
Windows Server 2025 exige la firma SMB saliente de forma predeterminada
Windows 11 24H2 y Windows Server 2025 añaden controles de auditoría de la firma SMB
Windows 11 24H2 y Windows Server 2025 añaden el bloqueo de NTLM sobre SMB en el lado del cliente

Esto significa que la remediación no consiste solo en activar una política antigua. En las plataformas más recientes, puede usar la auditoría y la reducción de NTLM para hacer el entorno más seguro sin tener que adivinar qué dependencia va a fallar.

5. Revise por separado el acceso de invitado y las dependencias de NAS heredados

Microsoft indica que exigir la firma SMB también deshabilita el acceso de invitado a los recursos compartidos. Si su negocio todavía depende del acceso SMB de tipo invitado, se trata de una excepción de diseño que debe aislarse y revisarse, no incorporarse silenciosamente al resto del entorno.

6. Revise la proliferación de administradores locales en los mismos sistemas

El SMB sin firmar en estaciones de trabajo y servidores miembro es más peligroso cuando esos mismos hosts también comparten problemas de credenciales de administrador local. Si está endureciendo el entorno, revise Windows LAPS no implementado: por qué importan las contraseñas de administrador local compartidas en esos mismos sistemas.

7. Combine la firma con revisiones centradas en el relay

Si la firma SMB está deshabilitada, revise también los hallazgos adyacentes que facilitan el relay:

Si está decidiendo cómo operacionalizar esas comprobaciones en todo el entorno, Herramientas de auditoría de seguridad de AD: qué comparar antes de elegir también es relevante.

El control es más sólido cuando se trata como parte de un programa de reducción del relay, y no como un valor de registro aislado.

Validación tras el endurecimiento

Después de cambiar la política, valide el resultado directamente.

ejecute Get-SmbClientConfiguration y Get-SmbServerConfiguration para confirmar que RequireSecuritySignature es True
confirme que los ajustes efectivos de la Directiva de grupo coinciden con la línea base prevista
habilite primero los eventos de auditoría de firma si prevé problemas de compatibilidad con terceros
identifique los dispositivos o el software que no admiten la firma antes de exigirla de forma generalizada
compruebe si aún existen flujos de trabajo antiguos de invitado o sin firmar, y si deben retirarse en lugar de conservarse
revise si el acceso a recursos compartidos por IP, el uso de CNAME o las rutas SMB con uso intensivo de NTLM siguen presentes
incluya el control en la revisión más amplia descrita en Cómo auditar la seguridad de Active Directory: checklist práctica para equipos internos

La condición real de éxito no es una captura de pantalla de la política. Es que clientes y servidores ya no acepten SMB sin firmar donde la exposición al relay importa.

Cómo detecta EtcSec esta exposición relacionada

EtcSec puede modelar este problema directamente porque SMB_SIGNING_DISABLED es un hallazgo concreto de endurecimiento de red, no solo una recomendación genérica de buenas prácticas.

En la práctica, los enlaces del catálogo relacionado más útiles son:

hallazgos directos de SMB_SIGNING_DISABLED en sistemas que todavía permiten SMB sin firmar
hallazgos de NTLM_RELAY_OPPORTUNITY en los que los prerrequisitos del relay siguen presentes
las comprobaciones de supervisión y endurecimiento de AD circundantes, que indican si el problema está aislado o forma parte de un entorno más propicio al relay

Por eso este tema va de la mano con Ataques de relay NTLM: secuestro de autenticación en AD y Cómo auditar la seguridad de Active Directory: checklist práctica para equipos internos, y no solo con una guía genérica de servidores de archivos.

Controles relacionados

Si está revisando la firma SMB deshabilitada, revise también Ataques de relay NTLM: secuestro de autenticación en AD, Supervisión de Active Directory: Event IDs de seguridad que importan, Cómo auditar la seguridad de Active Directory: checklist práctica para equipos internos, Seguridad de contraseñas en Active Directory: configuraciones incorrectas que importan, Windows LAPS no implementado: por qué importan las contraseñas de administrador local compartidas, Cuentas privilegiadas obsoletas: un riesgo oculto en Active Directory y Herramientas de auditoría de seguridad de AD: qué comparar antes de elegir. Esos artículos cubren las rutas de coacción, relay y supervisión circundantes que determinan si el SMB sin firmar es simplemente un ajuste débil o una ruta de ataque práctica.

Firma SMB deshabilitada: por qué aún permite NTLM relay