Microsoft has quietly hardened File Explorer in Windows 11 so the Preview pane will no longer render files that Windows marks as coming from the Internet — a deliberate security change shipped with October 2025 security updates that blocks inline previews for Mark‑of‑the‑Web (MoTW) files and shows a protective warning instead.
The Preview pane in File Explorer has long been a productivity shortcut for users who need to triage PDFs, Office documents, images and other attachments without launching full applications. That convenience depends on preview handlers — in‑process components that render file content inside Explorer’s host process. Over time Windows has relied on a lightweight provenance marker, the Mark of the Web (MoTW), written as a Zone.Identifier alternate data stream (ADS) on NTFS, to label files saved from browsers, email, or other internet sources. Those zone markers are read by Attachment Manager, Office Protected View, and other subsystems when deciding whether to sandbox, warn or block files.
Starting with the October 2025 cumulative security packages (commonly reported in the field as the October 14–15 rollups and in many reports tied to KB5066835), Microsoft adjusted Explorer’s behavior so files that still carry the Internet Zone marking are not handed to preview handlers; the Preview pane shows this message instead:
"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."
This block applies to files bearing MoTW and to files opened from Internet‑Zone network shares; it does not prevent users from opening files in their native applications.
Practical impacts:
Note: some high‑profile NTLM‑leak attacks were reported earlier in 2025 (for example, CVE‑2025‑24054 in spring 2025), demonstrating that attackers had working campaigns that used Explorer parsing and archive processing to induce SMB authentication to attacker hosts. Those incidents helped crystallize the threat model that the October hardening addresses.
That said, the change imposes real operational costs. Administrators must weigh the security gain against productivity impacts and avoid knee‑jerk mitigations that weaken other OS protections. The most defensible path for organizations is to apply the updates, harden authentication and network egress, and then adopt narrow, auditable exceptions (Trusted sites, controlled Unblock‑File scripts) for workflows that truly need previews. Until Microsoft publishes detailed engineering notes or a targeted fix that restores previews safely, treat community registry fixes as experimental and favour policies that preserve the long‑term security signals Windows provides via MoTW and Attachment Manager.
Windows users and administrators who rely on the Preview pane should plan for small process changes and coordinate a measured response: patch, harden, and selectively restore — rather than disabling the protections that stopped this class of credential‑theft attacks in the first place.
Source: TechWorm File Explorer Updated on Windows 11 to Block Harmful Files
Background / Overview
The Preview pane in File Explorer has long been a productivity shortcut for users who need to triage PDFs, Office documents, images and other attachments without launching full applications. That convenience depends on preview handlers — in‑process components that render file content inside Explorer’s host process. Over time Windows has relied on a lightweight provenance marker, the Mark of the Web (MoTW), written as a Zone.Identifier alternate data stream (ADS) on NTFS, to label files saved from browsers, email, or other internet sources. Those zone markers are read by Attachment Manager, Office Protected View, and other subsystems when deciding whether to sandbox, warn or block files. Starting with the October 2025 cumulative security packages (commonly reported in the field as the October 14–15 rollups and in many reports tied to KB5066835), Microsoft adjusted Explorer’s behavior so files that still carry the Internet Zone marking are not handed to preview handlers; the Preview pane shows this message instead:
"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."
This block applies to files bearing MoTW and to files opened from Internet‑Zone network shares; it does not prevent users from opening files in their native applications.
What changed, in plain language
- If a file has a Zone.Identifier marking it as from the Internet (ZoneId = 3), File Explorer will not call the preview handler to render it in the preview pane. Instead users see a protective warning.
- Files without MoTW — locally created files or files saved from a Trusted / Intranet zone — continue to preview normally.
- Manually removing the MoTW (for example via File Properties → Unblock, or via PowerShell’s Unblock‑File) restores preview behavior for that file. Administrators can also add trusted file shares to Local intranet or Trusted sites to avoid the Internet Zone marking, but that broadens trust for all files from that source.
Technical mechanics: Mark of the Web, Attachment Manager and preview permissions
Mark of the Web (MoTW) and Zone.Identifier ADS
Windows records the origin zone of many downloaded files using an NTFS alternate data stream named Zone.Identifier. The ZoneId numeric values map to zones such as Local machine (0), Local intranet (1), Trusted sites (2), Internet (3), and Restricted sites (4). Attachment Manager, SmartScreen, Office Protected View and the Shell consult this metadata when deciding whether to allow certain behaviors, including macro execution, Protected View, and — now — in‑process preview rendering.Preview permission check (URLACTION_SHELL_PREVIEW)
Community researchers and independent analysts have demonstrated that Explorer consults a zone‑based policy action before invoking preview handlers — often discussed as the URLACTION_SHELL_PREVIEW (0x180F) URLAction. Field reproductions indicate the October 2025 updates effectively deny the preview action for Internet‑zoned files by default, causing Explorer to display the warning instead of handing the file to the preview renderer. Several technical writeups show how removing the Zone.Identifier (Unblock) or adding the source to Trusted/Local Intranet restores previews, consistent with a zone‑based policy flip. This particular registry/URLAction change is documented by community analysis and reproduced across tests, but it should be treated as a well‑reasoned inference until Microsoft publishes a low‑level engineering note.Why network resolution leads to credential leakage
Certain file formats (HTML fragments embedded in documents, .library‑ms manifest entries, thumbnails, archive entries pointing at file: or UNC resources) can instruct the renderer to fetch external resources. When those references resolve to an SMB share hosted by an attacker, Windows will perform network authentication. If NTLM negotiation occurs, elements of the authentication exchange can be captured remotely. Those captured artifacts may be usable in relay, pass‑the‑hash style attacks, or offline cracking, depending on the environment and mitigations in place (SMB signing, NTLM restrictions, Kerberos availability). Blocking lightweight previewing removes a low‑friction, user‑visible trigger for such network authentication attempts.How this affects users and help desks
Many users — especially knowledge workers in accounts payable, legal, HR, procurement and other high‑volume document workflows — rely on the Preview pane to triage dozens of documents a day. The October change removes that quick inspection path for files downloaded from the Internet, forcing additional clicks and application launches. Community reporting across Microsoft Answers, Reddit, and enterprise forums shows widespread user disruption since the update rollouts.Practical impacts:
- Immediate loss of quick triage for downloaded files (PDFs, Office documents).
- Increased help‑desk volume as users ask how to restore previews.
- Risk of improper mitigations (for example, bulk‑unblocking every file or disabling MoTW) that lower the organization’s overall security posture.
How to restore previews (safe, practical options)
These steps are ranked by scope — smallest, lowest‑risk changes first.1. Per‑file unblock (recommended for one‑offs)
- Right‑click the downloaded file in File Explorer → Properties.
- On the General tab, check the Unblock checkbox if present.
- Click Apply → OK. If Explorer still doesn’t preview the file, restart File Explorer or sign out and back in.
This removes the Zone.Identifier ADS from that file only and restores preview for that single, trusted item.
2. Bulk unblock for trusted folders (use cautiously)
- Open an elevated PowerShell session.
- Run: Get-ChildItem -Path "C:\path\to\folder" -Recurse | Unblock‑File
Document and log the operation. Only run this on tightly controlled, known sources (for example, vendor drop folders that you validate before processing). Bulk unblocking changes metadata for many files and increases risk if misapplied.
3. Zone / Trusted Sites approach (for network shares)
- Add vendor portals or internal file servers to the Local intranet or Trusted sites zone in Internet Options → Security → Trusted sites / Local intranet. Files saved from these zones will not receive an Internet marking and will preview normally. This is appropriate for trusted vendor portals, but adding broad ranges or public file servers to Trusted Sites weakens boundary controls.
4. Group Policy to prevent new files inheriting MoTW (high‑impact; use only with compensating controls)
- Group Policy: User Configuration → Administrative Templates → Windows Components → Attachment Manager → Do not preserve zone information in file attachments — enable.
- Registry equivalent: SaveZoneInformation values in HKCU/HKLM (documented in Attachment Manager guidance).
This prevents Windows from writing Zone.Identifier for new saved attachments, but removing that signal eliminates an important OS‑level detection and control; apply only when you have strong compensations such as EDR, mail gateway scanning, and network egress controls.
Admin playbook: balancing security and productivity
- Patch promptly: ensure devices are up to date with October 2025 security updates to eliminate the underlying vulnerabilities Microsoft fixed. The preview block itself is a defensive hardening layered atop those fixes.
- Harden authentication: restrict NTLM where possible, require SMB signing, prefer Kerberos and modern authentication flows, and block SMB egress to the Internet. These measures reduce the value of any leaked NTLM artifacts.
- Targeted trust: use Trusted sites / Local intranet zoning for specific vendor portals and document sources; avoid broad Trusted Sites additions.
- Use auditable scripts for bulk unblocking: if you must restore previews at scale, implement scripted Unblock‑File workflows with change control, logging, and limited scope.
- Monitor and detect: deploy EDR detection for anomalous NTLM/SMB flows, and watch for OT/IoC indicators of exploitation attempts. Expect security vendor feeds and Microsoft telemetry to add detection guidance if active exploitation is observed.
Security analysis: strengths, weaknesses and trade‑offs
Strengths (why Microsoft’s move makes sense)
- Immediate attack-surface reduction: Blocking automatic previews for Internet‑zoned files removes a low‑interaction trigger that attackers have repeatedly exploited to coerce network authentications and capture NTLM artifacts. This is a high‑benefit mitigation that can be deployed centrally via updates.
- Conservative, defense‑first posture: In cases where filesystem parsing can lead to remote authentication, forcing an explicit open in a native application reduces silent, unattended exposures.
Weaknesses and operational risks
- Usability impact: The Preview pane is baked into many workflows; removing it for Internet‑marked files adds friction and real labor costs for high‑volume teams.
- Workarounds can reduce security: Bulk unblocking or disabling MoTW globally will restore previews but defeats the protective metadata that other Windows subsystems (Office Protected View, SmartScreen) rely upon. Administrators must not treat unblocking as a universal fix.
- Lack of low‑level vendor explanation (so far): Microsoft’s public notes describe the behavior change and the security rationale, but detailed internal engineering explanations (for example, explicit registry keys changed) remain largely community‑reconstructed. Treat registry‑level workarounds with caution until official engineering documentation or a targeted hotfix clarifies the intent.
Unverifiable or community‑reported claims (flagged)
- Multiple community posts and independent analyses propose that the Internet Zone’s URLACTION_SHELL_PREVIEW (0x180F) was changed to deny preview for Zone 3; this matches observed behavior and reproducible tests. However, the precise registry key or internal toggle remains a community inference until Microsoft publishes an engineering post‑mortem or a KIR‑style bulletin that explains the low‑level change. Administrators should treat such registry edits as experimental and risky until the vendor confirms details.
Cross‑referenced verification and the CVE context
Microsoft bundled this behavioral hardening with October 14–15 cumulative updates that fixed multiple Shell and preview‑related vulnerabilities. CVE records tied to the October 2025 patches include information‑disclosure/spoofing vulnerabilities in File Explorer and related components, and public CVE entries (published 14 October 2025) show that Microsoft issued fixes for these issues as part of the Patch Tuesday rollup. Independent vulnerability trackers and security vendors cataloguing CVE‑2025‑58739 and related IDs describe the class of risk that motivated the change: exposure of sensitive information and NTLM hash disclosure scenarios. Cross‑checking Microsoft’s KB entries, major security outlets and CVE trackers confirms the timeline and the defensive rationale underlying the preview block.Note: some high‑profile NTLM‑leak attacks were reported earlier in 2025 (for example, CVE‑2025‑24054 in spring 2025), demonstrating that attackers had working campaigns that used Explorer parsing and archive processing to induce SMB authentication to attacker hosts. Those incidents helped crystallize the threat model that the October hardening addresses.
Practical recommendations (short checklist for IT teams)
- Patch machines with the October 2025 updates, then assess impact across user groups.
- For high‑volume preview users, implement a pilot for targeted Trusted Sites or scripted, auditable Unblock‑File operations rather than a blanket policy change.
- Harden authentication and block SMB egress to the Internet. Require SMB signing and prefer Kerberos where possible.
- Log and monitor changes to Attachment Manager policies, Unblock operations, and unusual NTLM/SMB connection attempts.
- Avoid registry hacks unless validated in a controlled pilot; wait for vendor engineering notes or a targeted hotfix if you require a safer restoration of preview behavior.
Conclusion
Microsoft’s decision to block inline previews for files tagged as Internet‑originated is a blunt but defensible security hardening: it removes an easy, low‑interaction path attackers have used to coerce Windows into leaking negotiable authentication material such as NTLM hashes. The move trades an old convenience for a measurable reduction in a class of credential‑theft attacks, and it arrived with the October 2025 security rollups that addressed multiple Shell‑related CVEs.That said, the change imposes real operational costs. Administrators must weigh the security gain against productivity impacts and avoid knee‑jerk mitigations that weaken other OS protections. The most defensible path for organizations is to apply the updates, harden authentication and network egress, and then adopt narrow, auditable exceptions (Trusted sites, controlled Unblock‑File scripts) for workflows that truly need previews. Until Microsoft publishes detailed engineering notes or a targeted fix that restores previews safely, treat community registry fixes as experimental and favour policies that preserve the long‑term security signals Windows provides via MoTW and Attachment Manager.
Windows users and administrators who rely on the Preview pane should plan for small process changes and coordinate a measured response: patch, harden, and selectively restore — rather than disabling the protections that stopped this class of credential‑theft attacks in the first place.
Source: TechWorm File Explorer Updated on Windows 11 to Block Harmful Files
