How CLDAP Reflectors Enable DDoS Attacks & Ways to Reduce Your Exposure

CLDAP is often exposed to the internet without its administrators’ knowledge, enabling hackers to exploit its amplification factor to launch DDoS attacks. Here’s how to defend against the threat.

November 22, 2022

CLDAP, or connectionless lightweight directory access protocol, is just one of many protocols used for UDP amplified reflection attacks. However, it is steadily growing as the preferred tool of distributed denial of service threat actors. Let’s explore why reflection attacks are gaining momentum and ways to defend against them.

Organizations can protect themselves from any reflection attack if the proper steps are taken to prepare for prevention and response. Still, we also need to address the root cause: system misconfiguration by the unwary.

What Is a UDP Amplified Reflection Attack?

To define a UDP amplified reflection attack, let us break it down into its components, starting with UDP.

UDP

UDP, or User Data Protocol, is part of the TCP/IP suite. Running at OSI layer 4, it creates network datagrams by dividing data received from the upper layers into segments and encapsulating them with the source port number, destination port number, size, and a checksum. But unlike TCP, UDP is connectionless. It sends datagrams and then forgets about them. It does not care if the datagrams make it to their destinations.

Connectionless communication is faster than the connection-based TCP that ensures data delivery. However, it also provides an opportunity for an inexpensive approach to launching disabling denial of service attacks, which cannot usually be done with TCP because of the required handshake.

LDAP usually uses TCP, but there are infrequent instances in which it uses UDP. When using UDP, it is known as CLDAP. In either case, the protocol is used to query directory services, like Active Directory, that return information about users and services, including authentication information, manager name, email address, and other data stored by the business. 

Domain controllers should never be exposed directly to the internet, but when they are, they add to the millions of other devices that contribute to UDP reflection attacks.

See More: How to Defend Against Deadbolt Ransomware Attacks On NAS Devices

Reflection

Reflection is possible when organizations expose any UDP protocol to the internet, as shown in Figure 1.

DDoS

Figure 1: Simple Reflection

 After finding an exposed UDP service, like CLDAP,

  1.     the threat actor sends a request to the exposed service; the request contains the IP address of the victim’s server as the source address
  2.     The abused service responds by sending one or more packets to the victim’s web server, the web server at the spoofed source IP address contained in the initial request
  3.     The victim’s server receives the response and eventually drops it, but not before using up valuable server resources

This simple reflection will not cause much of a problem for the victim. Further, tracking the attacker using the traffic from his computer to the reflector would be easy. Let’s step up the attack while masking the threat actor’s location.

In Figure 2, the threat actor has contracted with a bot service provider to launch a distributed reflection attack. The bot service provider causes a portion of their bot resources to send service requests to the exposed CLDAP service on identified misconfigured devices. There are thousands of known devices the bot service provider can use.

Amplified Reflection DDoS Attack

Figure 2: Amplified Reflection DDoS Attack

This enables a distributed denial of service attack that does not reveal the identity of the threat actor who wants to disrupt the target’s services. But there is also another added element: amplification.

Amplification

Some services can return a much bigger response than the initial request. CLDAP, for example, can provide up to what is known as a 70X amplification factor. In other words, a standard 52 Byte request can result in the reflection devices sending up to a 3640 Byte response (70 * 52).   This amplification enables a fast overwhelming of the target with fewer requests.

CLDAP, available at port 389, has one of the most significant amplification factors, which is why it has become so popular. Table 1 shows other standard services threat actors can use for reflection attacks and their amplification factors. 

Top Amplification Factors

Table 1: Top Amplification Factors

Why CLDAP is commonly exposed

In addition to having a significant amplification factor, CLDAP is often exposed to the internet without its administrators’ knowledge.

According to David Allen, contributing editor at onmsft.com, threat actors have been usingOpens a new window CLDAP since about 2007 for reflection attacks. The number of open CLDAP instances and related DDoS attacks have been increasing, likely caused by a nearly 60% rise in the number of exposed CLDAP locations in the last year. Black Lotus Labs places much of the blame on Microsoft.

