SSH Tunneling Part 2

SSH TUNNELING 2

In today’s ever-evolving cybersecurity landscape, mastering tunneling techniques is more than just a skill—it’s the key to effective pivoting during penetration tests. We laid the foundation in Part 1 by exploring essential concepts, tools, and practical use cases. It’s time to build on that knowledge and elevate your expertise.

Part 2 takes you further into tunneling, revealing advanced techniques and their real-world applications through two (2) penetration testing scenarios what I like to call the “impossible” tunnel. Whether navigating heavily segmented networks or evading sophisticated monitoring defenses, this installment delivers actionable strategies designed to sharpen your skills and empower you to overcome even the most complex challenges.

By chaining proxies using software like an SSH client, we can forward a specific port through different networks to the Kali pentester machine and redirect all traffic from the client network to the Kali pentester machine. Additionally, we will extend the local and remote port forwarding capabilities to enable multiple systems to connect through remote, local, and dynamic port forwarding tunnels.

In this first penetration testing scenario, the Kali pentest machine is deployed within the client’s network but is not directly accessible. Instead, access is restricted and requires traversal through three intermediary systems. These systems create a layered network structure that adds complexity to direct communication.

Imagine conducting a penetration test in a segmented network where direct access to critical systems hosting Nessus (port 8834) and Updog (port 50001) is restricted. The only path to access these systems is through three (3) jump servers. By leveraging local and dynamic port forwarding, we can securely tunnel through the jump servers to access these services from our local machine. This approach bypasses restrictive firewalls and network isolation while ensuring encrypted communication.

To configure SSH on the client side:

1. Edit Config:

nano ~/.ssh/config

2. Add Server Details:

Host rbt
    HostName 192.168.1.100
    User username
    Port 22
    IdentityFile ~/.ssh/id_rsa

3. Connect:

ssh rbtsecurity
  1. Local Port Forwarding for Updog
    Sets up a local port forwarding tunnel (GCP instance (jump server) for Updog
  2. Local Port Forwarding for Nessus
    Sets up a local port forwarding tunnel (GCP instance (jump server) for Nessus
  3. Connecting to the First Jump Server
    Authenticate and connect to the GCP instance (jump server)
  4. Connection to the Second Jump Server – Dynamic Port Forwarding
    Sets up a dynamic port forwarding tunnel (falson system (jump server 2)
  5. Local Port Forwarding to Third Jump Server
    Sets up a local port forwarding tunnel (Cloud Kali server 3)
ssh -fNC -L [local_port]:[target_host]:[target_port] [user]@[ssh_server]
ssh -fNC -L 8834:localhost:8834 rbtsecurity

ssh -L 8881:127.0.0.1:8881 kali
ssh -D 8881 falcon
ssh -i ./id_rsa.gcp.pentest1 gcp-user@xx.xxx.xxx.xxx
ssh - 8882:127.0.0.1:8834 -i ./id_rsa.gcp.pentest gcp-user@xx.xxx.xxx.xxx
ssh -L 50001:127.0.0.1:50001 -i ./id_rsa.gcp.pentest gcp-user@xx.xxx.xxx.xxx

In this second penetration testing scenario, the Kali pentest machine is deployed on the client’s network, but again, direct access is not possible. Instead, access is restricted, requiring traversal through three (3) intermediary systems. However, unlike the first scenario, where specific services (such as Nessus and Updog) are targeted, this time, the goal is to access the entire network. This layered structure adds complexity, requiring more extensive tunneling techniques to navigate the entire network securely.

In this second penetration testing scenario, gaining local-like access to an entire remote network becomes essential for enumerating, exploiting, or testing systems. This is particularly useful when a pentester has access to an intermediary system (e.g., a jump server) but cannot directly interact with other network resources from their own machine. Using local and dynamic port forwarding, you can bridge this gap, enabling you to interact with the remote network as if it were directly connected to your local system.

  1. Connection to the Third Jump Server – Dynamic Port Forwarding
    Sets up a dynamic port forwarding tunnel (AWS instance (jump server 3))
  2. Local Port Forwarding to Second Jump Server
    Sets up a local port forwarding tunnel (Falcon system (jump server 2))
  3. Local Port Forwarding to First Jump Server
    Sets up a local port forwarding tunnel (Cloud Kali system (jump server 1))
ssh -fNC -L [local_port]:[target_host]:[target_port] [user]@[ssh_server]
ssh -fNC -L 8834:localhost:8834 rbtsecurity

ssh -L 8882:127.0.0.1:8882 kali
ssh -L 8882:127.0.0.1:8882 falcon
ssh -D 8882 -i ./vaf-keypair.pem kali@xx.xx.xxx.xxx

Through the penetration testing scenarios discussed, we explored how techniques like Local, Remote, and Dynamic Port Forwarding are utilized to gain access to systems. These methods enable the forwarding of specific ports through multiple networks to the Kali pentesting machine, effectively redirecting all traffic from the client network to the pentester’s machine. By employing these strategies, pentesters can securely and flexibly route traffic, gaining access to critical services even when direct communication is otherwise blocked or restricted.

Detection and Mitigations

Share the Post:

Table of Contents

Subscribe To Our Blog

Light