A CLDAP amplification attack is a reflection-based DDoS technique that abuses Connectionless LDAP — a UDP variant of the Lightweight Directory Access Protocol used by Microsoft Active Directory domain controllers for fast service discovery — sending spoofed search requests to internet-exposed domain controllers, which respond with directory data sent directly to a spoofed victim, producing amplification factors of roughly 56x to 70x.
TL;DR: CLDAP amplification exploits Connectionless LDAP (RFC 1798), a UDP-based LDAP variant that Active Directory domain controllers use for fast “LDAP ping” service discovery on port 389. A small spoofed CLDAP search request (~52 bytes) can trigger a response of over 1,000 bytes containing directory metadata, achieving amplification factors around 56x–70x. The vector emerged publicly in late 2016/2017 and quickly became one of the most abused reflection techniques because it targets a specific, often internet-exposed piece of enterprise infrastructure: Windows domain controllers. Mitigation is primarily about exposure elimination — domain controllers should never accept UDP/389 queries from the public internet — combined with BCP38 upstream and target-side scrubbing.
Last updated: 2026-08-27
CLDAP amplification was first documented by security researchers around late 2016 and rapidly weaponized through 2017, when multiple DDoS mitigation vendors and CERTs reported it becoming one of the most frequently observed reflection vectors in live attack traffic, in some periods surpassing DNS and NTP amplification in observed volume of distinct attack events. Its rise coincided with, and partly displaced, the earlier dominance of NTP amplification, which had declined following the widespread 2014 patching response. CLDAP’s appeal to attackers came from an unusually large, pre-existing population of exposed reflectors: enterprise Windows domain controllers that administrators had inadvertently left reachable on the public internet, often as a side effect of broader network misconfiguration rather than a deliberate choice to expose directory services.
What Is CLDAP?
The Lightweight Directory Access Protocol (LDAP) is the standard protocol for querying and modifying directory services, most commonly associated with Microsoft Active Directory. Standard LDAP operates over TCP port 389 (or 636 for LDAPS), requiring a connection to be established before any query executes.
Connectionless LDAP (CLDAP), defined in RFC 1798 (later obsoleted in favor of describing CLDAP-like behavior within the broader LDAPv3 framework, though the UDP mechanism persists in practice), allows LDAP search requests to be sent over UDP without first establishing a TCP session. Active Directory domain controllers use this UDP-based mechanism for a lightweight service popularly called “LDAP ping” — clients use it to quickly discover the nearest available domain controller and retrieve basic configuration information before committing to a full, connection-oriented LDAP or Kerberos exchange. This is a legitimate and useful optimization for Active Directory environments; the attack surface arises specifically when a domain controller is reachable on UDP port 389 from the public internet rather than only from the internal network it is meant to serve.
How CLDAP Amplification Works
Step 1: Attacker sends a small, spoofed CLDAP search request to an exposed domain controller
Attacker → Exposed Domain Controller: CLDAP search request (~52 bytes, src IP = victim's IP, UDP/389)
Step 2: The domain controller responds with directory service information — typically a "netlogon" style response describing the domain, forest, site, and controller configuration
Domain Controller → Victim: CLDAP search response (~1,068 bytes or more, depending on domain/forest configuration)
Step 3: The attacker repeats via many exposed domain controllers found through internet-wide scanning
1,000 exposed DCs × steady query rate × ~1,068 bytes response = aggregate volumetric flood converging on the victim
Attacker's own bandwidth used: 1,000 × ~52 bytes per query (negligible)Amplification: response bytes / query bytes ≈ 56x–70xThe response size varies with how much domain, forest, and site information the queried Active Directory environment publishes in its default CLDAP response, which is why the amplification factor is reported as a range (roughly 56x–70x) rather than a fixed value — larger or more complex Active Directory forests tend to produce somewhat larger responses.
Why Domain Controllers End Up Exposed
Unlike SSDP’s very large IoT population, CLDAP’s reflector pool is smaller in absolute count but disproportionately damaging to discover, because each exposed reflector is an enterprise’s Active Directory infrastructure — often indicating broader network exposure issues:
- Misconfigured firewall or cloud security group rules that allow inbound UDP/389 from any source, rather than restricting it to the internal corporate network or VPN range.
- Domain controllers deployed on cloud infrastructure without the same network perimeter assumptions as traditional on-premises deployments, where the DC may sit behind a corporate firewall by default.
- Multi-site Active Directory deployments where domain controllers at branch offices or DR sites are connected over infrastructure with looser perimeter controls than the main data center.
- Lack of awareness that CLDAP’s UDP/389 service, unlike standard TCP-based LDAP authentication traffic, is specifically the piece that should never be reachable from outside the trusted network, even in environments that otherwise carefully firewall LDAP/Kerberos/SMB.
Amplification Factor Comparison
| Protocol | Query Size | Typical Max Response | Amplification Factor |
|---|---|---|---|
| CLDAP | ~52 bytes | ~1,068+ bytes | ~56x–70x |
| DNS (ANY/EDNS0) | ~60 bytes | ~4,000 bytes | ~28x–70x |
| SSDP | ~110 bytes | ~750 bytes | ~7x–30x |
| NTP (monlist) | ~8 bytes | ~4,460 bytes | ~200x–556x |
| Memcached | ~15 bytes | Up to ~134 MB | Up to ~50,000x |
CLDAP sits in a similar amplification range to DNS amplification, notably higher than SSDP but well below NTP’s peak historical factor. Its significance in the threat landscape comes less from being the single highest-amplification vector and more from having emerged as a widely available, moderately efficient, and — critically — comparatively under-monitored reflection technique relative to the more established DNS and NTP vectors that network operators had already spent years hardening against by the time CLDAP surged.
CLDAP Amplification in Documented Large-Scale Attacks
Public industry reporting has associated CLDAP amplification, often combined with other UDP-based reflection vectors in multi-vector campaigns, with some of the largest publicly reported DDoS attacks in the years following its emergence, including events reported in the multiple-terabit-per-second range where CLDAP contributed alongside other amplification protocols. As with other amplification vectors, attackers frequently combine several reflection protocols (DNS, NTP, SSDP, CLDAP) simultaneously in a single campaign to maximize aggregate volume and complicate protocol-specific mitigation.
Detection Signals
| Signal | What to observe | Tool |
|---|---|---|
| Inbound UDP/389 traffic with no matching outbound CLDAP query | Response-shaped CLDAP packets arriving without a corresponding local directory-service query | NetFlow/IPFIX, tcpdump -n udp port 389 |
| Source IPs resolving to enterprise/hosting ASNs rather than residential ranges | Attack traffic converging from domain-controller-hosting networks, distinct from the consumer-IP pattern typical of SSDP attacks | Flow analysis, ASN enrichment |
| CLDAP responses containing recognizable netlogon/domain metadata | Packet content consistent with genuine Active Directory CLDAP ping responses rather than another UDP protocol on the same port | Packet capture, DPI |
| Sudden UDP/389 volume spike with no legitimate internal Active Directory traffic explanation | Traffic pattern inconsistent with the organization’s own internal directory-service query volume | SNMP/RMON, interface counters |
# Inspect for CLDAP traffic on the wiretcpdump -n 'udp port 389' -v
# Correlate NetFlow for UDP/389 responses without matching outbound queriesnfdump -r flows.nf 'proto udp and src port 389' -o extended
# Check whether a domain controller you own responds to WAN-side CLDAP queries# (only run against infrastructure you own or are authorized to test)ldapsearch -H cldap://<dc-public-ip> -x -s base -b "" "(objectClass=*)" netlogonIf a domain controller responds to an externally-sourced CLDAP query, it is exposed and should be remediated immediately by restricting UDP/389 inbound access to trusted internal ranges only.
Mitigation Techniques
Eliminate public exposure of domain controllers on UDP/389
The most direct and complete fix: firewall or cloud security group rules should restrict inbound UDP (and TCP) port 389 to the organization’s internal network ranges and any legitimate site-to-site VPN or WAN links — never to the public internet at large. Active Directory’s CLDAP service discovery mechanism has no legitimate use case involving arbitrary internet clients.
Network and cloud security group auditing
Because CLDAP exposure often results from cloud security group misconfiguration rather than deliberate design, organizations running domain controllers in cloud environments should specifically audit inbound rules for UDP/389, UDP/88 (Kerberos), and related Active Directory service ports as part of routine cloud security posture reviews, since these ports are easy to overlook amid broader network ACL management.
BCP38 / Ingress Filtering (RFC 2827)
Because CLDAP amplification depends on IP spoofing to redirect the domain controller’s response to the victim, BCP38 (RFC 2827) ingress filtering at the attacker’s network would prevent the spoofed query from leaving the attacker’s own network. As with all spoofing-dependent reflection attacks, this defense must be applied upstream by the networks that originate the traffic.
Rate limiting and response correlation at the target
Organizations being targeted by CLDAP-amplified traffic can rate-limit inbound UDP/389 and correlate incoming responses against previously sent outbound queries, discarding unsolicited CLDAP responses without needing coordination from the exposed domain controllers’ owners.
Upstream scrubbing and distributed absorption
Given that CLDAP amplification is frequently combined with other reflection vectors in multi-protocol campaigns, absorption at a distributed edge or scrubbing provider with sufficient aggregate capacity across all vectors simultaneously is the practical mitigation for a target facing this kind of attack. See Blackhole Routing vs. Scrubbing for architectural approaches.
Common Mistakes
| Mistake | Impact | Correct solution |
|---|---|---|
| Assuming domain controllers are inherently internal-only and require no explicit firewall verification | Cloud deployments and multi-site architectures can inadvertently expose UDP/389 to the internet through default or overly broad security group rules | Explicitly audit and test whether domain controllers respond to CLDAP queries from outside the trusted network; do not assume exposure is impossible |
| Blocking all inbound UDP/389 as an incident response without checking internal dependencies | Can disrupt legitimate CLDAP-based service discovery for branch offices or remote sites relying on WAN links that traverse the filtering point | Scope filtering to distinguish public-internet-sourced traffic from legitimate internal or VPN-based Active Directory traffic |
| Treating CLDAP exposure as purely a DDoS-reflection risk | An exposed domain controller can also leak sensitive directory metadata (domain name, forest structure, site topology, DC hostnames) useful for reconnaissance ahead of a targeted attack against the organization itself | Treat CLDAP exposure as both a DDoS-reflector risk and an information-disclosure/reconnaissance risk requiring remediation regardless of DDoS concerns |
| Relying solely on the domain controller’s own resource limits to survive being abused as a reflector | Sustained abuse as a reflector consumes the domain controller’s own bandwidth and processing capacity, potentially degrading legitimate authentication and directory services for the organization that owns it | Remediate exposure directly rather than assuming the DC can absorb reflector traffic without operational impact |
| Ignoring CLDAP because DNS and NTP amplification are better known | CLDAP has been observed at comparable or higher volumes than legacy vectors in various reporting periods since its 2016/2017 emergence | Include CLDAP/UDP-389 monitoring alongside DNS/UDP-53 and NTP/UDP-123 in standard amplification-vector detection coverage |
How to Implement on Azion
Azion’s distributed network can help absorb and filter CLDAP-amplification traffic before it reaches an origin, while eliminating your own domain controllers’ exposure as reflectors remains a network-configuration responsibility independent of any edge provider:
- DDoS Protection provides always-on detection and mitigation for volumetric UDP traffic, including CLDAP-amplified floods and multi-vector campaigns combining CLDAP with other reflection protocols, absorbing it across Azion’s distributed infrastructure rather than at your origin.
- Network Shield can apply network-level rules to identify and filter anomalous UDP/389 traffic patterns consistent with CLDAP reflection, depending on configuration.
- Firewall enables custom rules for rate limiting and protocol-based filtering at the network layer.
- WAAP combines network and application-layer protections for organizations facing multi-vector campaigns that pair volumetric amplification with application-layer abuse.
If your organization operates Active Directory domain controllers, auditing and restricting UDP/389 exposure remains a necessary complementary step, since it addresses whether your own infrastructure can be weaponized against others rather than whether your public-facing applications are protected from incoming attacks.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is IP Spoofing?
- What Is DNS Amplification?
- Azion DDoS Protection
Frequently Asked Questions
What is a CLDAP amplification attack? A CLDAP amplification attack sends a small, spoofed Connectionless LDAP search request to an internet-exposed Active Directory domain controller, which responds with directory metadata sent directly to the spoofed victim address instead of the attacker. Aggregated across many exposed domain controllers, this generates a volumetric flood against the victim.
What is CLDAP and how does it differ from regular LDAP? Standard LDAP requires establishing a TCP connection before any query executes. CLDAP (Connectionless LDAP), defined in RFC 1798, allows LDAP search requests over UDP without a prior connection, and Active Directory domain controllers use it for a fast “LDAP ping” service-discovery mechanism that lets clients quickly find the nearest domain controller before committing to a full authentication exchange.
What is the amplification factor for CLDAP attacks? CLDAP amplification typically produces factors in the range of roughly 56x to 70x, depending on how much domain, forest, and site information the targeted Active Directory environment includes in its default response. This places it in a similar range to DNS amplification and notably above SSDP, though below NTP’s historical peak.
When did CLDAP amplification emerge as a DDoS vector? CLDAP amplification was first publicly documented by security researchers around late 2016 and became widely observed in live attack traffic through 2017, partly displacing NTP amplification as network operators had already hardened against the earlier, more established vector following the 2014 patching wave.
Why are Active Directory domain controllers exposed to CLDAP abuse? Exposure typically results from misconfigured firewall or cloud security group rules that allow inbound UDP/389 from any source rather than restricting it to the internal network, cloud deployments that lack traditional on-premises perimeter assumptions, or multi-site deployments with looser controls at branch or DR locations. CLDAP’s UDP-based service discovery was never intended to be reachable from the public internet.
Can a firewall stop a CLDAP amplification attack against me? A firewall at the target’s network can rate-limit or filter inbound UDP/389 traffic and correlate responses against previously sent outbound queries, reducing impact. It cannot prevent the attack from being generated — that requires the exposed domain controllers being abused as reflectors to have their own network access restricted, which is outside the target’s control unless the target also happens to operate those domain controllers.
How do I check if my own domain controller is exposed to CLDAP abuse? Send a CLDAP search request to the domain controller’s public IP address on UDP port 389 from an external test host you control and check whether it returns directory metadata. If it responds, the domain controller is exposed and should have its network access restricted to trusted internal ranges immediately. Only test infrastructure you own or are explicitly authorized to test.
Is CLDAP exposure only a DDoS risk, or does it also leak information? Both. An exposed domain controller responding to CLDAP queries can disclose domain name, forest structure, site topology, and domain controller hostnames to anyone who queries it — information useful for reconnaissance ahead of a more targeted attack against the organization, independent of any DDoS use. This makes CLDAP exposure a combined reflection and information-disclosure risk.
Does BCP38 stop CLDAP amplification attacks? BCP38 (RFC 2827) ingress filtering, applied at the network where attack traffic originates, would prevent the spoofed query from ever reaching the exposed domain controller, since the attack depends entirely on IP spoofing to redirect responses to the victim. Adoption of BCP38 remains incomplete globally, which is part of why CLDAP amplification persists as a viable vector alongside DNS, NTP, and SSDP.
How does CLDAP amplification compare to DNS and NTP amplification as a defensive priority? CLDAP should be monitored alongside DNS and NTP as a standard amplification vector rather than treated as a secondary concern, since public reporting has documented periods where CLDAP-based reflection volume was comparable to or exceeded these longer-established vectors. Organizations should extend detection coverage (NetFlow/sFlow monitoring for UDP/389 alongside UDP/53 and UDP/123) and, if they operate Active Directory, verify domain controller exposure specifically rather than assuming existing DNS/NTP hardening efforts cover it.
Sources:
- 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.”
- Akamai|Prolexic. “Threat Advisory: CLDAP Reflection Attacks.” 2017.
- NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”