TryHackMe — CMesS is a medium rated room. Though it is not that difficult but definitely helped me to a few more steps while performing a pentest.

So, let’s begin!

Initial Enumeration

The first that we need to do after starting the machine is to add the IP address to /etc/hosts.

We can now start an nmap scan to check all the open ports, services and other details, and meanwhile we check if there is something is on port 80 as this is related a CMS.

Now, because we have added an entry in the /etc/hosts file, we can directly access the webpage at cmess.thm which would land on a page like this:

Just by a single glance we can say that the server is running a Gila CMS which also appears to be pretty old because of the copyright 2017 in the footer. So, we can look for relevant exploits using searchsploit:

There are multiple exploits available here but for some of them we need to be logged in first and some of the others don’t work properly (I tried each one of them but none worked). So, we need to look for some other option.

We have a website in front of us, so we can try directory traversal using ffuf:

It can be seen that a number of pages are detected and we can explore each on of them. But none of the pages contain any useful information, even the pages mentioned in robots.txt are not accessible.

At this point it almost feels like hitting a wall. So, we can try to recall all that we know

  1. We had to specifically add the IP to /etc/hosts
  2. We are running a CMS which appears to be old but can’t find any useful exploits.
  3. Appears like there are no pages that contain any useful information.

One thing that is important to note here is that if we are asked to add an entry to /etc/hosts, then there are high chances that there might be a hidden subdomain because subdomains can't be found directly through IP address. So, we can perform subdomain enumeration to see if there are any subdomains present. Again, we can use ffuf for performing this task:

Here, I’ve added -fw to filter out those results that were not useful as all of them were having word count of 522.

So, we’ve found a subdomain. We can immediately go and check if there is some useful information over there.

Here, we get username and password for one of the account. Also, during the directory traversal attack we had found a login page. So, we can use these credential and try to login over there.

Now, we know the exact version of the CMS, so we can start looking for exploits for the same.

It appears that this version is vulnerable to local file inclusion. But turns out that the path mentioned in the exploit is for Windows and we are not sure if our target is running on Windows or Linux.

Meanwhile, the nmap scan also completes so we can gain some information from there as well:

Gaining Foothold

Here, from the information for port 80 we can conclude that the system is running on Linux. So, we can try to access /etc/passwd via LFI and modifying the exploit URI as: http://cmess.thm/admin/fm/?f=src../../../../../../../../../etc/passwd. After entering this we land on the file manager page of the CMS.

Over here, we can see an option for uploading files. So, we can upload a “php reverse shell” over here and then try to connect with the machine. We can use the php reverse shell by PentestMonkey and modify the $IP and $PORT values before uploading it.

After uploading the file, it gets saved in the assets directory. So, we can access it at: http://cmess.thm/assets/rev.php. Make sure to start a listener before visiting the .php file to catch the reverse shell connection.

This is a dumb shell, so we can upgrade it as:

Now, that we have a shell we can try to find the user flag.

First, we can check a few basic things about the machine:

Privilege Escalation


From these details, we can see that currently we are logged in as www-data and there is another user named andre on the system as well. Now, initially we logged into the CMS as andre only so, we can check if the password has been reused over here by trying to switch to andre's account.

But that is not the case over here. So, we need to look for some other method. We can check the output of sudo -l to see what sudo privileges www-data has:

But here it asks for www-data's password which we don't know. So, the next thing we can look at is for binaries with SUID bit set:

Again, we can’t find useful binary over here that can be used to escalate our privileges. The next thing we can look for are files with keywords like “password” or “andre” in their name and if we have read permission to them.

And here we can see an odd file /opt/.password.bak which has the following content:

Now that we have got the password to andre’s account, we can log into his account and get the user flag.

Now, our next task is to escalate our privileges to root.


For this, we can first check the command that “andre” can run as sudo.

But looks like we can’t run any commands as sudo. So, the next thing we can check are the cron jobs:

Over here, we can see that there is one job that is being run every half minute which first changes directory to /home/andre/backup and then creates a backup of all the files present in that directory. Here we can see that a wildcard * is being used and we can use it to escalate our privileges.

The thing with wildcards is that we can store file with names similar to tar options/switches and when the wildcard gets replaced by those filenames (in order to add them to the compressed file) then they act like options/switches for tar instead of acting as normal filenames. We can exploit the same issue and escalate our privileges as this job is running as root.

Before all this we can shift to a much stable ssh session as we know the password for "andre's" account.


  1. Create a file that would create a copy of /bin/bash and set its SUID bit. So, as the job is being run by root a copy of root's bash would be created.

2. Make the executable:

3. Create files whose name are similar to that of tar options:

Keep in mind to specific the full path when creating the files else they won’t get created.

  • The --checkpoint displays the progress message every passed value record (here passed value is 1)
  • The --checkpoint-action performs the specified action on each checkpoint which in our case is to execute the command sh

4. Wait for some time and then try the command:

With this we have rooted the machine!

Some Key Points to Take Away

  1. Whenever possible try to enumerate subdomains along with directories.
  2. Check for files to which you have read access.


  1. TryHackMe — CMesS:
  2. PentestMonkey — PHP Reverse Shell:

Do check out my other work and write-ups at

Just another CyberSec Guy

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store