Rooting DC-4: Brute Force, Leaked Mail, and a Custom Sudo Binary

No CMS this time. Just a login form, a chain of recovered credentials, and one unusual sudo rule that gives away the whole box.

DC-4 trades CMS exploitation for something more procedural: brute forcing, credential reuse, and a privilege escalation path that comes from a single misconfigured sudo entry rather than a public CVE. If DC-3 was about staying with one target long enough to break it, DC-4 is about following a trail of leaked credentials from one account to the next until root falls out at the end.

Here is how I got from an open port scan to root on DC-4.

Target: DC-4 (VulnHub), OS: Debian, Difficulty: Beginner

Step 1: The Basics

With dc-4 already mapped in my hosts file, I scanned by hostname.

nmap -p- -sC -sV -T5 dc-4

22/tcp open  ssh     OpenSSH 7.4p1 Debian 10+deb9u6
80/tcp open  http    nginx 1.15.10
|_http-title: System Tools

SSH and a web server calling itself “System Tools.” Nothing exotic yet, just two doors to check.

Step 2: Mapping the Web App

feroxbuster -u http://dc-4 -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt

A second pass with DirBuster confirmed the same handful of pages: index.php, login.php, logout.php, and command.php. That last one, sitting next to a login form, was the giveaway. Whatever was behind that login almost certainly let an authenticated user run commands.

Step 3: Brute Forcing the Front Door

The site’s title, “System Tools,” made admin a safe first guess for the username. I pointed Hydra directly at the login form.

hydra -l admin -P /usr/share/wordlists/rockyou.txt dc-4 http-post-form "/login.php:username=^USER^&password=^PASS^:S=logout"

It came back with a hit: admin : happy.

Step 4: Turning a UI Into a Command Line

Logging in dropped me into a panel with a set of radio-button options tied to system commands. Instead of clicking through the UI, I intercepted the requests in Burp Suite so I could edit the underlying command parameters directly. One small but important detail: spaces in the injected values had to be URL-encoded as +, or the request would silently fail to process.

Listing the home directory turned up three accounts: charles, jim, and sam.

Step 5: A Password File Left Behind

Poking through jim's home directory surfaced a leftover backup file:

cat+/home/jim/backups/old-passwords.bak

A list of old passwords, still sitting there. I saved it locally and paired it with the three known usernames for the next brute force attempt.

Step 6: SSH Falls to a Small, Targeted List

hydra -L dc4-users -P /usr/share/wordlists/dc-4 dc-4 ssh

[22][ssh] host: dc-4   login: jim   password: jibril04

One match. A small, relevant wordlist beat a generic one here, purely because it was built from data the target itself had leaked.

Step 7: Checking the Mail

Logging in as jim over SSH greeted me with "You have mail." That is not a message to ignore.

cd /var/mail
cat jim

Inside was a message from charles, sent before he apparently went on holiday, handing over his password directly in plaintext:

Password is:  ^xHhA&hvim0y

Sometimes the biggest vulnerability in a system is a coworker with good intentions and bad judgment about where to put a password.

Step 8: A Custom Binary With Root Access

Switching to charles, I checked what he was allowed to run with elevated privileges.

sudo -l

(root) NOPASSWD: /usr/bin/teehee

teehee was not a binary I recognized by name, but its --help output made it clear: it behaves like tee, supporting writes and appends to files. Root access, no password, and the ability to append to any file. That combination is enough on its own.

Step 9: Writing Root Into Existence

Rather than looking for a more complicated escalation path, I used teehee to append a new, fully privileged user directly into /etc/passwd:

echo "lemon::0:0::/bin/bash" | sudo teehee -a /etc/passwd

A UID of 0 makes a user root in every way that matters, regardless of username or password. Switching to it confirmed that:

su lemon

Root, instantly.

Step 10: The Final Flag

cd /root
cat flag.txt

An ASCII banner and a closing thank-you from the box’s author. Machine complete.

What Would Actually Fix This

• Rate-limit login attempts on both the web application and SSH. Neither brute force here required more than a standard wordlist and no throttling to succeed.
• Delete old credentials instead of archiving them. A file named old-passwords.bak should never exist on a production system, and if it must, it should not be readable by other users.
• Never send passwords over email, even between coworkers who trust each other. A password manager or a proper one-time secret share removes this risk entirely.
• Treat any sudo rule on a file-writing binary as equivalent to full root access. tee, or any tool built on the same idea, can rewrite /etc/passwd or /etc/shadow directly. NOPASSWD access to anything like this should never be granted casually.
• Monitor /etc/passwd for unexpected UID 0 entries. This is one of the simplest and most detectable signs of exactly this kind of escalation.

Takeaways

DC-4 does not lean on a single flashy exploit. Instead, it strings together a series of small, very human mistakes:

• A weak, brute-forceable admin password.
• An old password file that should have been deleted.
• A password shared over email instead of a proper channel.
• A sudo rule granted to a tool without thinking through what it could actually do.

None of these individually require deep technical skill to exploit. What they do require is patience: following each credential to the next account, checking the mail spool instead of skipping past it, and reading --help output carefully enough to realize an unfamiliar binary is dangerous. That is a more accurate picture of how a lot of real internal networks get fully compromised than any single CVE ever is.

Thanks for reading, DC-5 is next.