SANS ISC: Exposed Windows Domain Controllers Used in CLDAP DDoS Attacks - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

LDAP, like many UDP based protocols, has the ability to send responses that are larger than the request. With UDP not requiring any handshake before data is sent, these protocols make ideal amplifiers for reflective distributed denial of service attacks. Most commonly, these attacks abuse DNS and we have talked about this in the past. But LDAP is another protocol that is often abused.

CLDAP has been on the radar for DDoS attacks at least since 2014 (likely earlier, but this is the earliest mention I found with a little bit of Google): https://us-cert.cisa.gov/ncas/alerts/TA14-017A . But as recent as in June, CLDAP was a component of major DDoS attacks ( https://blogs.akamai.com/2020/06/akamai-mitigates-sophisticated-144-tbps-and-385-mpps-ddos-attack.html )

Some of our honeypots have been seeing a small number of the reflected packets from these attacks. In investigating them, we noticed that many of them appear to come from exposed windows domain controllers. Windows domain controllers do use LDAP for active directory and support connectionless LDAP (CLDAP) out of the box. CLDAP is part of the issue here as it supports UDP.

A quick sample from a lab system:

IP (tos 0x0, ttl 64, id 26281, offset 0, flags [none], proto UDP (17), length 67)
    172.16.29.1.65465 > 172.16.29.232.389: UDP, length 39
IP (tos 0x0, ttl 128, id 17175, offset 0, flags [none], proto UDP (17), length 3090)
    172.16.29.232.389 > 172.16.29.1.65465: UDP, length 3062

A simple 39-byte request will cause a 3062-byte response. 

Interestingly, we also see floods of SYN-ACK packets from systems scanning for CLDAP. This could be related to these systems being overloaded with traffic and responding to spoofed TCP requests for port 389 as well as UDP requests.

Here a quick Wireshark snapshot of the SYN-ACK responses. Note how they arrive in less than a second.

So what should you do? I do not know of a good reason to allow clear text LDAP (Port 389, not LDAP over TLS) across your perimeter. Close that port!

---

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|