Post cover image

October 1, 2026

Network Pentesting Methodology — Part 1: NFS & VNC

This is the first part of a practical series that builds a repeatable network pentesting methodology using Metasploitable 2.

By Nadana

6 min read

The goal is not to treat every open port as a shortcut to exploitation. Instead, each service is explored to understand what it exposes, how it is configured, and what useful information or access it can provide.

For this part, I focused on NFS and VNC.

None

Starting with Service Discovery

I started by looking at what the machine was exposing to the network.

At this point, I was not trying to exploit anything. I just wanted to answer a few basic questions:

  • Which ports are open?
  • What services are running?
  • Which of them look interesting enough to investigate further?

I used:

nmap -sV 192.168.195.128

From the scan, two services became especially interesting for this part:

2049/tcp   NFS
5900/tcp   VNC

That gave me two different paths to follow:

NFS → possible filesystem exposure
VNC → possible remote desktop access

So instead of treating the scan as the result, I used it as a starting point for service-specific enumeration.

None

NFS

Why I Looked at NFS

NFS, or Network File System, allows directories to be shared across a network.

Normally, that is not a problem by itself. The issue is how those shares are configured.

When I see NFS exposed, I usually want to know:

  • What is being exported?
  • Who is allowed to access it?
  • Can I mount it?
  • Are sensitive files exposed?

So the first thing I did was confirm the NFS-related services:

nmap -sV -p 111,2049 192.168.195.128

This confirmed that the target had NFS/RPC-related services available.

None

Checking the NFS Exports

Next, I checked which directories the server was exporting:

showmount -e 192.168.195.128

The result was:

/ *

This was immediately interesting.

The / means that the root filesystem is being exported, while * means the export is broadly available instead of being limited to one specific trusted host.

So, in practical terms, the result suggested:

The whole filesystem may be remotely accessible.

At that point, the obvious next step was to see whether I could actually mount it.

None

Since the initial showmount result already showed that the root filesystem was exported, I followed up with a few Nmap NFS scripts to get a clearer view of the share, including its contents, permissions, and filesystem information before mounting it manually.

None

Mounting the NFS Share

I created a local mount point:

sudo mkdir -p /mnt/nfs

Then mounted the target filesystem:

sudo mount -t nfs 192.168.195.128:/ /mnt/nfs

After that, I listed the mounted directory:

ls -la /mnt/nfs

The mount worked, and I could browse the target filesystem.

Some of the important directories available were:

/etc
/home
/root

This was the point where the NFS issue became more than just an exposed service.

The flow was now:

NFS exposed
   ↓
Root filesystem exported
   ↓
Filesystem mounted successfully
   ↓
Sensitive directories accessible

A useful screenshot here would show both the active mount and the filesystem listing:

mount | grep nfs
ls -la /mnt/nfs
None

Looking for Sensitive Files

Once I had access to the filesystem, I started checking whether sensitive files could also be read.

One of the most obvious files to check on a Linux system is:

/etc/shadow

So I tried:

sudo cat /mnt/nfs/etc/shadow

The file was readable.

That changed the impact of the NFS misconfiguration quite a lot.

Instead of simply having access to files, I now had access to password hashes stored by the operating system.

The path became:

NFS exposure
   ↓
Remote access to filesystem
   ↓
/etc/shadow readable
   ↓
Password hashes exposed
None

Extracting the Interesting Hashes

To make the output easier to work with, I filtered the shadow file for the relevant hash format:

sudo cat /mnt/nfs/etc/shadow | grep '\$1\$'

Then I saved those hashes to a file:

sudo cat /mnt/nfs/etc/shadow | grep '\$1\$' > ~/hashes.txt

At this stage, the important point was not the command itself.

What mattered was that one exposed network service had now given me authentication material that could be analyzed offline.

Offline Password Analysis

I used John the Ripper to analyze the hashes:

john ~/hashes.txt

Then checked the recovered results with:

john --show hashes.txt

This is a good example of how one finding can naturally lead into another part of the attack path.

The NFS service itself did not directly give me a shell.

Instead, it exposed data that could potentially be reused somewhere else.

NFS
  ↓
Sensitive file exposure
  ↓
Password hashes
  ↓
Offline password analysis
  ↓
Possible credential reuse later

Actual Output

The exact John output from the lab should be placed here:

None None

So the NFS flow in this lab became:

NFS exposed
→ root filesystem exported
→ filesystem mounted
→ sensitive files accessible
→ password hashes exposed
→ offline analysis

VNC

Why I Looked at VNC

The other service I focused on was VNC.

VNC provides graphical remote access to a system, so if it is exposed, I want to know:

  • What version is running?
  • What authentication method is being used?
  • Can I connect?
  • What kind of session do I get?
  • Which user is the session running as?

I started with service-specific enumeration:

nmap -sV -p 5900,5901 --script vnc-info 192.168.195.128

The result showed:

5900/tcp open  vnc

It also revealed:

Protocol: 3.3

and:

Security type: VNC Authentication

So before even opening a VNC client, I already knew that:

  • VNC was reachable,
  • it was listening on port 5900,
  • the protocol version was 3.3,
  • and it expected VNC authentication.
None

Connecting to VNC

After confirming the service, I connected using:

vncviewer 192.168.195.128:0

The authentication worked, and I got access to the remote desktop.

At first, that already looked like a successful result, but I still needed to check what level of access the session actually had.

A desktop session alone does not tell me whether I am running as a normal user or as root.

None

After identifying the VNC service, I checked the stored VNC password file, copied it to my local user directory, and then used it to authenticate to the service. The connection was successful, confirming that the VNC session was accessible remotely 192.168.195.128:0.

None

Checking the Privilege Level

Inside the VNC session, I opened a terminal and ran:

whoami

The result was:

root

I also checked:

id

The result confirmed:

uid=0(root)

So the VNC session was running with root privileges.

That means the path was not just:

VNC access

It was actually:

VNC exposed
    ↓
Authentication succeeded
    ↓
Remote desktop obtained
    ↓
Privilege checked
    ↓
Root session confirmed

A single screenshot showing the VNC desktop with whoami and id in the terminal would be strong evidence for this part.

None

The VNC path therefore became:

VNC discovered
→ protocol enumerated
→ authentication identified
→ remote session obtained
→ privilege level verified
→ root access confirmed

What This Part Adds to the Methodology

The two services behaved differently, but both reinforced the same approach:

Discover
→ Enumerate
→ Interpret the result
→ Validate the exposure
→ Follow the next useful path

NFS produced access to sensitive data.

VNC produced direct privileged access.

That distinction is useful because it shows why enumeration should guide the next step instead of relying on a fixed exploit checklist.

Want to Try This Lab Yourself?

If you want to follow along and reproduce the same steps, you can set up a small local lab using:

Metasploitable 2 is intentionally vulnerable and is designed for practicing penetration testing in a safe lab environment.

After importing both machines, make sure they are connected to the same isolated virtual network, then identify the target IP address before starting the enumeration.

Keep the lab isolated and only test systems you own or have permission to use.