In this tutorial, we will learn how to do port forwarding in order to execute commands remotely on a target machine.

Port forwarding is useful since it allows us to set up a port on our local machine which we can use to access a remote service on our target, without even needing a password for it.

We will assume you already have gained a remote shell to your victim system, and are able to execute commands remotely, such as with the below screenshot:

Quick reminder, though. If at any time you get lost and don’t know which command to use, you can use the help command to get some help.

First off, we need to find out what our interfaces are, which we can do with the ipconfig command.

As you can see, one of our interfaces is connected to the 10.0.2.0 network; which wasn’t available to us previously. Let’s scroll down further, and we’ll notice that there’s another network interface; this time connected to the 192.168.56.0 network, with which we do have connectivity.

An important thing to note is that we simply executed the ipconfig command from our meterpreter shell. But, what if we want to run it as if we were sitting in front of the following computer?

Thankfully, we can use the execute command to run any command on the remote machine. Let’s look at the help section for the execute command:

We’ll find that we can give it the -i flag if we want to interact with the process after we’ve created it. This is important, since we need to “interact” with the process in order to actually be able to see the output. Therefore, to execute ipconfig on the victim system, we need to use this flag; like so.

This will provide us with the output of the command, showing both interfaces, along with the subnet mask and default gateway for each of them.

1. Finding Available Services

Now that we’ve established the network interfaces available on the machine, and discovered that there’s another network that wasn’t available before, we can run netstat to find which services are available on the 10.0.2.15 network interface.

Notice how, in order to pass an argument to netstat, we need to use the -a flag. Take a look at the following screenshot for an explanation of netstat and its parameters.

And the next one for details on its syntax.

We will use the -a, -o, and -n parameters in this tutorial; to display all active TCP connections, including their process IDs (PIDs) along with each connection’s numerical IP address and port number.

Remember that, to see the output of the netstat command invoked remotely through execute, we need to include the -i flag at the end. Thus, our usage of the command will be:

For this example, we will focus on port number 3306. This connection comes from a process with PID 3668, as we can see on the right-side column.

Let’s find out more about this program by running the Windows tasklist command on the target. tasklist is the Windows equivalent to the ps command on Unix-like systems, like Linux and macOS.

Scrolling further down, we’ll find the process whose PID is 3668, mysqld in this case.

To summarize the information we just gathered, we know the following:

• Process name: mysqld.exe
• Process ID (PID): 3668
• Port Number: 3306
• mysqld cannot be accessed remotely

With this information, we can proceed to use the port forwarding functionality in Meterpreter to allow us to access this service from our attacking host. Here is a list of the parameters available for the Meterpreter portfwd command, which can be consulted by using the help command on the Meterpreter shell.

We will use the -l flag to set up the local port on which we will listen for this remote connection (port 4445 for this tutorial), the -p flag to connect to port number 3306 on the target, and the -r flag to specify the IP address of the target system. You will be notified once the local TCP relay has been created successfully, as shown below:

Now that the port forwarding relay has been established, we can now attempt to connect to the mysql service, which will be available on our localhost, on port 4445, as configured previously.

Did you notice? We weren’t even asked to enter a password! Since a SysAdmin will regularly choose to make his/her life easier by not requiring a password for services that are only available locally.

“After all, I’m the only one with access to this service. It’s not available to anyone on the network. Then, why would I bother with a password anyway?” – SysAdmins everywhere.

Yes, the service is local. Yes, it’s not accessible through the network. Yet, by creating the port forwarding relay, we’ve ensured the system perceives that we’re sitting in front of the physical machine; even though we’re actually not.

So… let’s check the existing databases, shall we?

As you can see, we have a WordPress database at the end of the list. Now that we know that, we can actually do some interesting stuff like acquiring the list of users, password hashes, etc.

First, let’s enter into the database and list the tables on it.

From here, we can look at the schema and select the relevant fields from the wp_users database.

Now that we have the usernames and password hashes, we can run them through John The Ripper to find the actual passwords. But first, let’s copy them into a text file and format it so John can read it.

This file can be saved as a text file, in our example called wpaccounts, and then passed as a parameter to the john program as follows:

This will take a quite long amount of time. However, once it’s done you will get the password for the users in the database. The password is on the left side, and the user is on the right side, between parentheses.

2. Conclusion

Remember that, you should consider setting up a password for services running on your system, at least the ones that allow you to do so. After all, you never know when someone could enter your system and use a port forwarding utility to access and steal information from a local service on your system.

In this example we gathered information from a WordPress blog. However, what if this was your company’s trade secrets, your bank, or even a hospital with your medical history? This is why we study how attacks work, so that the systems we develop and administer are protected and defended from any vulnerabilities and/or exploits.