CVE-2025-24054 is a NTLM hash disclosure spoofing vulnerability in Microsoft Windows. CISA added it to the Known Exploited Vulnerabilities catalogue on 17 April 2025, which means attackers have used it in real attacks. Microsoft Windows NTLM contains an external control of file name or path vulnerability that allows an unauthorized attacker to perform spoofing over a network.
What this vulnerability means in Windows environments
CVE-2025-24054 is dangerous because it sits in NTLM, a legacy authentication path that many Windows environments still support for compatibility. When an attacker can trigger NTLM hash disclosure through spoofing, they may gain material authentication material without needing a password in clear text, which can undermine trust in networked Windows workflows.
That makes the issue more than a simple application bug. It is a disclosure flaw that can become an access problem, because exposed NTLM material may be reused for lateral movement, relay-style abuse, or follow-on authentication attacks if the environment still accepts NTLM broadly.
How organisations confirm exposure
The first question is whether the vulnerable Windows systems are present anywhere in the estate, including workstations, servers, remote users, and internet-facing endpoints. Asset inventory matters because the exposed surface is often broader than the device an admin initially suspects.
Exposure review should also check whether the affected systems can be reached from untrusted networks and whether users or services still rely on NTLM for inbound or outbound authentication. Vendor guidance and the CVE Program record help with identification, while the NIST National Vulnerability Database remains the standard reference point for structured vulnerability tracking.
Remediation and compensating controls
Where patching is not yet complete, compensating controls should reduce both initial exposure and the value of any leaked NTLM material. Limiting NTLM use, reducing external reachability, tightening segmentation, and constraining where authentication material can travel are all practical ways to narrow the blast radius.
Because this class of issue is exploitation-relevant, remediation should be treated as an asset-wide activity rather than a single-host fix. The safest posture is to remove unnecessary NTLM dependencies over time and to align the response with the Windows hardening guidance already in place for privileged paths and legacy authentication.
Detection and identity impact after exploitation
Detection work should look for unusual authentication events, suspicious network-originated file or path interactions, and signs that NTLM material was harvested or replayed after the initial disclosure. A successful attack may not look like classic malware delivery at first, so logging and correlation across endpoints, identity services, and network telemetry are important.
If exploitation is suspected, the identity impact can be significant even without direct account takeover at the outset. Review whether NTLM-derived material, sessions, cached credentials, or adjacent service accounts need rotation or invalidation, and verify whether the attacker used the disclosure only as a foothold or as a path to broader access.
Risk and Threat Considerations
This vulnerability is risky because NTLM disclosure can turn a single spoofing event into reusable authentication material, especially in environments that still depend on legacy Windows authentication. That creates a practical path from disclosure to impersonation, relay, or lateral movement.
Failure mechanism: An attacker triggers the Windows flaw, extracts NTLM hash material, and then uses that material to impersonate or authenticate as the victim in downstream network activity.
Impact: The result can be unauthorized access, credential reuse, lateral movement, and broader compromise of Windows accounts or services that still accept NTLM.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | NTLM disclosure affects account access and lifecycle control. |
| Recommendation — Reduce NTLM exposure by tightening account use, access scope, and legacy authentication dependencies. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Leaked NTLM hashes are authenticator material that can be abused after disclosure. |
| IA-2 — Identification and Authentication (Organizational Users) | The flaw weakens Windows user authentication pathways. | |
| SC-7 — Boundary Protection | Network spoofing and disclosure risk increase where legacy auth crosses trust boundaries. | |
| Recommendation — Rotate or invalidate exposed authenticators and restrict where legacy credentials can be used. Enforce stronger user authentication paths and reduce reliance on legacy NTLM flows. Segment exposed Windows systems and limit network paths that can trigger legacy authentication. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | NTLM hash material is sensitive authentication data whose protection and handling matter. |
| Recommendation — Treat leaked authentication material as sensitive and constrain its exposure and reuse. | ||
Practitioner Guidance
Why practitioners should care: Treat this as an authentication-material exposure issue, not just a patching task. The operational question is whether the environment still allows NTLM to matter enough that leaked hashes can be used after the initial event.
What to watch for: Look for legacy authentication dependencies, exposed endpoints, and accounts or services that would still accept NTLM if an attacker obtained it. The more broadly NTLM remains enabled, the more valuable the disclosure becomes to an adversary.