¿Qué es un ataque de amplificación CLDAP? | Riesgo DDoS en Active Directory

Un ataque de amplificación CLDAP es una técnica DDoS basada en reflexión que abusa de Connectionless LDAP (LDAP sin conexión): una variante UDP del Lightweight Directory Access Protocol usada por los controladores de dominio de Microsoft Active Directory para el descubrimiento rápido de servicios. El ataque envía solicitudes de búsqueda falsificadas a controladores de dominio expuestos en internet, que responden con datos de directorio enviados directamente a una víctima falsificada, produciendo factores de amplificación de aproximadamente 56x a 70x.

Resumen rápido — La amplificación CLDAP explota Connectionless LDAP (RFC 1798), una variante de LDAP basada en UDP que los controladores de dominio de Active Directory usan para el descubrimiento rápido de servicios vía “LDAP ping” en el puerto 389. Una pequeña solicitud CLDAP falsificada (~52 bytes) puede generar una respuesta de más de 1,000 bytes con metadatos de directorio, logrando factores de amplificación de alrededor de 56x-70x. El vector surgió públicamente a finales de 2016/2017 y rápidamente se convirtió en una de las técnicas de reflexión más abusadas porque apunta a una pieza específica, a menudo expuesta en internet, de infraestructura empresarial: los controladores de dominio de Windows. La mitigación se centra principalmente en eliminar la exposición (los controladores de dominio nunca deberían aceptar consultas UDP/389 desde el internet público), combinada con BCP38 upstream y scrubbing del lado del objetivo.

Última actualización: 2026-08-08

La amplificación CLDAP fue documentada por primera vez por investigadores de seguridad a finales de 2016 y se convirtió rápidamente en arma a lo largo de 2017, cuando múltiples proveedores de mitigación DDoS y CERT reportaron que se convertía en uno de los vectores de reflexión observados con mayor frecuencia en tráfico de ataque real, superando en algunos periodos a la amplificación DNS y NTP en volumen observado de eventos de ataque distintos. Su auge coincidió con, y parcialmente desplazó, el dominio anterior de la amplificación NTP, que había disminuido tras la amplia respuesta de parcheo de 2014. El atractivo de CLDAP para los atacantes provino de una población inusualmente grande y preexistente de reflectores expuestos: controladores de dominio Windows empresariales que los administradores habían dejado inadvertidamente alcanzables desde el internet público, a menudo como efecto secundario de una mala configuración de red más amplia en lugar de una decisión deliberada de exponer servicios de directorio.

¿Qué es CLDAP?

El Lightweight Directory Access Protocol (LDAP) es el protocolo estándar para consultar y modificar servicios de directorio, más comúnmente asociado con Microsoft Active Directory. El LDAP estándar opera sobre el puerto TCP 389 (o 636 para LDAPS), requiriendo que se establezca una conexión antes de que se ejecute cualquier consulta.

Connectionless LDAP (CLDAP), definido en RFC 1798 (posteriormente obsoleto en favor de describir el comportamiento tipo CLDAP dentro del marco más amplio de LDAPv3, aunque el mecanismo UDP persiste en la práctica), permite enviar solicitudes de búsqueda LDAP sobre UDP sin establecer primero una sesión TCP. Los controladores de dominio de Active Directory usan este mecanismo basado en UDP para un servicio ligero conocido popularmente como “LDAP ping”: los clientes lo usan para descubrir rápidamente el controlador de dominio disponible más cercano y obtener información básica de configuración antes de comprometerse con un intercambio LDAP o Kerberos completo, orientado a conexión. Esta es una optimización legítima y útil para entornos de Active Directory; la superficie de ataque surge específicamente cuando un controlador de dominio es alcanzable en el puerto UDP 389 desde el internet público en lugar de solo desde la red interna a la que debe servir.

Cómo funciona la amplificación CLDAP

Paso 1: El atacante envía una pequeña solicitud de búsqueda CLDAP falsificada a
        un controlador de dominio expuesto

Atacante → Controlador de Dominio Expuesto: solicitud de búsqueda CLDAP (~52 bytes,
                                        IP origen = IP de la víctima, UDP/389)

Paso 2: El controlador de dominio responde con información de servicio de
        directorio — típicamente una respuesta estilo "netlogon" describiendo
        el dominio, bosque, sitio y configuración del controlador

Controlador de Dominio → Víctima: respuesta de búsqueda CLDAP (~1,068 bytes o más,
                              dependiendo de la configuración del dominio/bosque)

