I have a proxy server on the WAN as well as my box open to the WAN. I want this proxy server to (when it receives a shell), route it to my host so it can be the "man in the middle" between my connection with the target.
I can reliably do this successfully, but only using
reverse_http. When I try to use
reverse_https I have confirmed through analysis with
Wireshark (as well as not getting the beloved
meterpreter > prompt on my box) that the stage is being successfully downloaded and being executed by the target from my box.
However, the next part when it tries to give my box control of that downloaded stage fails. I can see in Wireshark it's failing because the target keeps sending a
Client Hello but my proxy isn't responding with a
Server Hello to initialize the secure connection. The target keeps sending these
Client Hellos attempting TLSv1 (SSL 3.1) then SSLv3 and then all over again.
To give you an idea of the settings for my handler it's basically all run-of-the-mill stuff,
LPORT 443 except for that I have the
OverrideScheme (for the second part of the payload) set to
ReverseListenerBindPort set to
4444 because I'm behind a NAT.
Payload (made with
msfvenom) is the same kind of thing without the
OverrideScheme and my
LHOST set to the proxy server domain name.
If it would help I would be open to dumping the PCAP. Any ideas at this point would be welcomed because I've been trying for two days now and I'm starting to lose hope.
Here is a screenshot of the what's happening:
Everything after the "stage transmitted" (where the stage IS successfully sent over HTTPS) is the stage now trying to reach me.
Ok, so turns out I had port 443 closed on my NAT. But now there's a new problem! The same thing is happening as last time but now after every
Client Hello my connection gets reset (
RST ACK). Also, only TLSv1 connections are being attempted by Meterpreter now (it's not switching back and forth between SSLv3 and TLSv1). (Still not getting a
Server Hello though)
I read here: Server sends RST after receiving Client Hello when binding certain certificate that this is likely due to some kind of incompatibility of the cipher suites.
So I did a scan of the site with ssllabs.com, and it does indeed support TLSv1 (that's the lowest it goes) in the following cipher suites:
# TLS 1.0 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH x25519 (eq. 3072 bits RSA) FS 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH x25519 (eq. 3072 bits RSA) FS 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
So, based off of this I would think Meterpreter would be able to successfully initiate an HTTPS connection. Does anyone have anymore insight on this?