Post cover image

July 25, 2026

The Planets: Earth — A Complete Penetration Testing Walkthrough (VulnHub)

Introduction

By Prerna Bhamre

7 min read

Introduction

Every penetration test follows a structured methodology — from identifying the target and discovering potential attack surfaces to exploiting vulnerabilities and assessing the system's security. Hands-on labs provide an excellent way to develop these practical skills in a safe and controlled environment.In this walkthrough, we'll perform a complete penetration testing assessment of The Planets: Earth, a vulnerable machine from VulnHub. We'll follow the complete penetration testing lifecycle, from reconnaissance and enumeration to exploitation and privilege escalation.Rather than simply listing commands, this article explains the purpose behind each step, the tools used, the vulnerabilities identified, and the key concepts learned throughout the assessment.

Lab Environment

The penetration testing assessment was performed in a controlled virtual lab environment using Oracle VirtualBox. The target machine, The Planets: Earth, was deployed from VulnHub, while Kali Linux was used as the attacker machine throughout the assessment.

The objective of the assessment was to identify and exploit vulnerabilities by following a structured penetration testing methodology, progressing from reconnaissance and enumeration to exploitation and privilege escalation until root access was obtained.

🔶Environment Configuration

Platform :- VulnHub

**Target Machine:-**The Planets: Earth

**Attacker Machine:-**Kali Linux

**Virtualization Software:-**Oracle VirtualBox

**Network Configuration:-**VirtualBox Host-Only Adapter

**Assessment Type:-**Black-Box Penetration Testing

🔶Tools Used

The following tools were used during the assessment:

  • Nmap — Host discovery, port scanning, and service enumeration.
  • Gobuster — Directory and virtual host enumeration.
  • CyberChef — Decoding encoded data.
  • SSH — Secure remote access.
  • Linux Utilities — Commands such as find, cat, grep, strings, and sudo for enumeration and privilege escalation.

Methodology

🔶Phase 1 — Reconnaissance

The first phase of the assessment focused on identifying the target machine and gathering information about the exposed network services.

Step 1: Identifying the Attacker's IP Address

Before interacting with the target machine, I verified the IP address assigned to the Kali Linux attacker machine.

Command

ip a
None

Observation: The command displayed the available network interfaces and the IP address assigned to the Kali Linux machine, confirming that the attacker system was correctly connected to the virtual network.

Step 2: Discovering the Target Machine

After verifying the attacker machine, I scanned the local network to identify the IP address of the vulnerable machine.

Command

sudo arp-scan --localnet
None

**Observation:**The scan identified the IP address of The Planets: Earth virtual machine, which was used for all subsequent enumeration and exploitation activities.

Step 3: Initial Port Scan

Once the target IP address was identified, an Nmap scan was performed to enumerate the open ports and running services.

Command

nmap -sC -sV <Target_IP>
None

**Observation:**The scan revealed multiple open ports, including 22 (SSH), 80 (HTTP), and 443 (HTTPS), providing the initial attack surface for further enumeration.

🔶Phase 2 — Web Enumeration

After identifying the available services, the next step was to enumerate the web application for hidden resources and sensitive information that could assist in further exploitation.

Step 1: Configuring the Virtual Hosts

During the service enumeration phase, the SSL certificate revealed two hostnames: earth.local and terratest.earth.local. Since these virtual hosts were not publicly resolvable, they were manually added to the local hosts file.

Command

sudo nano /etc/hosts

Entry Added

192.168.124.5    earth.local    terratest.earth.local

Observation

After updating the hosts file, both virtual hosts became accessible, allowing further enumeration of the web application.

Step 2: Enumerating Hidden Resources

With the virtual hosts configured, the next step was to inspect publicly accessible files exposed by the web server.

Commands

curl -k https://terratest.earth.local/robots.txt
curl -k https://terratest.earth.local/testingnotes.txt
curl -k https://terratest.earth.local/testdata.txt

To save the test data locally:

curl -k -s https://terratest.earth.local/testdata.txt -o testdata.txt
None None

**Observation:**The exposed files revealed several important findings:

  • The application used repeating-key XOR for encryption.
  • The administrator username was identified as terra.
  • A known plaintext file (testdata.txt) was publicly accessible.

These findings provided the information required to recover the administrator credentials in the next phase.

🔶Phase 3 — Recovering Administrator Credentials

The information gathered during the web enumeration phase revealed that the application used repeating-key XOR encryption and exposed a known plaintext file (testdata.txt). Using these findings, the administrator password could be recovered through a known-plaintext XOR attack.

Step 1: Preparing the Encrypted Password

The encrypted administrator password was saved locally for analysis.

Command

nano cipher.txt

To verify the encrypted data:

head -c 40 cipher.txt

**Observation:**The password was stored as hex-encoded ciphertext. Since XOR encryption is reversible when the correct key is known, the previously downloaded testdata.txt could be used to recover the original password.

Step 2: Recovering the Administrator Password

A Python script was used to decrypt the ciphertext using the known plaintext.

Python Script

from pathlib import Path
cipher = bytes.fromhex(Path("cipher.txt").read_text().strip())
key = Path("testdata.txt").read_bytes().strip()
plain = bytes(c ^ key[i % len(key)] for i, c in enumerate(cipher))
print(plain.decode(errors="replace"))
None

Output

Username : terra
Password : earthclimatechangebad4humans

**Observation:**The XOR recovery process successfully revealed the administrator credentials, providing authenticated access to the web application's admin portal.