Paso 3: El atacante repite esto a través de muchos controladores de dominio
        expuestos, encontrados mediante escaneo a nivel de internet

1,000 DC expuestos × tasa de consulta sostenida × ~1,068 bytes de respuesta
  = inundación volumétrica agregada convergiendo en la víctima

Ancho de banda propio usado por el atacante: 1,000 × ~52 bytes por consulta (insignificante)
Amplificación: bytes de respuesta / bytes de consulta ≈ 56x–70x

El tamaño de la respuesta varía según cuánta información de dominio, bosque y sitio publique el entorno de Active Directory consultado en su respuesta CLDAP por defecto, por lo que el factor de amplificación se reporta como un rango (aproximadamente 56x-70x) en lugar de un valor fijo: los bosques de Active Directory más grandes o complejos tienden a producir respuestas algo más grandes.

Por qué terminan expuestos los controladores de dominio

A diferencia de la población muy grande de IoT de SSDP, el conjunto de reflectores de CLDAP es menor en cantidad absoluta pero desproporcionadamente dañino de descubrir, porque cada reflector expuesto es la infraestructura de Active Directory de una empresa, lo que a menudo indica problemas de exposición de red más amplios:

• Reglas de firewall o de grupo de seguridad de cloud mal configuradas que permiten UDP/389 entrante desde cualquier origen, en lugar de restringirlo a la red corporativa interna o al rango de VPN.
• Controladores de dominio desplegados en infraestructura de cloud sin las mismas suposiciones de perímetro de red que los despliegues on-premises tradicionales, donde el DC podría estar detrás de un firewall corporativo por defecto.
• Despliegues de Active Directory multi-sitio donde los controladores de dominio en sucursales o sitios de DR se conectan sobre infraestructura con controles de perímetro más laxos que el centro de datos principal.
• Falta de conciencia de que el servicio UDP/389 de CLDAP, a diferencia del tráfico de autenticación LDAP estándar basado en TCP, es específicamente la pieza que nunca debería ser alcanzable desde fuera de la red de confianza, incluso en entornos que por lo demás cuidan el firewall de LDAP/Kerberos/SMB.

Comparación de factores de amplificación

CLDAP se ubica en un rango de amplificación similar al de DNS, notablemente más alto que SSDP pero muy por debajo del pico histórico de NTP. Su importancia en el panorama de amenazas proviene menos de ser el vector con la amplificación más alta y más de haber surgido como una técnica de reflexión ampliamente disponible, moderadamente eficiente y, de manera crítica, comparativamente poco monitoreada en relación con los vectores de DNS y NTP más establecidos, contra los que los operadores de red ya habían pasado años reforzándose para cuando CLDAP creció.

La amplificación CLDAP en ataques documentados a gran escala

Los reportes de la industria pública han asociado a la amplificación CLDAP, a menudo combinada con otros vectores de reflexión basados en UDP en campañas multi-vector, con algunos de los ataques DDoS más grandes reportados públicamente en los años posteriores a su surgimiento, incluyendo eventos reportados en el rango de múltiples terabits por segundo donde CLDAP contribuyó junto con otros protocolos de amplificación. Como con otros vectores de amplificación, los atacantes combinan frecuentemente varios protocolos de reflexión (DNS, NTP, SSDP, CLDAP) simultáneamente en una sola campaña para maximizar el volumen agregado y complicar la mitigación específica por protocolo.

Señales de detección

# Inspeccionar tráfico CLDAP en la red
tcpdump -n 'udp port 389' -v

# Correlacionar NetFlow para respuestas UDP/389 sin consultas salientes coincidentes
nfdump -r flows.nf 'proto udp and src port 389' -o extended

# Verificar si un controlador de dominio propio responde a consultas CLDAP desde el WAN
# (ejecutar solo contra infraestructura propia o para la que se tenga autorización)
ldapsearch -H cldap://<ip-publica-del-dc> -x -s base -b "" "(objectClass=*)" netlogon

Si un controlador de dominio responde a una consulta CLDAP con origen externo, está expuesto y debe remediarse de inmediato restringiendo el acceso entrante UDP/389 solo a rangos internos de confianza.

Técnicas de mitigación

Eliminar la exposición pública de los controladores de dominio en UDP/389

La solución más directa y completa: las reglas de firewall o de grupo de seguridad de cloud deben restringir el acceso entrante UDP (y TCP) en el puerto 389 a los rangos de red internos de la organización y a cualquier VPN o enlace WAN legítimo de sitio a sitio, nunca al internet público en general. El mecanismo de descubrimiento de servicio CLDAP de Active Directory no tiene ningún caso de uso legítimo que involucre clientes de internet arbitrarios.

