DC4 Walkthrough

DC4 continues the boot2root “DC” series of virtual machines and is intentionally built for penetration-testing practice. Rated Easy, it’s aimed at beginners. Unlike earlier DC releases, the authors say this VM contains a single flag, provides no clues, and offers multiple possible paths to reach the flag which is often found in the /root directory. You can download DC4 VM from Vulnhub by clicking here.


My setup is straightforward. My host is running Windows 11 VMware Workstation Pro with Kali Linux VM (bridged mode) as the attacker and DC4 VM (bridged mode) as the victim.

Using netdiscover the IP of the target host is 192.168.0.151. According to nmap, the target has two open ports 80 (nginx) and 22 (OpenSSH).

While browsing to http://192.168.0.151, I came across a login form labeled “Admin Information Systems Login.” I attempted several common credential combinations such as admin:admin, admin:password, administrator:administrator, and administrator:password, but none were successful. Next, I ran dirb to see if I could uncover any interesting hidden directories or files.

dirb http://192.168.0.151 -X .php /usr/share/wordlists/dirb/big.txt

I ran dirb using both the default wordlists and a larger custom wordlist, but neither produced additional results. When accessing /command.php, /login.php, or /logout.php in Firefox, I’m immediately redirected back to /index.php. To investigate what’s happening behind the scenes, I captured the traffic using Burp Suite. This confirmed that requests to /login.php, /logout.php, and /command.php all return an HTTP 302 redirect back to /index.php.

While visiting /command.php, I noticed that before being redirected to /index.php, a form briefly appears. This form has three radio button options that allow the user to select one of the following system commands: ls -l, du -h, or df -h. As mentioned, it also displays the message: “You need to be logged in to use this system.”

I suspect that /command.php may be vulnerable to Local File Inclusion (LFI). To test this, I plan to send a POST request to /command.php with the following data: radio=pwd&submit=Run to determine whether the endpoint is susceptible to LFI.

LFI /command.php: “You need to be logged in to use this system”

Unfortunately, the Local File Inclusion (LFI) attempt was unsuccessful because the application requires a user to be logged in. I spent additional time exploring the application and testing various endpoints but was unable to identify any other vectors or interesting functionality at this stage. This indicates that, without valid credentials, further exploitation is limited—unless, of course, I missed something.


I decided to attempt a brute-force login. To start, I selected three common usernames—administrator, admin, root and used rockyou.txt as the password wordlist.

While I usually prefer Burp Suite Intruder, the Community edition has limitations that deliberately slow down brute-force attempts. For form brute-forcing, I opted for wfuzz, which is fast and straightforward once configured. I created a text file containing the three usernames, set up wfuzz with rockyou.txt as the password list, and let it run.


About an hour later …

I ran rockyou.txt against the usernames root and administrator first, and then tested admin. The correct credentials were found almost immediately with the admin username. The password corresponds to the 463rd entry in the rockyou.txt wordlist and is "happy", as shown in the screenshot above.

After logging in with credentials admin:happy, there is a link called command which takes me to /command.php. As you can see from the screenshot below there are three options a user can choose from List Files, Disk Usage, and Disk Free.

After obtaining credentials, I revisited the Local File Inclusion (LFI) vector that previously required authentication. While logged in, I selected “List Files” and submitted the request; I intercepted the request/response in Burp Suite and forwarded the request to Repeater for manual manipulation and further testing. This lets me tamper with the parameters and observe server behavior to determine whether an LFI exists and, if so, to safely attempt to read sensitive files.

As you can see from the screenshots above, /command.php is vulnerable to local file inclusion where I was able to read /etc/passwd on the target. Next, I need to figure out how I can take advantage of LFI and obtain a reverse shell on the target. My thought process is to see if python is installed on the target, if so, I can use it to obtain a reverse shell.

By sending radio=python -c ‘print(“Hello World!”);’&submit=Run as the POST data, I verified that the target has python installed. One of the easiest ways to get a reverse shell is using python modules subprocess, os, and socket.

The code for reverse shell can be seen on the screenshot above. Before sending the request I started netcat listener with the following command “nc -lvnp 1337”. After sending the request I got a reverse shell on the target.

After obtaining a reverse shell, I immediately upgraded it to a proper TTY to regain full interactivity. If you’re not familiar with the distinction: a non-TTY shell lacks features like tab completion, command history, password prompts, and proper support for interactive tools such as sudo, ssh, passwd, less, or top. A TTY shell restores those capabilities and makes command-line work far more reliable, for example, you can upgrade a basic shell with a common one-liner like:

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

With a reverse shell on the target, my next goal was privilege escalation to read the flag in /root. Inspecting the filesystem revealed three non-root accounts: charles, jim, and sam. In jim’s home I found a potentially valuable file: /home/jim/backups/old-passwords.bak, which appears to be a password list. It’s plausible one of those entries is a valid password for charles, jim, or sam.

I could manually attempt each password against each account, but the list contains 252 entries testing all three accounts exhaustively would require up to 756 attempts. Since SSH is available on the target, a more efficient approach is to perform an automated dictionary attack using the old-passwords.bak wordlist against the usernames charles, jim, sam (and optionally root), which should substantially reduce manual effort and speed up discovery.

Next, I fired up hydra with the following command:

hydra -L users -P old-passwords.bak ssh:\\192.168.0.151

where file users contains charles, jim, sam and old-passwords.bak is self-explanatory.

As you can see from the screenshot above the only valid credentials found is jim:jibril04. The good news is that I no longer have to use the reverse shell and can login directly using SSH. I did just that, logged in via SSH with jim:jibril04 as the credentials.

Now that I am logged in as user jim I can now read the file called mbox which only allowed the owner (jim) to read it.

After reading the contents of mbox I recognized that it appears to be headers and contents of an e-mail between users hence Return-path: <root@dc-4>. I already know the e-mails between users are stored in /var/mail directory.

It appears that the mbox file was simply a hint to examine /var/mail for potential messages between users. As shown in the screenshot above, charles emailed jim his password while on holiday. After logging in as charles, my first step, as usual, was to review the user’s sudo privileges.

As shown in the screenshot above, charles can execute the binary /usr/bin/teehee as root without a password. I wasn’t initially familiar with a command called teehee on Linux, but after running it, it appears to be a simple wrapper or renamed version of the standard tee command, which reads from standard input and writes to standard output.

According to the VM author, there are multiple ways to escalate privileges and access the root flag. In this instance, I leveraged /usr/bin/teehee to execute arbitrary commands as root. Specifically, I used it to add the user charles to the sudoers configuration by creating a file in /etc/sudoers.d/charles, thereby granting charles full root privileges. This method effectively allowed me to escalate to root and ultimately access the flag. See the screenshot below for reference.

I verified that I can execute any command as root by successfully reading the /etc/shadow file on the target. While it would be possible to attempt cracking the root password using the obtained hash, doing so is unnecessary in this scenario. The primary objective is to gain root-level access to run commands and ultimately read the flag in the /root directory, which I am already able to accomplish. All that is left to do is read the flag in the /root directory.

You may not always
end up where you
thought you
were going.

But you will always
end up where you
were meant to be

Pwning the box and
gaining root access