Dev Machine Walkthrough — Practical Pentesting Journey from Recon to Root

The Dev machine

The Dev machine blends web exploitation, file share enumeration, and privilege escalation into one smooth learning curve.

Let me walk you through how this system was compromised step by step. Along the way, I’ll explain the reasoning. 

Reconnaissance

The first step was identifying running services on the target machine. Performed full port scan using Nmap. The scan revealed the following open ports:

PORT      STATE SERVICE  VERSION
22/tcp    open  ssh      OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp    open  http     Apache httpd 2.4.38 ((Debian))
111/tcp   open  rpcbind  2-4 (RPC #100000)
2049/tcp  open  nfs      3-4 (RPC #100003)
8080/tcp  open  http     Apache httpd 2.4.38 ((Debian))
_http-title: PHP 7.3.27-1~deb10u1 - phpinfo()

The system was running OpenSSH 7.9 and Apache 2.4.38 on Debian, confirming a Linux environment. Since SSH required authentication, enumeration focused on web services.

SSH required credentials, so attacking it directly would be pointless… at least for now. That pushed the focus toward web services.

Web Enumeration

Port 80

Opening the website displayed a Bolt CMS installation error page, indicating the presence of Bolt and possible configuration files.

The current folder, /var/www/html/, is a Linux folder, and based on this information, it appears that the machine is running Linux. 

Port 8080

Displayed a PHP info page, which revealed server configuration details and internal paths useful for further enumeration.

Directory Fuzzing

Directory fuzzing helps uncover endpoints developers forget to secure. Using the FuFF tool made this process fast and reliable.

> fuff -w <wordlist_location>:FUZZ -u http://<targetIP>/FUZZ

Fuzzing both ports revealed several directories:

• public
• src
• app
• dev

The /dev directory hosted a BoltWire application. The registration module was enabled, allowing account creation and access to application features.

BoltWire Vulnerability

Researching BoltWire revealed it had a known Local File Inclusion (LFI) vulnerability tied to the print parameter.

Endpoint : http://192.168.22.8:8080/dev/index.php?p=action.search&action=print

By adjusting the request, the /etc/passwd file became accessible. That file exposed a valid system user jeanpaul

The archive contents were extracted and used for further correlation. 

But that wasn’t the only discovery. Several directories also allowed directory listing, exposing configuration files and application details.

NFS Enumeration

Port 2049 indicated the presence of Network File System (NFS). If misconfigured, NFS can expose sensitive data without authentication. 

NFS is a protocol that allows systems to share, mount, and access the files over the network. 

showmount is a tool to see which directories the server has and who is allowed to access them.

Command - > showmount -e <target_IP>
using namp 
Command - > nmap -p 2049 --script nfs-ls,nfs-showmount,nfs-statfs <target_ip>

The showmount tool result revealed a shared directory: /srv/nfs.

Use the Linux built-in mount tool using the below command and look for the available file.

> mount -t nfs 192.168.22.8:/srv/nfs </tmp/nfs_mount>

Inside the share sat a file named save.zip. It looked harmless… Zip files in shared directories, however, are rarely harmless.

Cracking the ZIP File

Attempting to unzip the file required a password. Instead of guessing randomly, the fcrackzip tool helped automate the process using a wordlist.

> fcrackzip -v -u -D -p <location>/rockyou.txt save.zip

-v - Verbose mode
-u - Unzip - try to unzip the file with the password
-D - Dictionary mode.
-p - The path to the the list rockyou.txt
save.zip - the target. 

Discovered password: java101

The archive contents were extracted and used for further correlation.

Configuration Files

An earlier directory listing revealed a configuration file:

app/config/config.yml

Opening this file exposed credential details. These credentials were tested against SSH.

SSH Access - Stepping Inside the System

The password itself didn’t grant direct access, but it worked with an id_rsa private key belonging to the user jeanpaul.

Private keys bypass password authentication and allow secure SSH login.

Using the private key:

ssh -i id_rsa jeanpaul@192.168.22.8

Access was successful. Now the focus shifted to privilege escalation, the phase where attackers attempt to gain root access.

Sudo permissions were checked

sudo -l

showed that the user could run /usr/bin/zip with root privileges without needing a password.

GTFOBins Escalation - Turning Zip into a Root Shell

Some programs, including zip, allow execution of system commands while running. If such a program runs as root → the command you execute also runs as root.

This is known as a GTFOBins privilege escalation technique.

> sudo zip /tmp/test.zip /tmp -T --unzip-command="sh -c /bin/bash"

• sudo - executes the command as root
• zip - starts executing with root privileges
• -unzip-command - forces zip to execute a shell
• /bin/bash - The shell command.

This executed a root shell and completed system compromise.

Just navigate to the flag.txt file, and Game Over. 

Machines like Dev highlight several real-world security mistakes:

• Debug pages should never remain publicly accessible
• Directory listing exposes sensitive files faster than most exploits
• NFS shares require strict access control
• Configuration files often leak credentials
• Sudo permissions must be tightly restricted

Interestingly, none of the individual vulnerabilities felt devastating alone. But together? They created a full compromise chain. 

Happy Hacking!!