Auditoría de red y de grupos de seguridad de cloud

Como la exposición de CLDAP a menudo resulta de una mala configuración de grupos de seguridad de cloud en lugar de un diseño deliberado, las organizaciones que corren controladores de dominio en entornos de cloud deberían auditar específicamente las reglas entrantes de UDP/389, UDP/88 (Kerberos) y puertos de servicio relacionados de Active Directory como parte de revisiones rutinarias de postura de seguridad en la nube, ya que estos puertos son fáciles de pasar por alto en medio de una gestión de ACL de red más amplia.

BCP38 / Filtrado de ingreso (RFC 2827)

Como la amplificación CLDAP depende del IP spoofing para redirigir la respuesta del controlador de dominio hacia la víctima, el filtrado de ingreso BCP38 (RFC 2827) en la red del atacante evitaría que la consulta falsificada saliera de la propia red del atacante. Como con todos los ataques de reflexión que dependen de spoofing, esta defensa debe aplicarse en la red upstream que origina el tráfico.

Rate limiting y correlación de respuesta en el objetivo

Las organizaciones que son objetivo de tráfico amplificado por CLDAP pueden limitar la tasa de UDP/389 entrante y correlacionar las respuestas entrantes contra consultas salientes previamente enviadas, descartando respuestas CLDAP no solicitadas sin necesitar coordinación con los propietarios de los controladores de dominio expuestos.

Scrubbing upstream y absorción distribuida

Dado que la amplificación CLDAP se combina frecuentemente con otros vectores de reflexión en campañas multi-protocolo, la absorción en un edge distribuido o un proveedor de scrubbing con suficiente capacidad agregada en todos los vectores simultáneamente es la mitigación práctica para un objetivo que enfrenta este tipo de ataque. Consulta Blackhole Routing vs. Scrubbing para enfoques arquitectónicos.

Errores comunes

Cómo implementarlo con Azion

La red distribuida de Azion puede ayudar a absorber y filtrar el tráfico de amplificación CLDAP antes de que llegue a un origen, mientras que eliminar la exposición de tus propios controladores de dominio como reflectores sigue siendo una responsabilidad de configuración de red independiente de cualquier proveedor de edge:

• DDoS Protection brinda detección y mitigación siempre activa para tráfico UDP volumétrico, incluyendo inundaciones amplificadas por CLDAP y campañas multi-vector que combinan CLDAP con otros protocolos de reflexión, absorbiéndolo a través de la infraestructura distribuida de Azion en lugar de en tu origen.
• Network Shield puede aplicar reglas a nivel de red para identificar y filtrar patrones de tráfico UDP/389 anómalos consistentes con reflexión CLDAP, dependiendo de la configuración.
• Firewall permite reglas personalizadas para rate limiting y filtrado basado en protocolo a nivel de red.
• WAAP combina protecciones de red y de capa de aplicación para organizaciones que enfrentan campañas multi-vector que combinan amplificación volumétrica con abuso a nivel de aplicación.

Si tu organización opera controladores de dominio de Active Directory, auditar y restringir la exposición de UDP/389 sigue siendo un paso complementario necesario, ya que aborda si tu propia infraestructura puede ser usada como arma contra otros, no si tus aplicaciones orientadas al público están protegidas de ataques entrantes.

Recursos relacionados

• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• ¿Qué es un ataque reflejado de ICMP/UDP?
• ¿Qué es la amplificación DNS?
• Azion DDoS Protection

Preguntas frecuentes

¿Qué es un ataque de amplificación CLDAP? Un ataque de amplificación CLDAP envía una pequeña solicitud de búsqueda Connectionless LDAP falsificada a un controlador de dominio de Active Directory expuesto en internet, que responde con metadatos de directorio enviados directamente a la dirección de la víctima falsificada en lugar de al atacante. Agregado a través de muchos controladores de dominio expuestos, esto genera una inundación volumétrica contra la víctima.

¿Qué es CLDAP y en qué se diferencia del LDAP normal? El LDAP estándar requiere establecer una conexión TCP antes de que se ejecute cualquier consulta. CLDAP (Connectionless LDAP), definido en RFC 1798, permite solicitudes de búsqueda LDAP sobre UDP sin una conexión previa, y los controladores de dominio de Active Directory lo usan para un mecanismo rápido de descubrimiento de servicio “LDAP ping” que permite a los clientes encontrar rápidamente el controlador de dominio más cercano antes de comprometerse con un intercambio de autenticación completo.

