Unpacking LDAPNightmare (CVE-2024-49113 and CVE-2024-49112)

Active Directory is at the heart of most enterprise environments, making it a prime target for attackers and red teamers alike. With LDAPNightmare - two recently disclosed vulnerabilities in Windows LDAP - you now have the opportunity to explore denial-of-service attacks or even remote code execution (RCE) that could cripple an organization’s AD infrastructure.

Discovered by Yuki Chen and publicly disclosed in December 2024, CVE-2024-49112 and CVE-2024-49113 open the door to impactful exploits against vulnerable Windows systems, from crashing domain controllers to breaking authentication workflows.

And with millions of targets exposed online, this vulnerability is as widespread as it is critical.

CVEs under scrutiny:

👉 CVE-2024-49112 - Remote Code Execution vulnerability, 9.8 severity score
👉 CVE-2024-49113 - Denial of Service vulnerability, 7.5 severity score

While detailed technical details are available only for CVE-2024-49113, both vulnerabilities affect LDAP and the security community assumes they have a similar exploitation mechanism.

In this guide, we’re breaking down the mechanics of LDAPNightmare, exploring the Denial of Service scenario involving CVE-2024-49113, and showing you how to test for and mitigate these vulnerabilities in real-world engagements.

If you’re a pentester, this is your chance to catch up quickly and leverage LDAPNightmare for more comprehensive assessments.

If your task is to manage the attack surface of your organization, you know the stress of chasing down critical vulnerabilities. LDAPNightmare is no different - get the details now so you can effectively move (fast) to reduce your exposure and risk of exploitation.

Does LDAPNightmare affect my targets?

The CVE-2024-49113 attack works by sending a DCE request to the target server which will cause LSASS service to crash. This can result in an automatic reboot when the attacker delivers an especially crafted CLDAP referral response packet. As a consequence, servers and even domain controllers from the Active Directory network can be crashed.

This is not just a business disruption; for pentesters, targeting a domain controller means you can simulate the real-world impact of an AD outage. Crashing a domain controller disrupts critical operations like authentication, group policies, and resource access, providing a clear picture of how resilient an organization is against such attacks. This can also reveal weaknesses in incident response readiness or gaps in failover strategies. By demonstrating these vulnerabilities, you can help organizations strengthen their AD environment and mitigate costly downtime or reputation damage.

Now let’s get practical.

To achieve remote code execution, there are some conditions required:

RPC calls can be made from an unknown network
No checking on domains lookup
Allowing outbound UDP connections
LDAP is working.

When these conditions are met, the following Windows versions are known to be vulnerable at the time this article was written:

Windows versions	Vulnerable release
Windows 10	1809, 1903, 1909, 20H1, 20H2, 21H1, 21H2 , 22H2
Windows 11	21H2, 22H2, 23H2, 24H2
Windows Server	2008 R2, 2012, 2012 R2, 2016, 2019, 2022, 2025 R2 to 23H2

How many targets are vulnerable to LDAPNightmare?

By January 2025, according to Shodan.io, around 5,400,000 possible Windows targets are accessible using public IP addresses.

Also using censys.io, you can discover even more targets than with Shodan.io, around 11,385,000 - with more detailed information:

LDAPNightmare - root cause and technical details

The root cause of LDAPNightmare is in the LdapChaseReferral function.

In the patched version, an if condition validates that lm_referral has a smaller value than referral_table_size.

In the vulnerable version, lm_referral is used to access an offset inside the referral table, with the only prior check being that lm_referral is different from zero. However, any unauthenticated attacker can control lm_referral, which results in an out-of-bounds read that crashes LSASS and, with it, the entire operating system.

How to exploit LDAPNightmare

The flow of this exploit targeting LDAPNightmare is the following:

The attacker sends a DsrGetDcNameEx2 request to the target;
The target queries the domain it received in the request to find its DC (domain controller);
The DC's address is solved, if necessary;
The target performs an CLDAP query against the attacker’s machine;
The attacker’s machine responds with a malicious response which crashes the target.

Now let’s go into detail for each of these steps.

First, to perform this exploit, an attacker needs a domain with the following DNS SRV entries:

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.<domain_name>

_ldap._tcp.dc._msdcs.<domain_name>

