Remote code execution over WAN

Question

Say I am on a a computer behind a NAT and I want to execute an RCE exploit on another computer behind a different NAT(note that no ports are forwarded to the victim's computer on his/her NAT) Could I then run an exploit like this(assuming that I already know that the target computer is vulnerable to that exploit) and hope to get a shell, if yes what changes are to be implemented such that the exploit is successful?

Answer 1

This boils down to a basic networking problem: if the exploit requires you to connect to a listening network service on the target (e.g. exploiting BlueKeep requires you to connect to the RDP service running on the target), you need a way to connect to the target by IP address. You mention the target is behind a NAT, and that port forwarding is not configured. So how would you address the target?

If you launch your exploit directly at the WAN address of the NAT device, it doesn't have any rules set to deal with the traffic, so it will be dropped or rejected. If you launch your exploit directly at the internal address of the target, it won't get anywhere since it shouldn't route across the internet.

Basically, you are out of luck unless port forwarding is configured (either manually or through something like UPnP), or if you can get a shell on another device on the target's internal network to pivot with.

Answer 2

Well, there are basically 2 types of shell that one uses, bind shell and reverse shell. In this case when the target is behind another NAT it would not be possible to get a bind shell which opens a port on the victim's system. Since the victim is on another network it would not be possible for us to access the bind shell that would be opened by the exploit.

However, a reverse shell is definitely possible in this scenario. A reverse shell opens a port on your system and listens for any incoming connections from the target machine. The challenge here is the listening server's IP address to use while creating such an exploit, so that the shell reaches us. We can overcome this problem in the following ways:

1. Port forwarding on your router - If you know the public IP address (say x.x.x.x) of your router, and you are able to change the settings on your router to forward the incoming requests to a particular port (say 4444) to your system, then you should be able to use your router's IP and port in your exploit, i.e (x.x.x.x:4444).

2. Keep in mind that the above IP address (x.x.x.x) will not be static if you are planning to use your home network or any other type of personal internet connection. You might need a static IP address to ensure that the exploit runs and of course, for persistence. In this case, you can turn to servers hosted on cloud such as AWS or Digital Ocean and get a static public IP address for your instance. You can also use services such as ngrok to create a TCP tunnel for your exploit with a known domain name and port pointing to your server and the corresponding listening port.