The Ghost of Internet Explorer in Windows

The Ghost of Internet Explorer in Windows

Speakers: George Hughey, Rohit Mothe

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=8cb_OF_6Ek8

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/George%20Hughey%20Rohit%20Mothe%20-%20What%20is%20Dead%20May%20Never%20Die%20The%20Ghost%20of%20Internet%20Explorer%20in%20Windows%20MapUrlToZone.pdf

Overview

George Hughey and Rohit Mothe from Microsoft's Security Response Center (MSRC) delivered a deep technical examination of how Internet Explorer's security zone model — code written in the 1990s — continues to underpin the security of modern Windows components, browsers, and Office products. Their talk, titled "What is Dead May Never Die," demonstrates that a legacy security boundary written in a hurry decades ago is still making critical security decisions for the latest Windows 11 installations. The researchers uncovered significant vulnerabilities in the MapUrlToZone function, the central API for determining what security zone a URL belongs to, and showed how inconsistencies between IE's zone logic and modern consumers of that logic create exploitable security bypasses.

Background

▶ Watch: Tearing them down, trying to figure out what's going on. (1:50)

Internet Explorer introduced the concept of security zones in the mid-1990s as a way to classify URLs by trust level: Local Machine, Local Intranet, Trusted Sites, Internet, and Restricted Sites. Files and pages in the Local Machine zone received elevated trust; content from the Internet zone was sandboxed more aggressively. This zone classification was foundational to IE's security model.

IE itself was officially retired, but the zone model never was. The core implementation lives in urlmon.dll, specifically in the MapUrlToZone API, and it is consumed by a remarkable breadth of modern Windows components. The speakers enumerated consumers including: Microsoft Edge, Microsoft Office (Mark of the Web enforcement), Windows Explorer (file trust decisions), Outlook (attachment safety evaluation), Antivirus and EDR products (that rely on zone information for threat classification), and numerous Windows shell components.

The implication is profound: if MapUrlToZone can be convinced to return the wrong zone for a URL — particularly classifying an Internet URL as Local Intranet or Local Machine — all of these modern components will make incorrect security decisions based on that answer.

Key Findings

▶ Watch: And he also found a double free vulnerability. (17:42)

• MapUrlToZone is widely consumed by modern security-critical components that have no knowledge of its IE-era implementation history or edge cases.
• Multiple URL parsing inconsistencies exist between MapUrlToZone's interpretation of a URL and the interpretation made by the application ultimately consuming the content. These inconsistencies create security zone bypass conditions.
• Mark of the Web (MotW) bypasses were discovered that stem from MapUrlToZone misclassification. MotW is the mechanism Windows uses to flag files downloaded from the Internet, triggering Protected View in Office and SmartScreen evaluation in the shell. Bypassing MotW allows a malicious file to open without these protections.
• UNC path handling creates significant attack surface. The function's handling of UNC paths (\\server\share formats) allows crafted paths to be classified as Intranet zone content, effectively giving network-accessible files elevated trust.
• Multiple CVEs were disclosed as a result of this research, with patches issued through Microsoft's standard update process.

Technical Deep Dive

▶ Watch: Um there are three main components to this path. (24:08)

The MapUrlToZone function takes a URL string and returns an integer representing the security zone (0 = Local Machine, 1 = Local Intranet, 2 = Trusted Sites, 3 = Internet, 4 = Restricted Sites). The implementation in urlmon.dll was originally written for IE and encodes decades of backward-compatibility logic, special-case handling, and IE-era assumptions about URL structure.

Parsing inconsistencies as the attack primitive: Modern URL parsers (in Edge/Chromium, in .NET, in Windows networking components) do not use the same parsing logic as urlmon.dll. A URL can be parsed as valid and pointing to an attacker-controlled resource by the consuming application, but parsed differently by MapUrlToZone — resulting in the function returning a different zone than the one appropriate for the actual destination.

The researchers identified several specific inconsistency classes:

1. IP address encoding tricks. URLs containing IP addresses in non-canonical formats (octal notation, hex notation, DWORD representation) may be parsed differently by MapUrlToZone versus other resolvers. An IP address that resolves to an external host might be classified by MapUrlToZone as local or trusted.