¿Cuál es el factor de amplificación de los ataques CLDAP? La amplificación CLDAP típicamente produce factores en el rango de aproximadamente 56x a 70x, dependiendo de cuánta información de dominio, bosque y sitio incluya el entorno de Active Directory objetivo en su respuesta por defecto. Esto lo ubica en un rango similar a la amplificación DNS y notablemente por encima de SSDP, aunque por debajo del pico histórico de NTP.

¿Cuándo surgió la amplificación CLDAP como vector DDoS? La amplificación CLDAP fue documentada públicamente por primera vez por investigadores de seguridad a finales de 2016 y se volvió ampliamente observada en tráfico de ataque real durante 2017, desplazando parcialmente a la amplificación NTP a medida que los operadores de red ya se habían reforzado contra el vector anterior y más establecido tras la ola de parcheo de 2014.

¿Por qué quedan expuestos los controladores de dominio de Active Directory a abuso CLDAP? La exposición típicamente resulta de reglas de firewall o de grupo de seguridad de cloud mal configuradas que permiten UDP/389 entrante desde cualquier origen en lugar de restringirlo a la red interna, despliegues en cloud que carecen de las suposiciones de perímetro tradicionales on-premises, o despliegues multi-sitio con controles más laxos en ubicaciones de sucursal o DR. El descubrimiento de servicio basado en UDP de CLDAP nunca fue pensado para ser alcanzable desde el internet público.

¿Un firewall puede detener un ataque de amplificación CLDAP en mi contra? Un firewall en la red del objetivo puede limitar la tasa o filtrar el tráfico UDP/389 entrante y correlacionar respuestas contra consultas salientes previamente enviadas, reduciendo el impacto. No puede evitar que se genere el ataque; eso requiere que los controladores de dominio expuestos que se usan como reflectores tengan restringido su propio acceso de red, lo cual está fuera del control del objetivo a menos que este también opere esos controladores de dominio.

¿Cómo verifico si mi propio controlador de dominio está expuesto a abuso CLDAP? Envía una solicitud de búsqueda CLDAP a la dirección IP pública del controlador de dominio en el puerto UDP 389 desde un host de prueba externo que controles y verifica si devuelve metadatos de directorio. Si responde, el controlador de dominio está expuesto y debe tener su acceso de red restringido a rangos internos de confianza de inmediato. Solo prueba infraestructura que poseas o para la que tengas autorización explícita.

¿La exposición de CLDAP es solo un riesgo DDoS, o también filtra información? Ambos. Un controlador de dominio expuesto que responde a consultas CLDAP puede divulgar el nombre de dominio, la estructura del bosque, la topología de sitio y los hostnames de los controladores de dominio a cualquiera que lo consulte: información útil para reconocimiento previo a un ataque más dirigido contra la organización, independientemente de cualquier uso DDoS. Esto convierte a la exposición de CLDAP en un riesgo combinado de reflexión y divulgación de información.

¿BCP38 detiene los ataques de amplificación CLDAP? El filtrado de ingreso BCP38 (RFC 2827), aplicado en la red donde se origina el tráfico de ataque, evitaría que la consulta falsificada llegara al controlador de dominio expuesto, ya que el ataque depende por completo del IP spoofing para redirigir las respuestas a la víctima. La adopción de BCP38 sigue siendo incompleta a nivel global, lo cual es parte de por qué la amplificación CLDAP persiste como un vector viable junto con DNS, NTP y SSDP.

¿Cómo se compara la amplificación CLDAP con la amplificación DNS y NTP como prioridad defensiva? CLDAP debería monitorearse junto con DNS y NTP como un vector de amplificación estándar en lugar de tratarse como una preocupación secundaria, ya que reportes públicos han documentado periodos donde el volumen de reflexión basado en CLDAP fue comparable o superó a estos vectores más establecidos. Las organizaciones deberían extender la cobertura de detección (monitoreo NetFlow/sFlow para UDP/389 junto con UDP/53 y UDP/123) y, si operan Active Directory, verificar específicamente la exposición del controlador de dominio en lugar de asumir que los esfuerzos de refuerzo existentes de DNS/NTP lo cubren.

Fuentes:

• IETF. “Connection-less LDAP.” RFC 1798. 1995.
• IETF. “Lightweight Directory Access Protocol (LDAP): The Protocol.” RFC 4511. 2006.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
• US-CERT|CISA. “UDP-Based Amplification Attacks.”
• NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”