CVE-2025-24071 is one of those Windows bugs that looks boring until you read the trigger condition and realize no user interaction is required beyond extracting a zip file. Microsoft patched it in the March 2025 Patch Tuesday release, credited researcher 0x6rss, and rated it important rather than critical. The rating undersold the operational reality: a drive-by credential leak that fires when Windows Explorer auto-indexes a file it has not been told to open.
This post walks through what happens under the hood, why the bug existed, and what the cleanup looks like for organizations that still permit outbound SMB or run patchy Windows fleets.
What is CVE-2025-24071 and how bad is it really?
CVE-2025-24071 is a spoofing vulnerability in the way Windows Explorer handles .library-ms files that causes an outbound SMB authentication attempt to an attacker-controlled host, leaking the victim's NTLMv2 hash. The CVSS score of 7.5 is accurate for a credential exposure bug, but the exploitation floor is lower than that number suggests because no click, double-click, or preview action is needed. Explorer's file indexer processes the file as soon as it lands on disk, and extracting it from a zip is enough.
The leaked material is an NTLMv2 response, which is a hash of the user's password plus challenge data. That hash is not the password itself, but it is usable in NTLM relay attacks and can be cracked offline against weak or predictable passwords. In Active Directory environments with fast hardware and a decent wordlist, a significant fraction of user accounts fall to offline cracking within hours.
The vulnerability affects Windows 10, Windows 11, and Windows Server versions current as of March 2025. Microsoft's patch addresses the Explorer parsing path; there is no registry-only mitigation that fully closes the issue without breaking expected behavior.
What is a .library-ms file and why does Explorer trust it?
A .library-ms file is an XML document that defines a Windows Library - the virtual folder concept that lets a user aggregate content from multiple filesystem paths under a single name. The format has existed since Windows 7 and contains elements that specify search connectors, folder references, and icons. The searchConnectorDescription element supports a simpleLocation url child, and that element is where the bug lives.
When Explorer sees a .library-ms file in a folder it is rendering, the indexer resolves the URLs contained in the file to generate thumbnail and metadata context. If a URL points to an SMB share, Windows opens an authenticated SMB connection to that host as part of the resolution process. The authentication uses the logged-in user's credentials automatically, which is the design intent for legitimate libraries pointing at corporate file servers.
The exploit is to craft a .library-ms file whose simpleLocation url points at an attacker-controlled SMB server, pack it in a zip alongside other decoy content, and send the zip to a target. When the target extracts the zip, Explorer's indexer touches the .library-ms file, and the NTLM authentication fires at the attacker's server. The attacker captures the NTLMv2 response using responder, impacket, or any off-the-shelf SMB listener.
How does the exploit chain work in a real campaign?
The exploit chain works by landing a zip archive on the victim's machine via phishing, web drive-by, or shared drive, and waiting for the user to extract it. No further interaction is required. Campaigns observed in the wild after disclosure used three main delivery vectors:
- Phishing emails with invoices or shipping documents as
.zipattachments. The.library-msfile is hidden among benign-looking.pdfor.xlsxfiles to reduce scrutiny. - Legitimate file-sharing services where an attacker uploaded a zip claiming to be a template or document pack.
- Watering-hole compromises on low-traffic B2B sites, serving zips as "case study downloads."
The attacker's SMB listener receives the NTLMv2 hash, and from there the attacker has two usable paths. Path one is offline cracking, which is effective against weak passwords and remains the dominant abuse pattern in criminal campaigns. Path two is NTLM relay, where the attacker simultaneously connects to a service the victim has access to - typically a file server, a certificate authority, or an LDAP endpoint - and relays the authentication to gain access as the victim.
For high-value targets, relay is the preferred use because it does not require cracking and it bypasses password complexity requirements entirely. CISA's advisory on NTLM relay, updated throughout 2024 and 2025, covers the mitigations in detail: SMB signing required, LDAP channel binding enforced, and Extended Protection for Authentication enabled on web services.
Why did Explorer trust remote URLs in library files without warning?
Explorer trusted remote URLs in library files because the original design treated library files as trusted configuration artifacts created by the user, not as untrusted content arriving from external sources. That assumption held in 2009 when libraries shipped. It stopped holding the moment email clients and browsers started extracting zips into user profile directories automatically.
This is a recurring class of Windows bug. The same structural issue caused CVE-2023-23397 (Outlook reminder sound files triggering SMB authentication), the 2022 .search-ms handling issues, and older variants involving .scf and .url shortcut files. In each case, a file type that once made sense as user-authored configuration became exploitable when arbitrary attackers could deliver it into Explorer's indexing path.
Microsoft's patch for 24071 removes the automatic URL resolution for the specific elements 0x6rss identified. It does not re-architect the file-type trust model, which means variant bugs in adjacent file types are likely. The broader fix - treating any file arriving via the Mark-of-the-Web as untrusted configuration - has been discussed in Windows security circles for years without a full rollout.
What does detection look like for this bug?
Detection looks for outbound SMB traffic from workstations to external hosts, which is almost always suspicious on enterprise networks. The specific indicator is a TCP connection on port 445 from a user workstation to an IP address outside the internal RFC 1918 space and outside any known file-sharing vendors.
If you already block outbound SMB at the perimeter, the attack fails quietly because the authentication attempt never reaches the attacker. That firewall rule is recommended in every Windows hardening guide published in the last decade, and the Patch Tuesday advisory underlines it. The organizations that got burned were ones where remote workers hit the internet directly without routing through a corporate egress point.
Endpoint telemetry worth reviewing:
- Sysmon Event ID 3 (network connect) for
explorer.exeorsearchindexer.exeto external port 445. - Unexpected
.library-msfiles in user profileDownloadsorTempdirectories. - Archive extraction events followed within seconds by outbound SMB.
Falcon, Defender for Endpoint, and most major EDRs shipped detections within the patch cycle. Self-hosted Sysmon configurations need the relevant rules added manually.
What compensating controls hold up against the next variant?
Compensating controls that hold up against the next variant of this bug class are outbound SMB blocking, NTLM relay mitigations at authentication targets, and reducing the use of NTLM itself. Specifically:
- Block outbound TCP 445 at the perimeter for every workstation segment. There is no legitimate reason for a user laptop to connect to a random internet SMB server.
- Enforce SMB signing on all domain-joined systems. A signed SMB session cannot be relayed even if the NTLM hash leaks.
- Enable Extended Protection for Authentication on LDAPS, AD CS web endpoints, and any internal web service that accepts Windows Integrated Authentication. This closes the HTTP-to-LDAP relay chain that remains the most dangerous outcome of these leaks.
- Prefer Kerberos for intranet authentication and audit for lingering NTLM usage using the NTLM auditing events in Windows Server. Accounts that never use NTLM legitimately should have NTLM disabled.
- Treat file-extension handlers as a hardening surface. Remove or neuter handlers for
.library-ms,.search-ms,.scf, and similar legacy types on workstations that do not use them.
Cleanup is rarely one-shot. Any organization that extracted untrusted zips during the vulnerability window should assume some NTLM hashes leaked and rotate affected user passwords, especially for privileged accounts.
How Safeguard.sh Helps
Safeguard.sh reachability analysis prioritizes CVE-2025-24071 against your actual workstation exposure - whether outbound SMB is blocked, which Windows builds are deployed, which users handle untrusted archives - and filters out hosts where the exploitation path is already closed, trimming CVE noise by 60 to 80 percent. Griffin AI autonomous remediation queues the relevant Windows updates, applies egress rules, and tracks patch completion across the fleet without hand-cranked WSUS policies. Eagle malware classification fingerprints the phishing loaders and SMB responder tooling used in follow-on campaigns, SBOM coverage with 100-level dependency depth surfaces third-party software that may also invoke vulnerable file handlers, container self-healing keeps the Windows-based build agents clean, and TPRM extends the same visibility to vendors whose endpoints touch your authentication fabric.