CTF WriteupsVulnhub Writeups

DC-1 vulnhub walkthrough

Vulnhub vulnerable machines

DC-1: 1 Vulnhub Walkthrough


Today, I published a new article for vulnhub walkthrough VMs. The article will be for “DC-1: 1” machine which was published last week (You can download it from the following link : https://download.vulnhub.com/dc-1/DC-1.zip ).

In this article you will learn the following:

  • Using nmap to find opened ports & running services.
  • Detecting technologies used to build web apps.
  • Checking robots.txt file.
  • Searching & using public exploits.
  • Uploading shell to drupal CMS.
  • Creating reverse shell using ncat (nc).
  • Privilege escalation using SUID binaries.
  • Collect important information from PHP configuration files.
  • Cracking Linux credentials.

After downloading and importing the OVA file to my virtualization software, I started both “DC-1: 1” & “Kali Linux”. Then, using nmap ping scan I got the IP address for my current target (DC-1: 1), which is

Then I start scanning all opening ports and running services and I got the it has only 3 open ports and running services (22 –> SSH, 80 –> HTTP , and 111 –> RPC). The current version of SSH server is not vulnerable. So, I have to enumerate and scan the HTTP service.

By viewing the hosted website in Firefox, I got that it uses drupal CMS which is one of the well-known used CMS in the wild.

To be sure, I used “whatweb” tool to check the web technologies in the back-end application and it retrieved that it used “Drupal 7”.

Back to nmap scan, I got that the website has “robots.txt” file and the file contains a lot of information about the back-end directory structure for the website.

One of the most important files in drupal is “CHANGELOG.txt” file, which contains information about the current version of Drupal. But I was not lucky, because the file was not available (deleted or renamed).

Since, I don’t have information about the exact version for drupal website. I decided to check the all the available exploits in exploit-db website. “Kali Linux” has an offline version of this website database and we can use “searchsploit” tool to search in the database.

Using this tool and searching for “drupal 7” (we get from whatweb that the website is using on of the 7th version of drupal CMS) we got the following exploits:

As I mentioned in my one of my previous articles (https://hackingresources.com/rootthis-1-walkthrough/), drupal has “drupalgeddon” v1, v2, and v3 which they previously discovered and lead to RCE (Remote Code Execution). We can try them one by one, but I used the first one “34992.py” which is used to exploit and SQLi (SQL Injection) to add a new admin account to the drupal website.

The exploit succeeded and added the user as follows:

On the other hand, there is available exploits for those vulnerabilities in metasploit framework, but as mentioned before I prefer not to use metasploit in my write-ups to help those who want to pass OSCP exam.

I used the credentials to login as administrator. Then I tried to add to install new module which allow me to get a shell on the back-end server. There is module that can provide me with this functionality which is https://www.drupal.org/project/shell .. I installed and enabled version 7.x-1.0-beta5 of this module as follows:

I found the “Shell” url in the Navigation menu. After visiting it, I can run commands on the back-end server. So, I decided to get a reverse shell to my “Kali Linux” machine using “nc” utility and I got the shell 😀 …

Now, I start checking for rooting the server. There are many techniques to do that. One of them is searching for the binaries owned by the root user and has “suid”, which is a feature in Linux that allows users to execute files with the permissions of a specific user.

To search for files that has we run “find / -perm /4000” command. I found interesting thing 😀 .. The “find” command has suid and owned by root user. Also, the “find” command” has “-exec” option, which can be used to run commands.

So, we run the following find command to get a shell with “root” user privileges and we can read the flag in root home directory.

Wait, the flag name “thefinalflag.txt” means that there are many flags in this machine. So, I searched for the files with their names start with “flag” word and found that their are flag1.txt and flag4.txt file. So, were are the other flags (flag2 & flag3)???

I opened “flag1.txt” and found a hint inside it about the config file. In drupal, the config file located in sites/default directory with “settings.php” name. So, I opened it and found the second flag.

The second flag gives me a hint. So, I tried to login to mysql using the drupal database credentials then extract the data from users table and try to crack them using hashcat since it has an option to crack drupal7 hashes. Since I do not have VGA which supports using its GPU for processing I can not crack it (it will take more than 15 days to crack using rockyou.txt word-list).

After searching, I found the third flag “flag3” in the one of pages in admin area.

The fourth flag “flag4.txt” can be read easily as in the previous images.

Finally, I found that I rooted and hacked the machine in an unattended way. The attended way as I guessed will be as follows :

1- Using metasploit or any other exploits which gives you a reverse shell (without logging-in to drupal).

2- Read flag1.txt file.

3- Read settings.php file.

4- Login to mysql database.

5- Extract users table information.

6- Crack users passwords using hashcat.

7- Login using the cracked passwords to drupal admin area.

8- Find the third flag which will give you a hint.

9- Return back to the reverse shell and try to read the fourth flag (flag4.txt) using the find command.

10- Read flag4.txt using find command and then read the thefinalflag.txt (but first, we have to list the /root directory contents) using the same methods.

By the way, reading the contents of both /etc/passwd & /etc/shadow and using john the ripper with rockyou.txt word-list can crack the password for flag4 user (password = orange).

I hope that you learn something new by reading this article. Do not miss to share it with your friends and provide us with your feedback in the comments.

Wait us for the next walkthrough 😀 ..


Related Articles


  1. You could have also generated a new hash via the /scripts/password passing it any password you’d like and updated the admin password within the database rather than taking all that time in hashcat.

    1. That’s true. But in real world scenarios you have to crack or trying to crack the hashes, because this will made you more stealthy and helps you to dig more an more in your target..

      Thanks for your comment..

  2. Hi Mohammed,

    I really appreciated the write up. I have zero pentest experience and was able to follow along with almost zero hassle. I went through a different walkthrough using the metasploit route before finding this write up and personally enjoyed this one much more. It gave better insight into what was happening.

    Thanks again,


Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button