1. UNC path edge cases. UNC paths with unusual numbers of leading backslashes, embedded credentials in the path, or specific server name patterns trigger different code paths in MapUrlToZone that can result in Intranet zone classification for what should be Internet zone content. Since the Intranet zone allows credential negotiation (NTLM authentication) by default, this can be exploited to coerce NTLM authentication from the victim to an attacker-controlled server.

1. Dot-segment and path normalization differences. Paths with ../ sequences, percent-encoded characters, or unusual Unicode normalization may be evaluated differently at the zone-check phase versus the content-loading phase.

1. Zone override registry keys are under-validated. Administrators can add URL patterns to trusted zones via registry keys. The pattern matching implemented against these registry entries has its own parser with known-inconsistent behavior relative to actual URL resolution.

Mark of the Web and the trust chain: When a file is downloaded, Windows attaches an Alternate Data Stream (ADS) named Zone.Identifier to the file containing the URL of origin and the zone it was classified as. Office reads this ADS to decide whether to open documents in Protected View. If an attacker can deliver a file such that MapUrlToZone classifies the source as Intranet zone at write time, the Zone.Identifier will record zone 1 instead of zone 3, and Protected View will not be triggered when the file is opened.

Demo / Proof of Concept

▶ Watch: found are a little bit more complicated and to me a little bit more interesting. (28:31)

The speakers demonstrated several concrete bypasses:

• A crafted URL that MapUrlToZone classifies as Local Intranet while modern resolvers correctly identify as an external Internet address. When a file is downloaded via this URL, it receives a Zone.Identifier marking it as Intranet zone, causing Office to open it without Protected View.
• A UNC path crafted to trigger Intranet zone classification, coercing outbound NTLM authentication from a victim who clicks a link in an Office document or Shell shortcut.
• An Office document that bypasses Protected View and executes macros because of zone misclassification, requiring no user action beyond opening the file.

The demonstrations were performed on a fully patched (at the time of research) Windows 11 installation, underscoring that these were not regression issues but novel vulnerabilities in the current codebase.

Defensive Implications

▶ Watch: And this happened when we were doing some testing. (38:09)

Patch application is the primary mitigation. Microsoft has issued patches for the specific vulnerabilities disclosed. Keeping Windows updated is essential.

Be cautious about Intranet zone trust expansion. Organizations that have added broad patterns to their Intranet zone registry configuration are expanding the trust surface of MapUrlToZone. Zone Intranet membership should be as specific as possible, preferably using exact hostnames rather than wildcards.

Credential protection settings matter. The Intranet zone's default behavior of attempting NTLM authentication to servers in that zone is the mechanism behind NTLM coercion attacks enabled by zone misclassification. Enabling Extended Protection for Authentication (EPA), requiring SMB signing, and restricting outbound NTLM limit the impact of zone bypass for credential theft.

MotW should not be the only defense. Mark of the Web is a useful defense-in-depth control but should not be relied upon as the sole barrier between a user and malicious downloaded content. Application whitelisting, disabling macros by default via policy, and user training to not override security prompts provide additional layers.

EDR and AV zone reliance. Security products that use zone information as an input to threat classification decisions should understand the limits of MapUrlToZone and not treat zone classification as authoritative for security-critical decisions.

Key Takeaways

1. Internet Explorer's security zone model is still the foundation of security decisions across modern Windows, Office, Edge, and many third-party security products.
2. MapUrlToZone contains parsing inconsistencies relative to modern URL resolvers that create exploitable security zone bypass conditions.
3. Mark of the Web bypasses stemming from zone misclassification allow malicious Office documents to bypass Protected View without any user security prompts.
4. UNC path handling in zone classification creates NTLM coercion attack surface.
5. Legacy security APIs that are still actively consumed by modern code deserve the same security scrutiny as new code — perhaps more, given the accumulated complexity.
6. The breadth of MapUrlToZone consumers means a single API vulnerability has wide-ranging downstream effects across the Windows security stack.

About the Speaker(s)

▶ Watch: There's this one CVE that has just your name. (40:01)

George Hughey is a security researcher at Microsoft's Security Response Center (MSRC). He focuses on finding vulnerabilities in Windows and described himself as loving to find bugs in the Windows platform.

Rohit Mothe also works at MSRC and has a long background in Internet Explorer security research dating back to tearing apart IE exploits at the start of his security career. He brought continuity of perspective, having worked on IE security and now seeing its legacy architecture still driving modern vulnerability research.