Firma LDAP y Channel Binding: el hallazgo de Directorio Activo que más explotamos en pruebas internas

Uno de los hallazgos más frecuentes en nuestras Evaluaciones de Seguridad del Directorio Activo —y uno de los que explotamos con mayor éxito durante las pruebas de penetración de red interna— no es una vulnerabilidad que haya que descubrir ni un parche que falte aplicar. Es un par de políticas que vienen desactivadas de fábrica en Windows Server y que casi nadie revisa: la firma LDAP y el channel binding en los Controladores de Dominio.

Su ausencia no dispara alertas. No aparece como crítica en un escaneo de vulnerabilidades. Y, sin embargo, es la condición que permite que una cuenta sin privilegios termine modificando objetos del directorio.

Firma LDAP y channel binding: dos controles, dos canales distintos

LDAP Signing (firma). Obliga a que los binds SASL —Negotiate, Kerberos, NTLM, Digest— soliciten firma de integridad, y rechaza los binds simples realizados sobre conexiones no cifradas. Sin la firma exigida, una sesión LDAP sobre el puerto 389 carece de verificación de integridad y puede ser retransmitida por un tercero.

LDAP Channel Binding Token (CBT). Vincula la autenticación que viaja dentro de una sesión TLS —LDAPS en el puerto 636, o LDAP con STARTTLS— al canal TLS específico donde ocurre. Sin CBT, una autenticación capturada en un canal TLS puede reutilizarse en otro distinto, que es exactamente lo que habilita la retransmisión hacia LDAPS.

El punto que más se malinterpreta es que no son intercambiables. Protegen canales diferentes: la firma cierra la retransmisión sobre LDAP en texto claro; el channel binding la cierra sobre LDAPS. Para que la retransmisión hacia LDAP sea inviable, ambos deben estar exigidos. Corregir uno y declarar el hallazgo cerrado deja el canal restante tan explotable como estaba.

La mala configuración no es, por sí sola, explotable

Conviene separar la condición de configuración del vector que la hace práctica, porque es exactamente donde se cae en el alarmismo fácil.

Por sí sola, la autenticación originada en SMB no se retransmite a LDAP: el cliente SMB fija indicadores de firma durante la negociación que el servidor LDAP honra, y la sesión se aborta. El atacante supera esa barrera de dos maneras:

• Manipulando el Message Integrity Code de NTLM (CVE-2019-1040, conocido como «Drop the MIC») en hosts que no tengan aplicado el parche correspondiente.
• Coaccionando autenticación sobre HTTP en entornos ya parcheados, típicamente mediante el servicio WebClient que implementa WebDAV, protocolo que no fija esos indicadores.

En ambos casos, la ausencia de firma y channel binding en el Controlador de Dominio es la condición necesaria para que la autenticación retransmitida sea aceptada como legítima. Esa precisión importa: es la diferencia entre reportar un riesgo real y vender miedo.

Qué obtiene el atacante

El impacto se escalona según el canal comprometido.

Sobre LDAP en texto claro, una sesión retransmitida permite modificar atributos de objetos ya existentes: configurar delegación restringida basada en recursos (RBCD) sobre equipos del dominio, o conceder derechos de replicación de directorio que habilitan la extracción masiva de credenciales mediante DCSync.

Sobre LDAPS, se suma la creación de cuentas de máquina nuevas, operación que requiere canal cifrado. Con el valor de fábrica del atributo ms-DS-MachineAccountQuota —diez equipos por usuario autenticado— eso está al alcance de cualquier cuenta del dominio.

Para el negocio, el perfil del ataque pesa tanto como su alcance: no requiere ejecución de código en el equipo de la víctima y deja escasa evidencia en sus registros locales. Es un camino de baja telemetría hacia el compromiso del dominio. En entornos regulados, además, toca controles de integridad y autenticidad de sesión exigidos por marcos como NIST SP 800-53 Rev. 5 (SC-8, SC-23); la técnica está catalogada en MITRE ATT&CK como T1557.001.

Una nota sobre severidad, porque es donde muchos informes exageran: el alcance real depende de controles concurrentes —la exigencia de firma SMB, el estado de parcheo frente a CVE-2019-1040, la presencia de servicios WebDAV alcanzables y el valor efectivo de ms-DS-MachineAccountQuota—. La severidad de cada instancia debe calcularse sobre lo efectivamente demostrado durante la prueba, no sobre el peor escenario teórico.

Por qué la remediación falla más de lo que debería

Microsoft advierte de forma expresa que configurar el servidor para exigir firma sin haber configurado antes los clientes produce pérdida de conexión. Ese error es el que convierte un proyecto de endurecimiento en una reversión completa, y el hallazgo vuelve a aparecer en la evaluación del año siguiente.

Una remediación que funciona respeta tres reglas.

Auditar antes de exigir. El Controlador de Dominio ya está avisando que el control no está activo: el Event ID 2886 se emite cada 24 horas mientras la política de firma permanezca en «None», y el 2887 cuantifica los binds inseguros completados. Pero ninguno de los dos identifica clientes. Para saber quién los realiza hay que elevar el nivel de registro de diagnóstico de la interfaz LDAP y recoger los Event ID 2889, que sí incluyen dirección IP e identidad del cliente.