These entries need to point to the attacker’s machine. Their values can be the IP address of the machine, a domain that resolves to that IP, or even a hostname - if the attack comes from the same network as the target.

The DsrGetDcNameEx2 function locates a domain controller (DC) for a specified domain and site based on the provided parameters, including account name, domain name, site name, and flags that define desired DC capabilities. It verifies DC compatibility, ensures the account exists (if specified), and returns detailed information about the DC it found.

This function has many arguments you can tweak. However, you can leave most of them set to their default values. The values you need to set are:

Account: must be set to a non-empty string, but you can use any username
Site Name: can be set to whatever too - you can just use an empty string
Domain Name: must use the domain created earlier.

This request will trigger the target machine to resolve the domain, by making a DNS query to _ldap.tcp.dc._msdcs.<our_domain> .

It will extract from the domain the target (which is a domain name) and a port, which it will use for the CLDAP request.

Because you used a domain name as a target, another DNS query is made to solve this domain name to an IP address.

Finally, the target sends a searchRequest CLDAP packet to the attacker.

The searchRequest is an LDAP message used to find directory entries matching specific criteria. It specifies the search base (location in the directory), scope (level of the directory tree to search), alias dereferencing policy, limits (size and time), return type (attribute types only or full values), search filter (criteria), and attributes to retrieve.

Responses include zero or more entries, referrals, and one completion message (SearchResultDone).

The parameters of the searchRequest message are irrelevant, as you control the LDAP server to which it was sent, and can respond with anything you want.

One possible response to a searchRequest is a "referral message". The server responds with a searchResDone message with the “referral” LDAP result code (equals 10). The response must also include valid LDAP URLs (starts with “ldap://” or “ldaps://”).

Referrals enable an Active Directory tree to be divided across multiple LDAP servers. If an LDAP server cannot fulfill a request, it can respond with referrals to other servers that might have the requested information. The client can then follow these referrals and query the referred servers. It’s worth noting that a client is not required to follow referrals, but in this case, it does.

As previously mentioned, the root cause of the vulnerability is an out-of-bounds read in the LdapChaseReferral function, which is linked with the behaviour explained above.

The referral_table_size is equal to zero for our interaction. However, if we manage to make lm_referral have a value bigger than 0, we can trigger the crash. The code below shows how lm_msgid and lm_referral get their values.

value_from_response_packet = value_from_response_packet2;
a2-›lm_referral = (unsigned int) value_from_response_packet2 >> 25;
a2-›lm_msgid = value_from_response_packet & 0x1FFFFFF;

To set a non-zero value for lm_referral, you need to change the byte that represents the length of “value_from_response_packet” (combination of lm_referral and lm_msgid) to 4 instead of 1.

Now “value_from_response_packet” is 4 bytes long, and you can set the most significant byte from it, which will affect lm_referral. Keep in mind that you can set this byte only to a value that can be divided equally by 2, or otherwise, it affects the value of lm_msgid.

Now, you can build an especially crafted CLDAP message that will trigger the vulnerability. The actual referral domain is not relevant and can be set to any random string.

LDAPNightmare proof of concept

To exploit this vulnerability, the original POC, which SafeBreach Labs published, did most of the hard work. As an ethical hacker, all you need to do is set up a domain name that points to a machine in your control.

LDAPNightmare exploit proof of concept - Denial of Service with CVE-2024-49113

Patching and mitigating CVE-2024-49113 and CVE-2024-49112

Microsoft addressed these vulnerabilities in December 2024 in their monthly Patch Tuesday release.

Because the LDAPNightmare exploit uses DNS and RPC queries from untrusted networks, Microsoft recommended in their MSRC publication that users should:

ensure that domain controllers are configured either to not access the internet or to not allow inbound RPC from untrusted networks.

However, effectively blocking internet traffic or implementing RPC restrictions could cause problems on some systems (especially those dependent on outbound connections).

The best mitigation would be updating all Windows hosts, as well as their Domain Controllers and Tier 0 servers (AD FS and AD CS).

Users can determine if their system is vulnerable by using patch management services or by effectively analyzing any suspicious network traffic (especially unusual DNS queries) and monitoring their Domain Controller events.