Internet Explorer’s Security Zone API Still Runs on Modern Windows
Modern Windows security decisions still run on Internet Explorer’s security zone model from the 1990s. The MapUrlToZone API (MUTZ) assigns every file path or URL to one of five zones: local machine, local intranet, trusted, internet, or restricted. Office uses it to decide whether to open a downloaded document in Protected View. Mark of the Web uses it. AV products use it. The DLL shipping the logic still ships in System32 on the latest Windows.
A Zero-Click Outlook Exploit Showed What Happens When MUTZ Fails
In 2023, Forest Blizzard, a nation-state threat actor, exploited a CVE in Outlook with zero user interaction. The attack: send a reminder task with a custom sound file pointing to an attacker-controlled SMB share. When the reminder fires, Outlook reaches out to fetch the file. Windows authenticates over NTLM. The attacker relays the NTLM hash against a vulnerable Exchange server, gaining access without a single click from the victim. Microsoft’s partial fix added a MUTZ call to check the sound file’s zone before connecting.
Path Prefix and Hostname Misclassification Bypasses
The research uncovered 12 CVEs across four bypass categories. Path prefix bugs exploit the shell: scheme: MUTZ checks a registry default that returns zone 0 (local machine) for any shell: path, even when the path connects to a remote IP. Hostname misclassification bugs fool MUTZ’s IPv4 and IPv6 detection. Padding an IPv6 interface ID beyond eight characters breaks IsIPv6, so MUTZ treats the address as a dot-free DNS name mapping to local intranet. An IPv4 port prefixed with 0 triggers octal parsing; since 8 is not a valid octal digit, the port fails and MUTZ misclassifies the host.
Canonicalization Gaps Let Remote Paths Pass as Local
Canonicalization bugs are the most general bypass category. One uses the device namespace prefix with a C: component followed by path traversal characters. CreateFile strips the C: and traversal, resolving to a remote path. MUTZ sees a question mark in the path and treats everything after it as HTTP query parameters, canonicalizing the whole thing down to \Device: on the local machine. Another bypass adds one extra slash to a UNC path: CreateFile strips it and connects remotely; MUTZ looks for a hostname between the two slashes, finds nothing, and defaults to local.
The January 2025 Fix: Unified Path Canonicalization
The root cause across all categories is parsing differences between MUTZ and CreateFile. MUTZ classifies security zones; CreateFile opens connections. When the two disagree on what a path resolves to, an attacker can pass a path MUTZ reads as local while CreateFile connects remotely. Since January 2025, MUTZ uses the same canonicalization routine as CreateFile. Point fixes had compounded over decades, steadily diverging the two implementations. The unified approach cut code complexity and eliminated the entire class.
Notable Quotes
that’s tracked as forest blizzard. Rohit Mothe · ▶ 13:24
port. This blew my mind when I saw this. George Hughey · ▶ 27:17
So, in total, I was able to find 12 George Hughey · ▶ 38:54
Key Takeaways
- MUTZ, a 1990s Internet Explorer API, still governs security zone decisions in modern Windows applications.
- Forest Blizzard exploited a MUTZ-reliant code path in Outlook to achieve NTLM relay with zero user interaction.
- The January 2025 fix unified MUTZ’s canonicalization with CreateFile’s, closing the entire category of bypasses.
About the Speaker(s)
George Hughey is a member of MSRC’s Vulnerabilities and Mitigations Team at Microsoft, where he has spent five years investigating Windows components and hunting for pervasive vulnerabilities across the OS.
Rohit Mothe is a Security Researcher on MSRC’s Vulnerabilities & Mitigations team at Microsoft, with over a decade of experience researching and exploiting vulnerabilities across various roles, including early work tearing down Internet Explorer exploits.