The File Explorer preview pane in Windows has been deliberately neutered for internet-downloaded files after security researchers and Microsoft found a practical way for preview handlers to coax NTLM authentication material out of a running system — a low‑interaction path that could leak NTLM hashes to attacker-controlled servers and enable relay or offline cracking attacks. This behavior change, rolled out as part of October 2025 security updates, is a defensive stopgap: it reduces a high-risk attack surface immediately but creates real usability headaches for users and organizations that rely on quick preview triage.
Microsoft ships legacy support for NT LAN Manager (NTLM) because many enterprise services and appliances still accept it. NTLM’s challenge/response primitives are not as strong as Kerberos; captured NTLM artifacts — particularly NTLMv2 challenge/response blobs — can be reused in relay attacks or subjected to offline cracking attempts. Over 2025, security researchers documented multiple ways that Windows Shell and preview handling could be induced to resolve remote UNC/SMB resources during routine UI actions, thereby triggering automatic NTLM authentication to attacker hosts. Those findings precipitated a sequence of patches and, ultimately, the October change to Explorer’s preview policy.
The immediate observable result for end users: when a file downloaded from the internet still carries the Mark‑of‑the‑Web (MoTW) Zone.Identifier tag, File Explorer will no longer hand the file to preview handlers. Instead, the Preview pane shows a warning message: “The file you are attempting to preview could harm your computer. If you trust the file and the source you received it from, open it to view its contents.” That protection can be reversed on a per‑file basis (Properties → Unblock) or targeted by enterprise zone/trusted‑site configuration, but Microsoft designed the default behavior to block a broad class of preview‑triggered credential leaks.
This practical change reflects a broader, well‑documented attack class: specially crafted files (LNKs, library manifest files, archives containing metadata, or documents with embedded external references) can cause File Explorer or in‑process preview handlers to resolve external resources automatically; when those resources are hosted on attacker‑controlled servers, a Windows client may perform NTLM authentication and leak negotiable material. Several researchers and vendors reproduced bypasses and assigned CVE IDs to successive bypasses, prompting Microsoft to harden behavior while further fixes are developed.
For everyday users: install the October 2025 updates, use the Properties → Unblock UI for files you trust, and treat the Preview pane warning as a deliberate protective cue. For administrators: treat this as an opportunity to inventory NTLM usage, harden authentication and egress controls, and adopt scripted, auditable unblocking workflows only for verified sources. The hard work remains: over time, remove NTLM dependence, enforce SMB signing, and tighten detection so that convenience never again becomes an easy path for credential leakage.
Note: user‑facing guides and community write‑ups (including the article you provided) summarize the same mitigation steps and practical workarounds; consult vendor KBs, research writeups, and your organization’s change control before making broad changes to zone or attachment policies.
Source: Make Tech Easier Windows File Explorer Previews are Vulnerable to NTLM Hash Leakage – How to Stay Safe - Make Tech Easier
Background / Overview
Microsoft ships legacy support for NT LAN Manager (NTLM) because many enterprise services and appliances still accept it. NTLM’s challenge/response primitives are not as strong as Kerberos; captured NTLM artifacts — particularly NTLMv2 challenge/response blobs — can be reused in relay attacks or subjected to offline cracking attempts. Over 2025, security researchers documented multiple ways that Windows Shell and preview handling could be induced to resolve remote UNC/SMB resources during routine UI actions, thereby triggering automatic NTLM authentication to attacker hosts. Those findings precipitated a sequence of patches and, ultimately, the October change to Explorer’s preview policy. The immediate observable result for end users: when a file downloaded from the internet still carries the Mark‑of‑the‑Web (MoTW) Zone.Identifier tag, File Explorer will no longer hand the file to preview handlers. Instead, the Preview pane shows a warning message: “The file you are attempting to preview could harm your computer. If you trust the file and the source you received it from, open it to view its contents.” That protection can be reversed on a per‑file basis (Properties → Unblock) or targeted by enterprise zone/trusted‑site configuration, but Microsoft designed the default behavior to block a broad class of preview‑triggered credential leaks.
This practical change reflects a broader, well‑documented attack class: specially crafted files (LNKs, library manifest files, archives containing metadata, or documents with embedded external references) can cause File Explorer or in‑process preview handlers to resolve external resources automatically; when those resources are hosted on attacker‑controlled servers, a Windows client may perform NTLM authentication and leak negotiable material. Several researchers and vendors reproduced bypasses and assigned CVE IDs to successive bypasses, prompting Microsoft to harden behavior while further fixes are developed.
Technical breakdown: how previews led to NTLM leakage
Preview handlers, external references, and automatic network resolution
Preview handlers exist for many file types (PDF, Office, images, HTML containers) and often run in the context of File Explorer to present content without launching heavy applications. Some formats permit embedded resource references (images, stylesheet links, file:// and UNC paths). Explorer or the handler may attempt to resolve those references to render the preview or extract metadata (for example, PE icon resources from a remote executable). If the referenced host requires SMB/NTLM authentication, Windows may attempt NTLM negotiation automatically, exposing response material that an attacker can capture.Real‑world PoCs and the CVE chain
Security teams tracked a sequence of disclosures and bypasses in 2025. An initial zero‑click disclosure prompted a patch (CVE‑2025‑24054), but subsequent research found bypasses and new attack variants that led to additional CVEs (for example CVE‑2025‑50154 and CVE‑2025‑59214). Researchers demonstrated how crafted shortcuts or metadata could trigger remote SMB requests even without explicit user action, and that some mitigation paths left execution paths unprotected, enabling bypasses. Those findings made it clear that fixing every parsing path and third‑party preview handler would be slow; a behavior change at the Shell level offered rapid risk reduction.What Microsoft changed (precise behavior and scope)
- Files marked with the Mark‑of‑the‑Web (MoTW) — Zone.Identifier alternate data stream indicating Internet origin — will not be passed to preview handlers by File Explorer after October 14, 2025 security updates. Instead, the Preview pane displays a protective message and refuses to render content inline.
- This behavior applies to downloaded files and to files accessed on network shares categorized as Internet zone; local files or files saved from Trusted/Local Intranet zones continue to preview normally.
- Users can restore previewing for trusted items by removing MoTW (right‑click → Properties → Unblock) or by using PowerShell’s Unblock‑File for bulk operations. Administrators can add specific servers to Trusted Sites or Local Intranet to avoid MoTW for those sources.
Who’s at risk — practical exposure model
- Environments that still accept NTLM authentication on internal services (no SMB signing, or services that permit NTLM) are the highest risk; captured NTLM artifacts are more useful there.
- High‑volume document triage teams (accounts payable, legal, HR, procurement) who rely on the Preview pane for speed will feel the operational impact immediately.
- Systems that automatically process or index untrusted files (file servers, ingestion services, VDI hosts) are prime targets because they often prefetch metadata or generate thumbnails without explicit user action.
How to stay safe: practical steps for home users, power users, and admins
Below are step‑by‑step, verifiable actions that preserve security while restoring limited convenience where appropriate.1) Patch first — install Microsoft’s October 2025 security updates
- Open Settings → Windows Update and install all available updates; the preview change and associated patches shipped starting October 14, 2025. This is the baseline: do not skip the update because it fixes several Shell/Explorer CVEs.
2) Verify if a file is blocked and safely restore preview for trusted files
- Per file (recommended for one‑offs): Right‑click the file → Properties → on the General tab check the Unblock checkbox and Apply. This removes the Zone.Identifier stream for that file and generally restores preview.
- Bulk (power users and admins, use with caution): Run PowerShell in the folder containing trusted files and execute:
Get-ChildItem -File | Unblock-File
This pipes found files into the Unblock‑File cmdlet and removes MoTW at scale. Use audit logging and limit this to narrowly scoped directories.
3) Use sandboxed behavioral analysis for suspicious files
- Static AV scans often cannot reveal whether a preview operation will cause outbound NTLM negotiation. For files you don’t trust, detonate them in a sandbox that tracks network behavior before unblocking or opening them locally.
- Tools recommended by defenders include Joe Sandbox and OPSWAT MetaDefender (MetaDefender Cloud) — these services run files in controlled environments and report network calls and SMB/HTTP fetches. Use these services when you need to triage unknown files safely.
4) Test in a disposable virtual machine
- Create a VM (Hyper‑V, VMware, VirtualBox) that mirrors your environment, preview the file there, and monitor outbound network traffic. This local sandboxing approach avoids uploading potentially sensitive files to third‑party services and is effective for large companies with controlled lab environments.
5) Disable preview handlers system‑wide (if your workflow allows)
- If previewing downloaded files is not essential, disable preview handlers to eliminate the attack vector completely: In File Explorer, See More → Options → View tab → uncheck “Show preview handlers in preview pane.” This is a blunt productivity trade but eliminates preview‑triggered leakage.
6) Hardening NTLM and network controls (enterprise)
- Restrict and audit NTLM usage with Group Policy (Network Security: Restrict NTLM settings). Use audit mode first to identify legitimate NTLM traffic and then selectively deny or restrict.
- Enforce SMB signing where possible and block SMB egress (TCP 445) from user endpoints to the internet via perimeter firewall rules. This prevents attacker‑hosted SMB endpoints from being reachable.
- Consider adding only trusted vendor portals and internal file servers to the Local Intranet or Trusted Sites zone so files saved from those sources do not receive MoTW. Do this narrowly — broad Trusted Sites configuration erodes the defense posture.
7) Detection and monitoring
- Add EDR/SIEM rules that flag Explorer‑initiated outbound SMB or unexpected NTLM authentication to unusual destinations. Monitor for explorer.exe or dllhost.exe initiating network flows to internet IPs. These are primary indicators of this attack class.
Step‑by‑step: when and how to unblock safely (concise checklist)
- Confirm the file is from a trusted sender and that you expect the content.
- Right‑click → Properties → check Unblock → Apply → OK.
- If you have many files in one folder from a trusted vendor, open PowerShell in that folder and run:
Get-ChildItem -File | Unblock-File - Log the operation (file hashes, source URL, operator) and keep these records for incident tracing.
- If uncertain, run the file in an isolated VM or submit it to a sandbox service first.
Enterprise playbook — balancing security and productivity
- Map workflows: identify teams that rely on Explorer previews and pilot controlled exceptions for those groups only.
- Prefer zone‑based trust: add vendor portals to Trusted Sites or Local Intranet rather than disabling MoTW globally.
- Use auditable scripts and change control for any bulk Unblock‑File operations; require manager approvals and logging.
- Harden identity: accelerate removal of NTLM reliance where feasible; adopt Kerberos/modern authentication, enforce MFA for privileged accounts, and use Protected Users/Privileged Access Workstations for high‑value principals.
Critical analysis: strengths, trade‑offs, and residual risks
Strengths of Microsoft’s approach
- Immediate risk reduction: disabling previews for internet‑marked files removes a low‑interaction trigger that researchers repeatedly weaponized; it’s a high‑leverage fix that protects many users instantly.
- Works across diverse preview handlers: a platform‑level change avoids the Herculean task of fixing every single parser and third‑party handler.
Usability costs and operational friction
- Productivity impact: knowledge workers who triage large numbers of downloaded docs lose an efficient workflow and will incur time costs and increased help‑desk tickets.
- Risky compensations: mass unblocking or wholesale disabling of MoTW weakens multiple Windows defenses (Attachment Manager, Office Protected View, SmartScreen). Administrators must avoid overbroad workarounds.
Residual and long‑term risks
- The change is defensive, not fixative: removing the preview surface reduces exposure but does not eliminate parsing bugs in individual handlers; attackers may pivot to other low‑interaction paths (thumbnailing services, indexing, mail previews). Continuous hardening, detection and migration away from NTLM remain essential.
- Some mitigations are environment‑sensitive: blocking outbound SMB is effective, but organizations must balance connectivity needs for legitimate remote shares and cloud integrations.
Unverifiable or community‑reported details (flag)
- Community analysis has postulated specific internal toggles (for example, changes to URLACTION_SHELL_PREVIEW or registry keys) as the mechanism behind the change. Those low‑level technical inferences are plausible and tested by researchers, but Microsoft’s consumer KB intentionally omits detailed internal engineering specifics. Treat registry hacks as experimental until vendor engineering notes or supported hotfixes appear.
Quick reference: commands and policies
- Unblock a single file (GUI): Right‑click → Properties → Unblock → Apply.
- Unblock many files (PowerShell):
- Open PowerShell in the folder (Shift+Right‑click → Open PowerShell window here).
- Run: Get-ChildItem -File | Unblock-File
These commands remove the Zone.Identifier alternate data stream. Use logging and scope restrictions. - Group Policy to audit/restrict NTLM:
- Policy path: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM.
- Use audit mode first, then apply deny options carefully after testing.
Conclusion
Microsoft’s decision to disable File Explorer previews for internet‑marked files is a pragmatic, security‑first response to a tangible and repeatable NTLM credential‑leak attack path. The update reduces the immediate attack surface and forces adversaries to work harder, but it shifts a burden onto users and administrators who must adopt targeted, auditable workflows to restore productivity when needed. The defensible operational posture is straightforward: patch promptly, restrict NTLM exposure and SMB egress, use sandbox analysis for unknown files, and apply narrowly scoped unblocking or trusted‑zone exceptions only where necessary and logged.For everyday users: install the October 2025 updates, use the Properties → Unblock UI for files you trust, and treat the Preview pane warning as a deliberate protective cue. For administrators: treat this as an opportunity to inventory NTLM usage, harden authentication and egress controls, and adopt scripted, auditable unblocking workflows only for verified sources. The hard work remains: over time, remove NTLM dependence, enforce SMB signing, and tighten detection so that convenience never again becomes an easy path for credential leakage.
Note: user‑facing guides and community write‑ups (including the article you provided) summarize the same mitigation steps and practical workarounds; consult vendor KBs, research writeups, and your organization’s change control before making broad changes to zone or attachment policies.
Source: Make Tech Easier Windows File Explorer Previews are Vulnerable to NTLM Hash Leakage – How to Stay Safe - Make Tech Easier
