Browser detection issue #803

corelanc0d3r opened this Issue Sep 18, 2012 · 7 comments


None yet
4 participants

corelanc0d3r commented Sep 18, 2012


I noticed some interesting behavior when testing some IE exploits on a variety of hosts (XP with IE8, WIn7 with IE8, Win7 with IE9).

Clients are configured to use a proxy, capable of doing SSL inspection (mitm).

When SSL is enabled for the exploit, the proxy will intercept and sends a slightly diffferent user agent to the msfconsole webserver... different enough to make msf bail out and tell it's not a supported platform.

What I have discovered is that the browser version is wrong, but the windows version is correct:

Actual version What metasploit sees
XP SP3 with IE7 MSIE7 / NT 5.1
XP SP3 with IE8 MSIE7 / NT 5.1
Win7 with IE8 MSIE7 / NT 6.1
Win7 with IE9 MSIE7 / NT 6.1

If the IE8 target (which usually is based on a msvcrt.dll ROP chain) works on IE7 too, then the exploit can be successful in an increased number of cases, if the IE8 payload is used for MSIE7 / NT 5.1 at all times

For the non-existing combination of MSIE7 / NT 6.1, it would be good enough to send the IE9 payload. It's somewhat slower, but at least it will give a shell and not a crash.

For non SSL sessions, the UA is correct.


todb-r7 commented Sep 18, 2012

Do you have a record of the actual user-agent strings and what generated them? That'd be nice to have.

Is this User-Agent mutation proxy product specific, or something that IE is doing for some reason?


todb-r7 commented Sep 18, 2012

Opened this as a Redmine bug


wchen-r7 commented Sep 18, 2012

I wanna know if that's proxy specific, too. Maybe every proxy product behaves a little differently.


FireFart commented Sep 18, 2012

is this the ie compatibility mode?

Emulate IE7 mode causes IE8 to do three things:

1) Use IE 7 Standards mode for standards mode document

2) Send the IE7 User agent string

3) Sets the right internal parameters to process conditional comments as IE 7 would.

As you can see, it does more than just setting the HTML document’s compatibility-mode.

corelanc0d3r commented Sep 18, 2012

yeah, it's proxy specific - so it might be different for other products, but at least the Windows version component was accurate. It's definitely not compatibility mode (although the behavior looks similar, and the proposed technique might actually work too in case of compatibility mode)

User agents :

XP SP3 with IE8 :
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Win7 with IE8 and IE9 (same output)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)


wchen-r7 commented Sep 22, 2012

I'm tracking the issue in here instead:


todb-r7 commented Nov 17, 2012

Closing this out in favor of RM7244

@todb-r7 todb-r7 closed this Nov 17, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment