Eric Woodruff Senior Security Researcher

LDAPNightmare, recently published by SafeBreach Labs, is a proof-of-concept exploit of a known Windows Lightweight Directory Access Protocol (LDAP) denial-of-service vulnerability (CVE-2024-49113). What is LDAPNightmare, how dangerous is this exploit, and how can you detect and defend against it?

What is LDAPNightmare?

The December 2024 Windows update – published by Microsoft on December 10, 2024, noted two LDAP vulnerabilities: CVE-2024-49112 and CVE-2024-49113. CVE-2024-49113 is a denial-of-service vulnerability; CVE-2024-49112 is remote code execution (RCE) vulnerability.

The security researcher who found these vulnerabilities, Yuki Chen, has not publicly disclosed details that would lead to abuse. However, on January 1, 2025, SafeBreach Labs published its own research. Named LDAPNightmare, this working proof-of-concept abuses the denial-of-service vulnerability CVE-2024-49113.

Using LDAPNightmare, an attacker can coerce a domain controller (DC), acting as an LDAP client, to send an LDAP request to a malicious server. That server can then send a crafted response that causes a Windows host, such as a DC, to crash.

Note that the exploited vulnerability is not specific to Active Directory. Any Windows host can fall victim to LDAPNightmare abuse. However, the high-value nature of Active Directory makes the identity service a prime target.

An LDAPNightmare exploit involves the following flow (Figure 1):

  1. An attacker sends a Distributed Computing Environment/Remote Procedure Call (DCE/RPC) request to a victim DC.
  2. The request triggers the victim DC to send a DNS SRV query to a DNS domain that the attacker controls.
  3. The attacker-controlled DNS responds with SRV records that resolve to the hostname of a malicious host.
  4. The victim DC broadcasts a NetBIOS name request to resolve the hostname of the malicious host.
  5. The malicious host replies with its IP address.
  6. The victim DC, having resolved the host, acts as an LDAP client and sends a CLDAP request to the malicious host.
  7. The malicious host, controlled by the attacker, provides a response that is crafted to cause an integer overflow in the LDAP client library on the victim DC, causing Windows to crash.
Figure 1. LDAPNightmare exploit flow

The entire walkthrough of SafeBreach Lab’s research can be found at LDAPNightmare: SafeBreach Publishes First PoC Exploit (CVE-2024-49113). So far, no public disclosures exist regarding abuse of CVE-2024-49112.

How can you defend your environment against LDAPNightmare?

To defend against potential denials of service from LDAPNightmare, organizations should patch their DCs, Tier 0 estate (e.g., AD FS and AD CS servers), and critical Windows hosts as soon as possible. The December 2024 Windows Patch Tuesday updates contain the necessary patches to protect against the vulnerabilities in both CVEs.

The following table displays information published by the Microsoft Security Response Center (MSRC) regarding the available patches for CVE-2024-49113.

Operating systemInstall typeKnowledge Base article
Windows Server 2016Full and server coreKB5048671
Windows Server 2019Full and server coreKB5048661
Windows Server 2022Full and server coreKB5048654
Windows Server 2022Full and server core, hotpatchedKB5048800
Windows Server 2025Full and server coreKB5048667
Windows Server 2025Full and server core, hotpatchedKB5048794
Table 1. Microsoft Knowledge Base articles for CVE-2024-49113 patches

You can find full details of the updates available for all Windows versions (client and server) at CVE-2024-49113 – Security Update Guide – Microsoft – Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability.

A word of caution regarding other mitigations

The MSRC publication regarding CVE-2024-49112 recommends the following mitigations:

Ensure that domain controllers are configured either to not access the internet or to not allow inbound RPC from untrusted networks. While either mitigation will protect your system from this vulnerability, applying both configurations provides an effective defense-in-depth against this vulnerability.

Unfortunately, MSRC does not provide actionable steps for these mitigations, and the guidance regarding RPC limitations could be problematic if misinterpreted.

  • Tier 0 systems should never have unfettered access to the internet. Yet, certain Microsoft services require outbound connectivity to various Azure and M365 endpoints. These services generally support outbound connectivity through a proxy, but unless your organization already has a proxy in place for this traffic, you should prioritize patching your DCs over implementing new proxy services.
  • Enabling RPC restrictions can have negative consequences if implemented on DCs. Microsoft has published an article covering the potential fallout.
  • Most enterprises already have a process for testing Windows patches before rollout. Any RPC restrictions require equally extensive design and testing—time-consuming actions that are likely to divert resources from the critical patching of affected hosts.