Asumir que las dos auditorías no son simétricas. La de firma necesita un solo prerrequisito. La de channel binding necesita tres: Controladores de Dominio actualizados (la actualización del 14 de noviembre de 2023 en Windows Server 2022, o la del 9 de enero de 2024 en Windows Server 2019), el registro de diagnóstico elevado, y la política colocada en modo «When Supported». Con la política en «Never» no hay auditoría posible, por mucho que el resto esté configurado. Omitir cualquiera de los tres lleva a la conclusión errónea de que no existen clientes incompatibles.

Dar tiempo a la ventana de observación. Un ciclo operativo completo. Procesos mensuales, tareas programadas, trabajos de respaldo y sistemas de conciliación realizan binds que no se manifiestan en unos pocos días de monitoreo.

Quiénes suelen ser los clientes incompatibles

En nuestra experiencia en la región, el inventario rara vez son servidores. Son dispositivos:

• Firewalls y plataformas UTM, balanceadores de carga, concentradores VPN y portales cautivos.
• Impresoras y multifuncionales con libreta de direcciones corporativa.
• Almacenamiento en red, controladoras de red inalámbrica y telefonía IP.
• Sistemas de videovigilancia y control de acceso físico.

Todos integran un cliente LDAP dentro de su firmware que el administrador no puede modificar. La corrección no se ejecuta en el dispositivo, sino sobre su versión o su configuración: actualizar firmware a una versión que soporte firma o LDAPS, ajustar la integración con el directorio desde la consola del fabricante, o escalar el requerimiento al proveedor. Ese último caso es el que define el cronograma real del proyecto, y conviene levantarlo en la primera semana, no en la última.

Dos matices que ahorran bastante trabajo:

• Una dirección IP en el Event ID 2889 no identifica necesariamente al responsable final. Servidores de aplicación, agentes de respaldo y servidores intermedios realizan binds en representación de otros sistemas. Confirme el proceso responsable o el caso reaparecerá al aplicar la exigencia.
• Un bind simple sigue siendo válido si viaja sobre LDAPS. Para una aplicación heredada, la vía de corrección no es necesariamente reescribir su método de autenticación: con frecuencia basta con migrarla a canal cifrado.

Verificación: la parte que casi nadie completa

Aplicar las políticas no cierra el hallazgo. Verificarlas, sí.

• Prueba puntual. Con ldp.exe, un Simple Bind al puerto 389 contra el Controlador de Dominio debe devolver Strong Authentication Required.
• Validación en producción. El Event ID 2888 reporta binds no protegidos rechazados tras exigir la firma; el 3039, fallos de validación de channel binding. Un conteo distinto de cero indica clientes legítimos que la auditoría no detectó.
• Alcance del cierre. Ambos controles activos de forma simultánea en todos los Controladores de Dominio del bosque, incluidos los de sitios remotos y los incorporados después del proyecto de remediación. Uno sin endurecer reabre el vector completo.

Y una trampa específica de Windows Server 2025: esta versión introduce una política de enforcement que tiene precedencia sobre la clásica y viene habilitada por defecto en despliegues nuevos. Pero un Controlador de Dominio actualizado desde una versión anterior conserva sus políticas de firma previas para evitar interrupciones. No queda protegido por el solo hecho de actualizar, y debe verificarse de forma explícita.

Contención, no cura

Hay medidas que no corrigen la falta de firma ni de channel binding, pero reducen el impacto de una retransmisión exitosa y cierran los vectores que la hacen viable en la práctica:

• Llevar ms-DS-MachineAccountQuota a cero, verificando antes qué procesos legítimos de aprovisionamiento dependen de ese cupo.
• Exigir firma SMB en servidores y clientes, eliminando el vector de retransmisión originado en ese protocolo.
• Verificar el parcheo frente a CVE-2019-1040 en la totalidad del parque.
• Deshabilitar el servicio WebClient donde no sea funcionalmente necesario.
• Habilitar Extended Protection for Authentication en los servicios HTTP sensibles, señaladamente la inscripción web de los Servicios de Certificados de Active Directory.

Conviene decirlo sin rodeos: la totalidad de este vector descansa sobre una propiedad de diseño de NTLM. La firma y el channel binding son contención. La migración a Kerberos y la restricción progresiva de NTLM mediante directiva eliminan la clase de ataque completa, no solo esta instancia. Es un proyecto de alcance mayor y debe tratarse como tal, pero debería figurar en la hoja de ruta para que la organización entienda qué está comprando con cada control.

Cómo saber si usted está expuesto

Hay una verificación que no cuesta nada y no modifica el entorno: revisar en el Visor de Eventos de sus Controladores de Dominio, bajo Applications and Services Logs \ Directory Service, si aparecen los Event ID 2886 y 3041. Ambos se emiten cada 24 horas mientras las políticas permanezcan en su valor permisivo. Si están ahí, el control no está activo.

Ese es apenas el punto de partida. Lo que viene después —construir el inventario de clientes incompatibles, negociar con proveedores, secuenciar el cambio sin cortar servicios y verificar el cierre en todo el bosque— es donde el proyecto se gana o se pierde.

En GFS InfoSec evaluamos esta y otras configuraciones del Directorio Activo dentro de nuestras Evaluaciones de Seguridad de Active Directory, y las explotamos en condiciones controladas durante nuestras pruebas de penetración de red interna, de modo que la severidad que usted recibe esté respaldada por lo que efectivamente se demostró en su entorno y no por un catálogo genérico. Si quiere saber en qué estado están hoy sus Controladores de Dominio, conversemos.