Bypassing AV with Metasploit over the internets.

[mtgarden at gmail.com (Matt Gardenghi)]

Couple of thoughts; looking to solicit some comments. The background for 
these comments can be found at: http://www.skullsecurity.org/blog/?p=261

Anyway, I was hoping for comments on the issues below; handling NAT, 
DHCP addresses, and sticky code. Thanks.


If there is no proxy involved and port 80 outbound is open, then you can 
just reach out and use reverse TCP. If there is a proxy, then you need 
to utilize reverse_http. This is a non-issue unless of course you have a 
NATted IP like myself. How do we fix this? It would seem simplest to 
have PXHOST1 and PXHOST2. PXHOST1 is the routable IP that is included in 
the payload for the victim. We want them to reach out to that IP which 
will be port-forwarded to our local attack machine. The PXHOST2 would be 
our local IP to which the exploit binds. This should solve lots of 
problems. First it covers the whole NAT issue, and second, it doesn?t 
increase the load on a victim machine.

It would be really cool, if the PXHOST/LHOST in the exploit code we sent 
out to the victim to start the process could handle DNS lookups. Then I 
could feed the DynDNS entry for my router to the code and not have to 
worry about time sensitive exploits. During a long pentest, I?d want 
some code that lasted longer than 4 hours. I guess the answer to that is 
a static IP, which I have in many circumstances though by no means all 
of them.

Anyone know how to get my code to re-execute? i.e. become sticky? I 
guess, I could bind the Metasploit payload to an executable ZIP. One 
that opens, runs a batch script that migrates the payload to a separate 
directory and attempts to schedule it with AT, then executes the payload 
immediately before cleaning itself up. Other than that, I have no idea 
how to make it sticky.

Matt