Black Lotus assertsOpens a new window that CLDAP was never wholly implemented across most services, but Microsoft automatically enables a partial CLDAP implementation when a domain controller is initialized. The protocol uses a single command, LDAP ping. Microsoft writesOpens a new window that it uses this command only to identify “… whether services are live on a domain controller ….”

Many, if not most, organizations lack dedicated internal security teams. They may also lack security-conscious network personnel that ensure unwanted exposure to the internet is blocked, like blocking internet access to port 389. This results in domain controllers being exposed to the internet, which is never a good idea for the domain owner. It is a security disaster waiting to happen and creates opportunities for reflection attacks.

The exposure of CLDAP, NTP, and other reflection protocols results from poorly configured networks and connected systems, a situation potential victim organizations cannot do much about, one that only gets worse and requires a strong defense.

See More: Defending Against Industroyer2 and Securing OT in a Connected World

Defending Against Reflection Attacks

The defenses that help defend against reflection attacks can have unwanted effects on a network. Consequently, some or all of the safeguards listed below might only take effect when initiating an incident response, a response that involves engaging a cloud service that can quickly implement what is needed to ensure continued delivery of customer services. 

Another option is always running all internet access through a service provider that monitors for and quickly responds to any type of DDoS attack and offers some level of always-on filtering. Further, cloud service providers like Azure and Alibaba provide both DDoS detection and response capabilities.

Donald Shin, writing for A10, providesOpens a new window a set of safeguards for defending against reflection attacks. 

Rate Limiting. There are two types of rate limitingOpens a new window . The most common form is source limiting. Source rate limiting uses the source IP addresses to track how much time elapses between each incoming request. If a source sends too many packets based on an expected and defined rate, it will be told to slow down. This limits the number of reflection requests a victim system must handle.

Regular Expression Filter. A Regex filterOpens a new window filters packets looking for a defined pattern. If the pattern is matched, the packet can be dropped.

Additional safeguards include,

Traffic Scrubbing: Incoming traffic is sent to a processing center and cleaned of unwanted traffic. This is related to regex filtering and rate limiting, both of which can be part of traffic scrubbing. Always-on traffic scrubbing is often not an option because it can severely degrade performance.

Server Redundancy: Having more than one server to provide customer services and business operations support is always a good plan for denial-of-service attacks and unexpected increases in service needs. Using a cloud service with automatic resource expansion when needed can help during the first minutes of a reflection attack, the critical minutes between the start of the attack and an adequate response. 

Final thoughts

UDP amplified reflection attacks, like those that use CLDAP, are made possible by misconfigured networks that expose UDP services to the internet. Educating business owners and their IT teams is a good start in helping eliminate reflection opportunities. 

Larger organizations should include scanning for protocols unnecessarily exposed to the internet as part of their own risk assessments. Teams should ensure that any port open to the internet is part of an explicitly defined IP address/port number pair required for business operation.

All organizations must assume there will always be exposed UDP protocols and prepare accordingly. Also, they need to start setting up detection capabilities to watch for emerging TCP reflection attacks.

Until recently, TCP reflection was impractical due to shortcomings in threat actors’ control over the process, shortcomings caused by the TCP handshake. However, threat actors have found a way around this challenge by using middleboxes, inline devices used for network management tasks outside of routing or switching. 

Finally, we have to assume that threat actors will always find a way to flood our resources, requiring that organizations plan for DDoS attacks, including documenting and practicing timely responses. Practice activities should integrate needed third-party denial of service mitigation service providers.

Let us know if you enjoyed reading this article on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!

Image source: Shutterstock

MORE ON DDOS ATTACKS

Tom Olzak
Tom Olzak

Cybersecurity Researcher, Author & Educator

Independent security researcher and an IT professional since 1983, with experience in programming, network engineering, and security. I have an MBA as well as CISSP certification. I am also an online instructor for the University of Phoenix. I've held positions as an IS director, director of infrastructure engineering, director of information security, and programming manager at a variety of manufacturing, healthcare, and distribution companies. Before joining the private sector, I served 10 years in the United States Army Military Police with four years as a military police investigator. I've written four books, Just Enough Security, Microsoft Virtualization, Enterprise Security: A Practitioner's Guide, and Incident Management and Response Guide. I am also the author of various papers and articles on security management.
Take me to Community
Do you still have questions? Head over to the Spiceworks Community to find answers.