Overview

This engagement documents a closed-environment assessment of a Metasploitable web server target using the Greenbone Vulnerability Manager (GVM) to discover, validate, and then using Nmap and rsh-client to exploit a remote command service vulnerability. It also reviewed suggested remediations; the exercise demonstrates a full scanner-to-exploit workflow that mirrors how an attacker might validate findings from an automated scan in a real environment.

The Challenge

Identify exploitable services reported by GVM, confirm the findings using active reconnaissance, and where feasible demonstrate the impact of an uncovered vulnerability by obtaining a remote shell and escalating privileges, while keeping all actions repeatable and well-documented for remediation guidance. The project focused on a running rexec service discovered by the scanner and on lateral information available via SMB that could yield credentials.

The Approach

I followed a methodical three-part approach that mirrors professional test practices: run a full authenticated/unauthenticated scan with GVM to discover and prioritize issues, perform targeted active reconnaissance with Nmap to validate and enrich findings, and execute a conservative, documented exploit using standard system clients to confirm impact and collect remediation evidence, all while capturing the exact commands and outcomes for reproducibility.

Tools used

• GVM (Greenbone Security Assistant): vulnerability discovery and reporting via web UI.
• Nmap: service and script-based reconnaissance (smb-brute).
• rsh-client (remote shell client): used to interact with a vulnerable rexec service
• Kali Linux: attacker platform hosting the scanner, tools, and commands.
• Metasploitable: intentionally vulnerable target VM used for validation.

The Execution

Part 1: Scan a Host for Vulnerabilities

Start the GVM services

I started the scanner services with sudo gvm-start so the GVM background daemons and web interface were running on the Kali host and available at the local HTTPS endpoint for the next steps; this ensures the scanner is ready to accept tasks and generate reports.

When the command completes the Greenbone Security Assistant UI becomes reachable at https://127.0.0.1:9392, or if the command reports that services are already running; this confirms the environment is prepared to create and execute scanning tasks.

Log in to the Greenbone Security Assistant UI

I opened the browser to https://127.0.0.1:9392 and authenticated to gain the UI access required to create tasks and run scans; this is the standard web GUI entry point for task configuration and report access.

Successful authentication confirms the GVM server is responsive and that I can create scanning tasks and retrieve the generated reports that will enumerate discovered vulnerabilities.

Create and run an advanced scan task for the Metasploitable host

I used the GVM GUI: selected Scans → Tasks, launched the Task Wizard → Advanced Task Wizard, created a task named Metasploitable with 172.17.0.2 in the Target Host(s) field, and started the task so the scanner would perform the configured NVTs (network vulnerability tests) against the target and generate a results report. (The UI path used was Scans -> Tasks -> Task Wizard -> Advanced Task Wizard, Target 172.17.0.2).

The task appears in the Tasks window and shows a progress indicator; once the status reaches Done (100%) a report entry is added to the Reports column from which vulnerability findings and NVT details can be inspected. This is the canonical way to create repeatable scan runs in GVM.

Open the generated report and identify high-priority findings

I opened the report by clicking the report count for the Metasploitable task, inspected the Results list, and focused on high severity entries such as The rexec service is running and other top items to prioritize follow-up reconnaissance and validation. (Open the report and click the The rexec service is running finding.)

The report provides an aggregated list of findings with insight and solution text; selecting a finding reveals the associated CVE and NVT details that explain how the vulnerability was detected and offers remediation suggestions used later for mitigation.

Inspect the CVE and NVT details for the rexec finding

I clicked the CVE linked to the rexec finding and then the underlying NVT reference in the CVE window to view the precise detection logic and contextual notes so I could understand the exposure, which ports the service uses (typically TCP 512, 513, 514), and recommended mitigation. (Click CVE, then NVT.)

The CVE/NVT view clarifies that the rexec service was detected listening on its canonical ports and provides recommended mitigation actions such as disabling the service and using secure alternatives like SSH, which informs the remediation guidance.

