Microsoft is urging Windows administrators to patch a critical improper authentication vulnerability in NT LAN Manager (NTLM) that allows an authenticated attacker to elevate privileges over a network. The flaw, tracked as CVE-2025-54918 in the Microsoft Security Response Center (MSRC) advisory, lets a low-privileged user trigger an authentication flow that can be manipulated to gain higher access rights on a target system—without the need for memory corruption or complex exploit chains.

Security researchers and incident responders have already flagged this class of bug as high-priority because of how easily it can be wedged into real-world attack chains. With NTLM still deeply embedded in enterprise Windows environments, organizations that delay patching risk exposure to credential theft, lateral movement, and full domain compromise. The advisory lands in a year already crowded with NTLM-related incidents, including several actively exploited hash-disclosure flaws and relay attacks.

What the advisory says

The core vulnerability, described as “improper authentication” in NTLM, enables an authorized attacker to elevate privileges over a network. Microsoft’s MSRC entry for CVE-2025-54918 is the definitive source for affected software versions, corresponding KB numbers, and remediation status. However, independent researchers note that multiple NTLM advisory identifiers have surfaced in public indexes, including CVE-2025-53778 and CVE-2025-24054, all pointing to the same family of authentication logic issues. Defenders should cross-reference the official MSRC update guide for their specific OS builds to confirm the exact KBs, as the MSRC page requires client-side rendering and may not be fully indexed by third-party scanners.

The practical impact is stark: any network-authenticated user could exploit this weakness to obtain SYSTEM-level access on a remote machine, move laterally across domain resources, or capture NTLM hashes for offline cracking. Because the attack requires only minimal user interaction—such as previewing a file or selecting an icon in Explorer—the exposure surface is broad and deeply concerning for any environment where NTLM is still permitted.

Why NTLM remains a target

NTLM is a legacy authentication protocol that Windows retains for backward compatibility with older servers, appliances, and third-party applications. Despite Microsoft’s long push toward Kerberos and modern authentication, NTLM persists in many enterprises because of hardcoded dependencies in line-of-business software, print servers, and network-attached devices. This lingering footprint keeps the attack surface alive.

Over the last eighteen months, threat actors have consistently targeted NTLM with a stream of flaws:
- Hash disclosure vulnerabilities that leak NTLM challenge-response data to attacker-controlled SMB shares simply by extracting an archive or clicking a link.
- Relay attacks that exploit missing SMB signing to forward authentication responses and impersonate users.
- Logic bugs that confuse the NTLM state machine into granting elevated tokens.

In several campaigns documented by security vendors, phishing emails delivering .rar or .zip archives triggered automatic NTLM authentication to rogue servers, giving attackers a foothold in minutes. The advisory for CVE-2025-54918 must be read against this backdrop: weaponization will likely follow disclosure within days, if it hasn’t already begun.

Technical breakdown: how improper authentication unfolds

When Microsoft categorizes a flaw as “improper authentication,” the underlying failure typically involves one of these weaknesses:

  • Identity binding mismatch: Server-side code fails to verify that the principal shown in the session matches the expected account, allowing an attacker to assume a different context.
  • Unintended authentication flows: External inputs—a file name, a shortcut, a search connector—cause the operating system to initiate an NTLM negotiation with an attacker’s SMB endpoint, leaking the user’s hash. This mechanism has been exploited in numerous hash-disclosure vulnerabilities.
  • Protocol state machine errors: Mistakes in the challenge-response handshake enable an attacker to downgrade security, inject crafted responses, or force the client to reveal credentials meant for a higher-privileged session.
  • Service-side authorization gaps: A network service that accepts NTLM but fails to properly restrict privileged actions can be abused by any authenticated user to perform administrative operations.

In the case of CVE-2025-54918, the advisory’s wording points toward a logic error that allows privilege escalation directly over the network. An attacker who has already gained a foothold—via a phishing lure, a compromised local account, or a malicious SMB share—can trigger the vulnerability to jump from low-privilege access to SYSTEM. This shortcut bypasses the need for additional local exploits and dramatically accelerates the path to domain dominance.

Realistic attacker workflows

Attackers rarely use NTLM bugs in isolation. The following patterns are already common in the wild:

  1. Phishing → hash capture → relay
    A user opens a phishing email containing a malicious .zip or .lnk file. Explorer attempts to authenticate to an attacker-controlled SMB server, sending the user’s NTLMv2 hash. The attacker either cracks the hash offline or relays it to a service that will accept the authentication, gaining access to that server as the victim. If the victim has administrative privileges anywhere in the domain, the attacker quickly escalates.

  2. Low-privileged user on a domain workstation → malicious share → SYSTEM escalation
    An authenticated domain user (even a guest) navigates to a malicious network share or clicks a crafted URI. The client initiates an NTLM authentication flow that a specially crafted server can manipulate, exploiting the improper authentication bug to return a token that grants SYSTEM on the local machine. From there, credential harvesting and lateral movement are straightforward.

  3. Chained exploits
    NTLM flaws serve as the initial entry vector, yielding credentials or local elevation. The attacker then uses a secondary vulnerability—such as a kernel privilege escalation in AFD.sys or the DirectWrite graphics component—to gain persistence and move deeper into the network. This composition of patches-together exploits is why monthly Patch Tuesday updates often combine fixes for NTLM, kernel, and browser bugs.

Enterprise impact and exploitability