Organizations may explore blocking RPC on a network layer. However, note that such blocking can disrupt Active Directory.

How can you detect LDAPNightmare?

How can you determine whether LDAPNightmare is a threat in your environment?

Check for patches

Patching is the primary route of defense, so the easiest method to determine whether Active Directory is protected from LDAPNightmare is to examine the status of the December 2024 Microsoft patches on your DCs. You can use the reporting capabilities of your patch-management platforms to determine this information. Alternatively, Semperis has written the following bit of PowerShell code, which you can use to evaluate the patch status of your DCs.

      param(
    [Parameter(Mandatory = $true)]
    [string]$CSVFilePath
)

$StatusList = @()

$DCList = @(get-addomaincontroller -Filter *)

foreach ($DC in $DCList) {
    $KBID = $null
    switch -Wildcard ($DC.OperatingSystem) {
        "Windows Server 2016*" { $KBID = "KB5048661" }
        "Windows Server 2019*" { $KBID = "KB5048661" }
        "Windows Server 2022*" { $KBID = "KB5048654" }
        "Windows Server 2025*" { $KBID = "KB5048667" }
    }

    Write-Progress -Activity "Checking domain controller" -Status $DC.HostName -PercentComplete $([float](([int]([array]::indexof($DCList,$DC)) + 1)/$DCList.Count) * 100)

    try {
        Get-HotFix -Id $KBID -ComputerName $DC.HostName -ErrorAction Stop | Out-Null 
        $StatusList += New-Object -TypeName psobject -Property @{Hostname = $DC.HostName; OS = $DC.OperatingSystem; KB = $KBID; State="Patched" }
    }
    catch [System.ArgumentException] {
        $StatusList += New-Object -TypeName psobject -Property @{Hostname = $DC.HostName; OS = $DC.OperatingSystem; KB = $KBID; State="Unpatched" }
    }
    catch [System.Runtime.InteropServices.COMException] {
        $StatusList += New-Object -TypeName psobject -Property @{Hostname = $DC.HostName; OS = $DC.OperatingSystem; KB = $KBID; State="Unreachable" }
    }
}

$StatusList | Export-CSV "$CSVFilePath\dclist$(get-date -f yyyy-MM-dd-HHmmss).csv" -NoTypeInformation

This PowerShell code checks each DC, respective to its operating system version for the appropriate hotfix, and then outputs the contents to a CSV file. If you are running Windows Server 2012 R2 or earlier or using hotpatching, you will need to update the switch statement as appropriate.

Note: This code requires remote access to and privileges on each DC, so run it only from a trusted Tier 0 device, such as a privileged access workstation (PAW).

Other detection methods

SafeBreach has indicated that LDAPNightmare could be used to determine whether a DC is vulnerable to CVE-2024-49113 exploitation. Yet this type of experiment would consist of knowingly crashing DCs, an act that is best avoided against a production directory service. As SafeBreach has indicated, and as we have verified in our own testing, the December 2024 Microsoft patches protect against integer overflow. Therefore, we recommend that organizations focus on inventorying which DCs and other Tier 0 hosts are missing the relevant patch.

SafeBreach also indicates that organizations can monitor for suspicious CLDAP referral responses, suspicious DsrGetDcNameEx2 calls, and suspicious DNS SRV queries. However, these types of network traffic would likely occur when an attack is already in effect against vulnerable hosts. At the speed at which this exploit works, you would be able to capture these events only moments before a targeted DC crashes.

If you notice a DC restarting, you can check the Windows Application log on the DC to determine whether LDAPNightmare is in play. First, look for Event ID 1000 with a Faulting application name of lsass.exe and a Faulting module name of WLDAP32.dll (Figure 2).

Figure 2. Event ID 1000

Then, look for a subsequent Event ID 1015 indicating that the critical process lsass.exe failed and that Windows must be restarted (Figure 3).

Figure 3. Event ID 1015

Semperis snapshot

LDAPNightmare is a recently published proof-of-concept exploit abusing CVE-2024-49113. The exploit has the potential to generate denial-of-service attacks against critical Windows systems, including DCs.

At this time, no attacks using LDAPNightmare are known to have occurred in the wild. However, an attacker could potentially use this exploit to build a system that could continually target and take down unpatched DCs, greatly affecting the availability of Active Directory. We will continue to update our resources on the vulnerability as research continues.

Additional reading