LDAP injection: What it is and how to prevent it?

SQL injection might receive all the headlines, but LDAP injection is just as dangerous. Let's say your applications send a request to a directory service, like Active Directory, without carefully sanitizing t he user input. LDAP injection enables the attackers to manipulate the queries, bypass the authentication mechanisms in place, and gain access to sensitive data.

What is LDAP injection?

LDAP injection is an attack where malicious characters are injected into input fields that construct LDAP queries. When the input is not sanitized, the injected data rewrites the query logic and enables authentication bypass, data extraction, or unauthorized directory modifications.

In theory, LDAP injection works on the same principle as SQL injection. The difference is the target. While SQL injection targets a database, LDAP injection targets directory services, like AD. These directory services usually controls who can access what across the entire organization, making LDAP injection vulnerability a high-stakes security issue.

How does an LDAP injection attack work?

Here is what a standard LDAP authentication filter looks like:

(&(uid=username)(password=userpassword))

In this filter, the application will use the credentials that the user provides. However, if an attacker enters a specially created input instead of a normal username, they can change the function of the filter.

For example:

Username input: admin)(&)

The resulting filter is: (&(uid=admin)(&))(password=anything))

The inserted, or injected, characters neutralize the password check. This allows the attacker to log in as an admin without even knowing the actual password. No brute force attack was done. No stolen credentials were used. All they needed was just a few characters and a vulnerability that was never checked.

LDAP injection examples

Here are a few examples of LDAP injection.

Authentication bypass

An application uses the following query to login:

(&(uid={username})(userPassword={password}))

The attacker then enters the following in the username field:

*)(uid=*))(|(uid=*

Now, the filter becomes:

(&(uid=*)(uid=*))(|(uid=*)(userPassword=anything))

Authentication is bypassed completely. Here is how:

LDAP filters use prefix notation, where special characters carry specific meanings. The asterisk (*) used in the username filed for this attack is a wildcard. This matches any value, and the parentheses are used to open and close the filter conditions. By injecting *)(uid=*))(|(uid=* into the username field, the attacker effectively closes the original uid condition early. It then appends a new condition using OR logic (|) that evaluates to true for any user. The password is never reached because the rewritten filter resolves to true before it even gets there. Valid credentials are no longer required.

Blind LDAP injection

Just like the name suggests, there is no visible output in a blind LDAP injection attack. In this case, the attacker submits payloads that produce true or false responses. These signals are then used to map out the directory (usernames, attributes, and structure), one character at a time. Though this process is slower, compared to the authentication bypass, blind LDAP injection is equally effective.

LDAP injection payloads

LDAP injection payloads are strings that attackers craft and use to manipulate the LDAP filter logic.

These LDAP injection payloads enable the attackers to exploit the prefix notation LDAP uses for filter logic. The LDAP filter syntax has special meanings for characters like (, ), *, and \. Leaving them unescaped lets attackers rewrite your queries.

During authorized penetration tests and security assessments, you can use various tools to test for LDAP injection vulnerabilities.

How to prevent LDAP injection

To prevent LDAP injection, escape special characters per RFC 4515, use safe LDAP query frameworks, and apply least privilege on service accounts.

1. Before any user input reaches the LDAP filter, escape special characters.
2. Use LDAP libraries that support safe query construction.
3. Define what a valid input looks like and reject everything else.
4. The LDAP service account that your application uses should have only the permissions it needs.
5. Require authentication for any and all LDAP queries.
6. Enforce LDAPS (port 636) to encrypt the LDAP traffic.
7. Keep an eye out any unusual patterns.

Other LDAP vulnerabilities: The bigger picture

LDAP injection is a serious threat, but it is not the only LDAP vulnerability that organizations need to be concerned about. Here are the other key LDAP vulnerabilities you should know about:

Anonymous binding

Anonymous binding occurs when an LDAP server is configured to accept queries without requiring any authentication. This means anyone who can reach the server over the network can query the directory and enumerate usernames, email addresses, group memberships, and organizational structure without providing a single credential.

This happens when the LDAP server's default configuration remains unchanged. Many older directory services ship with anonymous binding enabled out of the box, and administrators often do not disable it during setup.

To prevent this, explicitly disable anonymous binding on your LDAP server. Require all clients to authenticate before any query is processed, and audit your server configuration regularly to confirm the setting has not been reenabled.

Overly permissive ACLs

Access control lists (ACLs) define who can read or modify specific entries in the directory. When ACLs are too broad, regular users or service accounts can access sensitive attributes they have no business reason to view, such as password hashes, security group memberships, or privileged account details.

This typically happens through misconfiguration during setup or through permission drift over time, where access is granted for a temporary reason and never revoked.

To prevent this, apply the principle of least privilege to all directory entries. Audit ACLs periodically, remove any permissions that are no longer necessary, and use tools that can flag overly permissive entries automatically.

Weak credential policies

When an LDAP directory service does not enforce strong password requirements or account lockout policies, it becomes easy for attackers to run brute force or password spraying attacks against service accounts and user accounts alike.

This happens when credential policies are either not configured or set too loosely, for example, allowing short passwords, no complexity requirements, or unlimited failed login attempts.

To prevent this, enforce minimum password length and complexity requirements at the directory level. Set account lockout thresholds to block repeated failed attempts, and rotate service account credentials on a regular schedule.

Cleartext transmission

When LDAP traffic is sent over port 389 without STARTTLS or without upgrading to LDAPS, all communication between the client and the server travels in plaintext. This includes usernames, passwords, and any directory data returned in the response.

This happens when administrators rely on the default LDAP port without enforcing encryption, or when legacy applications do not support encrypted LDAP connections.

To prevent this, enforce LDAPS on port 636 or require STARTTLS on port 389. Block unencrypted LDAP traffic at the firewall and monitor your network for any plaintext directory queries.

LDAP Nightmare (CVE-2021-44142/related Windows LDAP vulnerabilities)

LDAP Nightmare refers to a class of critical vulnerabilities discovered in Windows LDAP implementations, most notably CVE-2024-49112, a remote code execution flaw in Windows LDAP that gained widespread attention. An unauthenticated attacker can send a specially crafted LDAP request to a vulnerable Windows domain controller and trigger a crash or execute arbitrary code, all without any credentials.

This happens because of flaws in how the Windows LDAP client or server processes certain incoming requests. Domain controllers are central to authentication across the entire organization, meaning a single successful exploit can give an attacker a foothold into the entire AD environment.

To prevent this, apply Microsoft's security patches promptly. Restrict inbound LDAP traffic from untrusted networks, monitor domain controllers for unexpected crashes or unusual LDAP traffic patterns, and follow Microsoft's hardening guidance for Active Directory.

Secure your Active Directory management with ADManager Plus

Managing LDAP and AD security across a large organization is rarely easy and straightforward. Misconfigurations will pile up, permissions will get out of hand, and gaps in visibility will create exactly the kind of exposure that LDAP injection attacks thrive on. ADManager Plus gives IT teams a centralized console to handle user provisioning, access control, and security reporting, without needing deep technical expertise or native AD tools. Enforce least-privilege access, audit directory permissions, and eliminate misconfigurations before attackers find them first.

FAQs

How is LDAP injection different from SQL injection?

Both exploit unsanitized input in query logic. LDAP injection targets directory services using LDAP filter syntax. SQL injection targets relational databases using SQL. LDAP injection is less well-known, which means it is more likely to go undetected during security audits.

What is blind LDAP injection?

Blind LDAP injection is a variant where the attacker cannot see direct query output. Instead, they infer directory information from the application's true or false responses.

Can LDAP injection affect cloud-based directory services?

Yes. Cloud-based directory services that use LDAP protocols are just as susceptible to injection attacks as on-premises deployments. Any application that constructs LDAP queries from un-sanitized user input is vulnerable, regardless of where the directory service is hosted.

How do I know if my application has already been exploited through LDAP injection?

Look for unusual authentication patterns in your directory service logs, such as successful logins with unexpected input strings, access to accounts outside normal business hours, or queries returning abnormally large result sets. Immutable logging and behavioral monitoring are key to catching exploitation early.