IE WebBrowser Control Attack Chain: Clicks Lead to R

Internet Explorer’s legacy WebBrowser control, despite the browser’s official retirement, can still be exploited to achieve full remote code execution (RCE) on Windows systems with just a single user click.

PT Security observed that by exploiting IE’s zone model, Mark of the Web (MOTW) handling, and powerful COM/ActiveX components, attackers can transform seemingly harmless user interactions into code execution on the host.

The core problem is that IE’s mshtml engine and WebBrowser control are still embedded in many desktop applications, especially older VB, .NET, and C/C++ tools with local web interfaces on http://localhost.

These apps often lack robust HTML and JavaScript sanitization, making XSS a realistic starting point.

Once an attacker gains script execution in a localhost context, they can leverage IE’s special treatment of the localhost and file zones to open local HTML files from disk.

This origin escalation effectively converts remote JavaScript into a local‑origin script, which runs with higher privileges.

IE WebBrowser Attack Chain Enables RCE

A subtle timing bug in how IE handles window operations and dialogs allows crafted JavaScript running under http://localhost to open local HTML files without the usual security prompts.

Microsoft eventually fixed the direct “open local file from localhost script” behavior, but only after researchers demonstrated that it could serve as the first pivot in a multi‑stage chain.

With that pivot, the attacker’s next goal is to bypass MOTW so that malicious local content is no longer constrained by Windows’ standard “Open File – Security Warning” checks.

To do this, the chain combines IE and Microsoft Edge. In the localhost XSS, the script opens a Microsoft Edge window to an attacker‑controlled URL.

Under the right conditions, Edge will download an HTML payload straight into the user’s Downloads directory without applying an MOTW tag.

The IE WebBrowser control can then be redirected from the localhost page to that newly downloaded local file, turning what started as a remote payload into a trusted‑looking local HTML document with scripting enabled and no MOTW restrictions.

With the script now executing in a privileged local context, the attacker instantiates high‑risk COM objects via ActiveX, such as WScript.Shell.

According to the Positive Technologies research team, these objects are historically known to enable arbitrary command execution when exposed to untrusted input.

IE displays an ActiveX security warning when such objects are created from local HTML. However, once the user clicks “Yes,” the page can launch commands such as calc.exe or a full-blown malware dropper.

In practice, this chain yields “two‑click RCE”: an initial click that triggers the Edge download, followed by a second click to approve the ActiveX prompt inside the legacy application.

Social engineering and UI design are used to make both clicks appear necessary or harmless.

Additional research shows that IE’s folder views and ZIP browsing surfaces, reachable through the same WebBrowser control, can further reduce the attacker’s reliance on obvious prompts by enabling clickjacking.

By overlaying a tiny, cursor‑following iframe that hosts a ZIP or folder view, an attacker can ensure that any user click on the page effectively double‑clicks a malicious file inside the embedded Explorer view.

This allows payloads to be executed with weak or missing MOTW enforcement. Defenders should treat any use of the IE WebBrowser control as a legacy risk.

Replacing it with modern, sandboxed web rendering controls, eliminating XSS on localhost web UIs, locking down ActiveX/COM via policy, and tightening MOTW-based execution rules are critical steps to closing this attack surface.