🔶Phase 4 — Initial Foothold

Using the recovered administrator credentials, the next step was to authenticate to the web application's admin portal and verify whether command execution was possible on the target system.

Step 1: Logging into the Admin Portal

The recovered credentials were used to access the administrator portal.

URL

https://earth.local/admin/

Credentials

Username: terra
Password: earthclimatechangebad4humans
None

**Observation:**Authentication was successful, revealing an Admin Command Tool that allowed authenticated operating system command execution.

Step 2: Verifying Command Execution

To confirm code execution and identify the execution context, the following commands were executed through the Admin Command Tool.

Commands

whoami
hostname
uname -a
None

Output

whoami
apache

hostname
earth

uname -a
Linux earth 5.14.9-200.fc34.x86_64

**Observation:**The commands confirmed that code execution was occurring as the apache user on the Earth machine. Since the current user had limited privileges, privilege escalation was required to gain full system access.

Step 3: Retrieving the User Flag

To verify user-level compromise, the filesystem was searched for flag files.

Commands

find / -type f -iname '*flag*' 2>/dev/null
ls -la /var/earth_web
cat /var/earth_web/user_flag.txt
None None

Output

[user_flag_3353b67d6437f07ba7d34afd7d2fc27d]

**Observation:**The user flag was successfully retrieved, confirming user-level access to the target system.

🔶Phase 5 — Privilege Escalation

Although command execution was achieved through the Admin Command Tool, it was running with the privileges of the apache user. The next objective was to identify a privilege escalation vector to obtain root access.

Step 1: Enumerating SUID Binaries

The first step was to identify SUID binaries that could potentially be exploited for privilege escalation.

Command

find / -perm -4000 -type f 2>/dev/null
None

**Observation:**Among the standard SUID binaries, a non-standard binary named /usr/bin/reset_root was identified, making it the primary target for further analysis.

Step 2: Analyzing the reset_root Binary

To understand the functionality of the binary, the strings command was used to extract readable text.

Command

strings /usr/bin/reset_root
None

**Observation:**The extracted strings revealed that the binary:

  • Checked for three specific trigger files.
  • Reset the root password to a hardcoded value (Earth) if all trigger files existed.
  • Used locations under /dev/shm and /tmp, which are writable by non-privileged users.

Step 3: Creating the Trigger Files

Based on the information extracted from the binary, the required trigger files were created.

Commands

touch /dev/shm/kHgTFI5G
touch /dev/shm/Zw7bV9U5
touch /tmp/kcM0Wewe

**Observation:**All three trigger files were successfully created, satisfying the conditions required by the reset_root binary.

Step 4: Executing the SUID Binary

After creating the trigger files, the SUID binary was executed.

Command

/usr/bin/reset_root
None

Output

CHECKING IF RESET TRIGGERS PRESENT...
RESET TRIGGERS ARE PRESENT, RESETTING ROOT PASSWORD TO: Earth

**Observation:**The binary detected the trigger files and successfully reset the root password to Earth, completing the privilege escalation process.

🔶Phase 6 — Root Access

With the root password successfully reset, the final step was to verify administrative access and retrieve the root flag, confirming complete compromise of the target system.

Step 1: Verifying Root Access

The reset root password was used to switch to the root account and verify administrative privileges.

Command

echo Earth | su -c 'id'
None

Output

uid=0(root) gid=0(root) groups=0(root)

Observation: The output confirmed successful privilege escalation, indicating that full administrative (root) access had been obtained.

Step 2: Retrieving the Root Flag

With root access confirmed, the final objective was to retrieve the root flag.

Command

echo Earth | su -c 'cat /root/root_flag.txt'
None

Output

[root_flag_b0da9554d29db2117b02aa8b66ec492e]

Observation: The root flag was successfully retrieved, confirming the complete compromise of the The Planets: Earth virtual machine.

Key Takeaways

This machine demonstrated how multiple seemingly minor weaknesses can be combined to achieve full system compromise. Throughout the assessment, the following concepts were explored:

  • Network reconnaissance and service enumeration using Nmap.
  • Virtual host discovery through SSL certificate analysis.
  • Web enumeration using curl and exposed resources.
  • Recovering credentials through a known-plaintext XOR attack.
  • Gaining an initial foothold via the web application's Admin Command Tool.
  • Identifying and exploiting an insecure SUID binary for privilege escalation.
  • Verifying root access and successfully retrieving the root flag.

This walkthrough highlights the importance of proper information disclosure controls, secure credential management, and regular auditing of privileged binaries to prevent privilege escalation vulnerabilities.

Conclusion

Completing The Planets: Earth from VulnHub was an excellent hands-on learning experience that reinforced the importance of following a structured penetration testing methodology. Throughout this assessment, I progressed through each phase of the engagement — from reconnaissance and enumeration to credential recovery, initial access, privilege escalation, and finally achieving root access.

This walkthrough also provided practical experience with tools and techniques such as Nmap, cURL, virtual host enumeration, known-plaintext XOR password recovery, Linux command execution, and SUID-based privilege escalation. More importantly, it demonstrated how multiple seemingly minor vulnerabilities can be chained together to achieve complete system compromise.

I hope this walkthrough serves as a useful learning resource for others exploring penetration testing through hands-on labs. If you have any suggestions, feedback, or alternative approaches to solving this machine, I'd be happy to hear them.

Thank you for reading, and happy learning!