Part 2: Exploit a Vulnerability Found by GVM

Perform targeted reconnaissance with Nmap using the smb-brute script

I executed sudo nmap -sV -p 445 -script smb-brute 172.17.0.2 to enumerate SMB accounts and attempt common credentials because SMB user lists and weak/default credentials can map to system accounts usable against other services like the found rexec vulnerability in the gvm scan.

The Host script results section of the nmap output lists username and password pairs such as msfadmin/msfadmin and user/user, which are high-value leads because credentials discovered via SMB often work for other services on the host.

Install the remote shell client (rsh-client) on Kali

I installed the remote shell client with sudo apt install rsh-redone-client to obtain a standard rsh binary so I could directly attempt authentication to the rexec service using credentials discovered during the SMB enumeration. sudo apt install rsh-redone-client

Installing rsh-client provides the client utility required to interact with a rexec/rsh service from the Kali machine; without it the next step to validate the rexec service would not be possible locally.

Use rsh to authenticate to the target as msfadmin

I launched rsh -l msfadmin 172.17.0.2 to connect to the target rexec service using the msfadmin account uncovered earlier, so I could obtain an interactive remote shell and validate whether the service allowed remote command execution without additional controls. rsh -l msfadmin 172.17.0.2

The login succeeded and the shell prompt changed to the remote user (msfadmin@metasploitable), confirming that the rexec service accepted the credentials and provided remote command execution capability. This validates the scanner finding at the exploitation level.

Confirm remote working directory with pwd

I ran pwd at the remote prompt to quickly confirm the session context and confirm that I was executing commands in the expected user environment /home/msfadmin, which helps orient follow-up actions and privilege escalation attempts. pwd

The output /home/msfadmin indicates the session is an interactive shell tied to the msfadmin account and permits subsequent local commands and privilege escalation attempts under that user context.

Escalate privileges to root with sudo su

I attempted sudo su at the remote prompt and provided the msfadmin password discovered earlier to elevate privileges, which succeeded and yielded a root shell root@metasploitable:/home/msfadmin#, demonstrating a full compromise when combined with the initial remote execution vector. sudo su then password msfadmin

Receipt of a root shell confirms the practical impact of the vulnerability: an attacker who can authenticate via rexec using a valid account can fully compromise the host by performing local privilege escalation with common sudo policies; this is a critical validation that converts an informational scanner finding into a high-impact exploit scenario.

Cleanly exit the session and confirm connection closure

I typed exit twice to drop from the root shell to the remote user and then close the remote connection, ensuring a clean end to the test session and predictable artifact generation in logs. exit

Exiting the shell closes the remote session and simulates an attacker finishing their interaction; it also leaves the system in a known state for subsequent validation or remediation scans.

The outcomes, lessons learned, and relevance to cybersecurity

• Outcome: The GVM scan successfully identified the rexec service; targeted reconnaissance with Nmap revealed valid credentials; use of the standard rsh client validated remote execution and a sudo su escalation yielded a root shell on the Metasploitable target, demonstrating that the vulnerability is exploitable in practice.
• Lessons learned:
• Automated scanners are valuable for discovery and prioritization but must be followed by focused reconnaissance to validate findings and identify attack paths.
• Credential reuse and weak/default credentials are common escalation enablers; discovering a valid account through one service (SMB) can enable exploitation of another (rexec).
• Services that permit unauthenticated or weakly authenticated remote command execution are high-risk and should be replaced with secure alternatives or removed. Mitigation recommendation is to disable rexec and prefer SSH for remote administration.
• Practical remediation recommendations :
• Immediately disable rexec/rsh services on production systems and block TCP ports 512, 513, and 514 at network boundaries where not required.
• Enforce unique, strong passwords and implement centralized authentication with multifactor authentication where possible to prevent credential reuse across services.
• Re-scan the host with GVM after remediation to confirm removal of the NVT findings and to ensure no other high severity findings remain.