HTB Academy — Public Exploits: From Enumeration to Exploitation

Introduction

This module from HTB Academy walks through one of the most fundamental workflows in offensive security — taking a running service, identifying a known vulnerability, and weaponizing a public exploit to extract sensitive data.

The objective is clean:

• Identify services running on the target
• Research public exploits for what’s found
• Configure and execute the exploit
• Retrieve /flag.txt

Simple on paper. The lesson isn’t in the steps — it’s in the thinking between them.

---

Target

154.57.164.74:31158

Target IP rotates per session. Adjust RHOSTS and RPORT accordingly.

---

Step 1 — Reconnaissance

Navigating to the target in a browser is the first move. No scanners yet — just eyes.

Target is running WordPress — with a post explicitly naming the installed plugin version

What we learn immediately:

• CMS: WordPress
• Plugin visible on homepage: Simple Backup Plugin 2.7.10

The target is advertising its attack surface. This is exactly the kind of passive disclosure that saves hours of enumeration.

---

Step 2 — Exploit Research

Before touching Metasploit, validate the attack surface with searchsploit — an offline Exploit-DB query tool.

searchsploit wordpress backup

searchsploit returns multiple WordPress backup plugin vulnerabilities

From the list, one entry is immediately relevant:

WordPress Plugin Simple Backup 2.7.11 - Multiple Vulnerabilities  |  php/webapps/39883.txt

The version matches what’s running on the target. This is the entry point.

---

Understanding the Vulnerability

Before running anything, understand what you’re actually executing.

This is not RCE.

Property	Detail
Type	Arbitrary File Read (Path Traversal)
Root Cause	Backup plugin exposes a file retrieval endpoint with no path validation
Impact	Any server-readable file can be exfiltrated
What it’s NOT	Remote Code Execution

The exploit abuses the plugin’s backup download functionality — it accepts a user-supplied file path and returns the file contents without any sanitization. Classic input trust failure.

Why does this matter in the real world? A single arbitrary file read can leak wp-config.php (database credentials), .env files (API keys), or SSH private keys. File read → credential exposure → full compromise is a well-worn path.

---

Step 3 — Locating the Module in Metasploit

msfconsole

msf6 > search exploit simple backup

Metasploit returns one matching module — exactly what we need

0  auxiliary/scanner/http/wp_simple_backup_file_read  .  normal  No  WordPress Simple Backup File Read Vulnerability

---

Step 4 — Configuration

use auxiliary/scanner/http/wp_simple_backup_file_read

set RHOSTS 154.57.164.74
set RPORT 31158
set FILEPATH /etc/passwd

Module configured — RHOSTS, RPORT, and FILEPATH set correctly

Starting with /etc/passwd is deliberate. It verifies the exploit works before going after the actual target. Always confirm the primitive before chasing the objective.

---

Step 5 — First Exploitation Attempt

exploit

/etc/passwd retrieved — exploit confirmed working

The file comes back. Every system user is visible — root, www-data, mysql, sshd. The exploit works.

But the objective isn’t complete.

/etc/passwd has no credentials useful here. No privilege escalation path. No flag.

This is a technical success and a logical failure — a distinction that separates script runners from actual pentesters.

---

Step 6 — Correcting the Approach

Re-read the objective. The lab told you exactly where the flag is.

set FILEPATH /flag.txt

Then run again:

exploit

Updated FILEPATH — now targeting /flag.txt

---

Step 7 — Flag Retrieved

HTB{my_f1r57_h4ck}

The loot file is saved automatically under /root/.msf4/loot/. Retrieve it with:

cat /root/.msf4/loot/20260329065518_default_154.57.164.74_simplebackup.tra_183427.txt

---

Technical Deep Dive

Exploitation Flow

WordPress Detected
      ↓
Plugin Version Identified (Simple Backup 2.7.11)
      ↓
Exploit-DB / searchsploit → Public PoC found
      ↓
Metasploit Module → auxiliary/scanner/http/wp_simple_backup_file_read
      ↓
Arbitrary File Read via unvalidated FILEPATH parameter
      ↓
/flag.txt → HTB{my_f1r57_h4ck}

Real-World Attack Chain

In a live engagement, this vulnerability chain looks like this:

File Read → /wp-config.php → DB Credentials
         → .env            → API Keys / Secrets
         → ~/.ssh/id_rsa   → SSH Private Key → Lateral Movement

Files worth targeting after achieving file read:

File	What’s Inside
/wp-config.php	Database host, name, username, password
/etc/shadow	Hashed system passwords (requires root read)
/home/*/.ssh/id_rsa	SSH private keys for lateral movement
/.env	Application secrets, cloud credentials

---

Key Takeaways

1. Tools don’t think — you do. Metasploit executes what you configure. If you point it at the wrong file, it returns the wrong answer perfectly.

2. Exploitation ≠ objective completion. Getting /etc/passwd feels like a win. It isn’t. Always map every action back to the stated objective.

3. Context awareness is a skill. The lab named the flag path explicitly. Missing it is a reading problem before it’s a hacking problem.

4. File read vulnerabilities are underestimated. They consistently lead to credential exposure and, from there, to full system compromise. Do not treat them as low-severity findings.

---

Going Further

Don’t stop at the flag. Use the file read to build a fuller picture of the target:

set FILEPATH /wp-config.php
set FILEPATH /etc/shadow
set FILEPATH /home/www-data/.ssh/id_rsa

The box is solved when you have the flag. The skill is built when you understand every file you touched and why.

---

References

• Hack The Box Academy — Public Exploits Module
• Exploit-DB — WordPress Simple Backup 2.7.11
• Metasploit Framework Documentation