The blunt assessment from incident response teams is that network-triggerable NTLM vulnerabilities have a small window between disclosure and weaponization. Proof-of-concept code often surfaces on GitHub within 48 hours of a patch release, and commercial threat actors integrate new exploits into their toolkits rapidly. The Common Vulnerability Scoring System (CVSS) rating for this class of flaw is typically high—8.1 or above—reflecting low attack complexity and high impact on confidentiality, integrity, and availability.

For organizations that have not yet disabled NTLMv1 or enforced SMB signing, the risk multiplies. An attacker who relays NTLM authentication to a domain controller can potentially create golden tickets if the target lacks Extended Protection for Authentication. Even environments that have moved largely to Kerberos often retain NTLM fallbacks; a single misconfigured server or legacy application can be the weak link that enables compromise.

Immediate mitigation and hardening steps

While patching is the first and most critical action, multiple layers of defense should be applied immediately to reduce exposure while testing and rolling out updates.

1. Apply the official patch

Access the MSRC Security Update Guide for CVE-2025-54918, identify the KB article for your Windows version and edition, and deploy via your standard update management pipeline. For Windows Server 2022, Windows 11, and Windows 10, the patches will be delivered through Windows Update and WSUS. Validate installation by checking the KB number in Add/Remove Programs.

2. Block outbound NTLM traffic

If patching cannot happen immediately, configure perimeter and host firewalls to block outbound SMB (TCP port 445) and NetBIOS (ports 137-139) from all user subnets and workstations to the internet. This prevents clients from initiating NTLM exchanges with attacker-controlled servers. On internal networks, restrict SMB access to trusted file servers only, and deny client-to-client SMB flows.

3. Harden NTLM configuration

  • Disable NTLMv1 by setting the Group Policy “Network security: LAN Manager authentication level” to “Send NTLMv2 response only. Refuse LM & NTLM” (level 5). Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
  • Enforce SMB signing on all domain members. Set “Microsoft network client: Digitally sign communications (always)” to Enabled, and do the same for “Microsoft network server: Digitally sign communications (always).” This makes relay attacks far more difficult.
  • Enable EPA (Extended Protection for Authentication) on IIS and other web services that use Windows authentication to bind tokens to the correct TLS channel.

4. Identity protections

  • Require Multi-Factor Authentication (MFA) for all administrative access, remote desktop sessions, and privileged identity management tools. Even if an NTLM hash is stolen, MFA prevents the attacker from logging in interactively.
  • Deploy Windows Defender Credential Guard on capable hardware. This uses virtualization-based security to isolate credential material, making it impossible for attackers to extract hashes from memory.

5. Monitor and hunt for exploitation attempts

SOC teams should deploy the following high-priority detections immediately:
- SIEM query for outbound NTLM authentications: Look for Windows Event ID 4624 with AuthenticationPackageName = “NTLM” where the source workstation sends traffic to an IP outside the corporate IP space. Cross-reference with firewall logs for outbound TCP/445.
- Endpoint telemetry: Alert on processes like explorer.exe, dllhost.exe, or svchost.exe initiating SMB connections to untrusted destinations.
- Lateral movement patterns: Monitor for new NTLM authentications to previously unseen hosts, especially if followed by service creation (Event ID 7045) or scheduled task creation (Event ID 4698) under privileged accounts.
- Network detection: Watch for SMB protocol negotiation frames containing NTLMSSP challenges or responses directed to rare external IPs. Threat intelligence feeds can enrich these alerts.

Patching playbook for IT teams

Roll out the update in a phased manner to minimize disruption while prioritizing the most exposed systems.

  • Inventory phase (Day 0): Identify every Windows system that accepts NTLM authentication—domain controllers, file servers, SQL servers, and legacy appliances. Map them to the KBs listed in the MSRC advisory.
  • Pilot group (Day 1): Deploy to a small set of non-critical servers and select user workstations. Validate that core business applications, especially those relying on file shares or legacy ERP systems, continue to function normally.
  • Priority rollout (Days 1–3): Patch domain controllers, DNS servers, certificate authorities, and any machine that processes untrusted content—mail transfer agents, document converters, and web proxies. These are the high-value targets in most attack chains.
  • Broad deployment (Days 4–7): Push the update to all remaining endpoints and servers during the next maintenance window.
  • Post-patch validation: Re-run the SIEM hunts to ensure that anomalous NTLM flows have ceased. Verify SMB signing and LmCompatibilityLevel settings across the estate using Group Policy Results reports.

The bigger picture: moving away from NTLM

Every NTLM vulnerability adds urgency to long-standing migration efforts. Microsoft has been clear that NTLM is deprecated in favor of Kerberos and modern authentication protocols like OAuth and certificate-based authentication. Administrators should inventory all NTLM dependencies in their environment—using tools such as the Microsoft Assessment and Planning (MAP) Toolkit or third-party audit scripts—and start decommissioning where possible. For services that absolutely require NTLM, segment them into isolated network zones with strict access controls and aggressive monitoring.

Conclusion

The NTLM improper authentication flaw described in CVE-2025-54918 (and its sibling advisories) is a textbook example of why legacy protocol baggage continues to haunt enterprise security. An attacker who can trick a user into minimal interaction can turn that foothold into system-level control, and the tools to do so are already circulating. Patching within a 24-hour window is the single most effective defense, but it must be backed by network restrictions, NTLM hardening, and proactive threat hunting. Windows admins who treat this patch as just another Tuesday update risk learning the hard way that NTLM’s attack surface remains as dangerous as ever.