NAT, reverse binding techniques and metasploit

Discussion about's server
Post Reply
User avatar
Posts: 38
Joined: Thu May 15, 2008 9:49 am

NAT, reverse binding techniques and metasploit

Post by GeorgeTI »

OK, this is my second post since a long time ago (and as I see it, most people were pretty busy too, the forum was almost dead :shock: ) buuuut anyway, since it is such a long time ago, I thing it is best to get started right on some technical issues.
So, as the topic suggests, this is about understanding and using the NAT protocol and how this affects some things, and I decided to focus on metasploit.

So, here goes:

NAT, or Network Address Translation, and PAT, or Port Address Translation, are the solutions that IT folks and namely the ISP people use to conserve IP address space. That is, we use some addresses to match a lot more computers. The routers at home use mostly PAT, to match the 3-5 or more computers at home with a single public IP address. For more info just google it, I am way too bored to type :wink:

And here comes what I want to discuss:
Suppose a simple scenario: Let A be a server with a certain vulnerability, and B be a blackhat box. Both boxes are behind firewalls and ADSL routers respectively. That is, A can accept incoming connections ONLY from CERTAIN ports (let's suppose it is 80) and B is behind a PAT, accepting incoming connections only when there is a certain outgoing connection registered in its memory. Notice that outgoing connections from both A and B are unfiltered (which is usually the case in many servers and almost all home networks -- please comment on this as needed).
So, B has found an exploit on A, in the service that runs on the specific port (for here it's 80, it might be anything). Now, it needs to establish bidirectional communication in order to do stuff (meterpreter shell etc). The problem is HOW?

One idea I had is to use the port forwarding feature most home routers have to make the listening port of meterpreter shell (I thing the default is 4444) listen to the outside world (internet). This can be somewhat tricky, as there are many more other things in the way but seems reasonable enough.
Another idea was to use a public shell account as a medium (A connects to the shell account, B connects to the shell account, fun starts) but this is way more risky as B has to load specific tools on the shell account (namely meterpreter handler and some other things) which can be easily detectable and traceable.
Of course there is the possibility of accessing a network with all-public IP addresses but this is not the rule but the exception.
Please share your thoughts and ideas
George T. I.
Post Reply