Black-Box VAPT Walkthrough (Part 2): Exploiting a Weak VNC Password

⚠️ Disclaimer: This was performed against an intentionally vulnerable machine in an isolated lab. Don't try any of this against systems you don't have explicit authorization to test.

Picking up from Part 1

In Part 1 of this series, I configured Nessus, ran a full vulnerability scan, and pulled a handful of high-impact findings out of the noise. One of the most interesting was a weak VNC password sitting on:

TARGET-IP:5900

Nessus labeled it simply as:

VNC Server 'password' Password

VNC Server 'password' Password

But part of doing VAPT properly is not just taking the scanner's word for it. I wanted to manually reproduce the finding myself and confirm it was actually exploitable — not just theoretically flagged.

A quick primer on VNC

VNC (Virtual Network Computing) lets a remote user interact with a full graphical desktop over the network. A typical deployment has a server listening for connections, usually on the default port:

5900/tcp

If that service is exposed and only protected by a weak password, an attacker doesn't just get "access" in the abstract — they can get a live, interactive desktop session.

What Nessus actually reported

Plugin: 61708
Host: TARGET-IP
Port: 5900/tcp
Severity: Critical

Plugin: 61708
Host: TARGET-IP
Port: 5900/tcp
Severity: Critical

The scanner had authenticated to the VNC service itself using a weak/default password — so this wasn't a purely theoretical misconfiguration. But I still wanted to reproduce it by hand rather than just trust the plugin output.

Connecting manually

I installed a VNC Viewer on Kali and connected directly:

vncviewer TARGET-IP:5900

vncviewer TARGET-IP:5900

The client connected and walked through standard authentication:

Connected to RFB server
Performing standard VNC authentication
Authentication successful

Connected to RFB server
Performing standard VNC authentication
Authentication successful

And the server identified the desktop as:

root's X desktop (metasploitable:0)

root's X desktop (metasploitable:0)

That last line is the important part — this confirmed the Nessus finding independently, and told me exactly what privilege level I'd be looking at.

What did this actually prove?

The chain here is worth spelling out, because it's the difference between a scanner line-item and a real security problem:

Network exposure
      ↓
VNC service on port 5900
      ↓
Weak authentication
      ↓
Successful VNC authentication
      ↓
Remote graphical access

Network exposure
      ↓
VNC service on port 5900
      ↓
Weak authentication
      ↓
Successful VNC authentication
      ↓
Remote graphical access

The issue wasn't "port 5900 is open." Plenty of open ports are fine. The actual problem was:

A remotely accessible VNC service was protected by weak authentication — and that authentication could be defeated.

Capturing evidence

Once the session was up, I took a screenshot as proof (saved as vncviewer weak passwd). Evidence collection matters in a VAPT engagement because it's what turns "I believe this is exploitable" into "here's the record." Useful evidence generally includes:

Scanner output
Terminal commands and their output
Successful connection logs
Screenshots
Service/version information
Proof of the privilege level obtained

Why the privilege level matters

The real-world impact of a weak VNC password depends heavily on whose session you land in. If the account is privileged, a successful login can mean the ability to:

Access files
Launch applications
View sensitive information
Modify system settings
Execute commands
Fully interact with the OS

In this case, the session belonged to the root desktop — which is about as bad as this particular finding could get.

Remediation

The immediate fix is obvious: replace weak/default credentials with something strong and unique. But that alone isn't enough. Worth layering on:

Disable VNC if it's not needed. If there's no operational reason to run it, remove the service.
Restrict exposure. Administrative services like this shouldn't be reachable from untrusted networks.
Use network controls. Firewall rules and segmentation limit who can even attempt a connection.
Avoid privileged graphical sessions. Remote desktop services should run with the minimum privilege necessary, not root.
Monitor remote access. Unexpected VNC connections should trigger alerts.

Why this finding matters

This is a small, clean example of why vulnerability validation matters. Nessus flagged the weak password — that's useful. But manual validation delivered something more valuable:

Proof that remote access was actually possible.

The full workflow, start to finish:

Nessus finding → VNC service → VNC Viewer →
Successful authentication → Remote graphical access → Evidence

Nessus finding → VNC service → VNC Viewer →
Successful authentication → Remote graphical access → Evidence

That's the whole point of moving from automated discovery to manual proof of impact — it's the difference between a line in a PDF report and something a stakeholder actually has to take seriously.

Wrapping up Part 2

Here's what this stage covered:

Identified the exposed VNC service
Understood exactly what the Nessus finding meant
Manually connected and validated the authentication bypass
Determined the privilege context (root)
Captured evidence of the successful access
Walked through the real-world security impact
Laid out concrete remediation steps

But the VNC issue wasn't the only serious finding from the scan. Part 3 covers the other two: a legacy SSL/TLS configuration and an unauthenticated bind shell offering root-level command execution.

Contents