Technical Explanation of NTLM Hash Leak via RAR/ZIP Extraction and .library-ms File
When a specially crafted .library-ms file containing an SMB path is compressed within a RAR/ZIP archive and subsequently extracted, Windows Explorer automatically parses the contents of this file due to its built-in indexing and preview mechanism. This behavior occurs because Windows Explorer processes certain file types automatically upon extraction to generate previews, thumbnails, or index metadata, even if the file is never explicitly opened or clicked by the user.
The .library-ms file format is XML-based and is trusted by Windows Explorer to define search and library locations. Upon extraction, the indexing service and Explorer’s built-in file parsing mechanism immediately analyze the .library-ms file content to render appropriate icons, thumbnails, or metadata information.
The provided file contains a <simpleLocation> tag pointing directly to an attacker-controlled SMB server:
Upon extraction, Windows Explorer attempts to resolve this SMB path (\\192.168.1.116\shared) automatically to gather metadata and index file information. This action triggers an implicit NTLM authentication handshake from the victim's system to the attacker-controlled SMB server. Consequently, the victim's NTLMv2 hash is sent without explicit user interaction.
This vulnerability arises because Windows Explorer implicitly trusts .library-ms files and automatically processes certain file types immediately upon their extraction from archives. Attackers exploit this implicit trust and automatic file processing behavior to leak credentials, which can then be utilized for pass-the-hash attacks or offline NTLM hash cracking.
Automatic File Processing Observations
Using Procmon, we can clearly observe that immediately after extracting the .library-ms file, the following operations are executed automatically by Explorer.exe and indexing services such as SearchProtocolHost.exe:
- CreateFile: The file is opened by Explorer automatically.
- ReadFile: File contents are read to extract metadata.
- QueryBasicInformationFile: Metadata queries performed.
- CloseFile: File is closed after processing.
Additionally, SearchProtocolHost.exe is invoked as part of Windows' file indexing service. After Explorer.exe finishes its initial processing, the indexing service reopens and reads the file to index its contents. This further confirms the automated handling of files upon extraction:
- CreateFile, ReadFile, QueryBasicInformationFile, CloseFile: Performed by SearchProtocolHost.exe to add file content into the search index.
These actions conclusively demonstrate that Windows automatically processes files immediately upon extraction, without any explicit user interaction. Both Explorer.exe and SearchProtocolHost.exe automatically read and process the XML content of the .library-ms file, initiating a connection attempt to the SMB path embedded within.
procmon process
SMB Communication Evidence
Using Wireshark with an SMB filter (smb or smb2), you can directly observe that the extraction of the malicious .library-ms file immediately triggers SMB communication attempts. Wireshark captures reveal the following sequence of SMB packets:
- SMB2 Negotiate Protocol Request: From the victim to the attacker-controlled server (192.168.1.116).
- SMB2 Session Setup Request (NTLMSSP_AUTH): Clearly showing the initiation of an NTLM authentication handshake, proving that Windows automatically tries to authenticate with the SMB server upon file extraction.
wireshark process
Even if the file is moved to the trash, it will still remain functional and continue to work.
Exploitation in the Wild
This vulnerability is actively being exploited in the wild and has potentially been offered for sale on the xss forum by the threat actor known as "Krypt0n."(This is a possibility. The security vulnerability hinted at by the threat actor aligns with this logic.) This threat actor is also the developer of the malware named "EncryptHub Stealer (ref: https://x.com/naumovax/status/1900574511797239900)."
forum posts:
Translation from Russian for the threat actor's post:
Let me clarify everything. The server where the hashes are sent is created locally, for example, on a VPS. Then, using an exploit, you generate a config with your IP, share, etc. After that, a special config is created. You place it on a shared folder anywhere—it doesn't matter where exactly. If the user simply opens Explorer or accesses the shared folder, an automatic redirect occurs (the request is redirected), and the user's hash is sent to your server. That's it. The file placed in the shared folder does not need to be opened.
Check the PoC for this vulnerability.
https://github.com/0x6rss/CVE-2025-24071_PoC
NOTE
I reported this vulnerability to Microsoft, and it was already fixed in the March release (Patch Tuesday).
CVE-2025-24071 - More details:
CVE-2025-24071/Microsoft Windows File Explorer Spoofing Vulnerability
Update: Microsoft has changed its CVE number. The CVE number previously defined by Microsoft, CVE-2025-24071, has been updated to CVE-2025-24054.🤷♂️
