Kioptrix 1.2 is the 3rd part of the Kioptrix series with the objective to obtain root privilege on the box. It can be downloaded from vulnhub. There may be more than one ways to successfully complete the challenges.

Note: In order to keep all my CTF’s write ups crisp and concise, I only mention the steps which led to positive results. There were lot of trial and error and hours or in some case even days of failed attempts before reaching to the correct solution. So I strongly recommend to try the challenges on your own before moving on to see the solutions. Checking the walkthrough should be the last resort.

My lab setup consists of Kali linux (will be referred as attacker) running in VMWare Player and the network adapter is set to NAT. Network settings of downloaded VM (will be referred as victim) is changed (if not already) to NAT to bring it to the same network where my attacking machine is present. I approach every challenge with the typical penetration testing methodology of Reconnaissance, Exploitation and Post Exploitation.


Once I booted up my Kali VM, I checked its IP address using ifconfig. My Kali IP was Since my Kali IP and the victim VM are in the same network, I used netdiscover to get its IP address.


IP address of victim was

Next I checked for open ports along with the services and versions running on the victim using nmap

From the nmap’s output I found port 80 was open so I navigated to it using victim’s IP in the browser. I landed up on the home page of the web application

Simultaneously I started dirb to look for all the sub directories in the background by the time I was examining the web application.


I clicked the login tab on the home page

I tried few SQL injection attacks but it didn’t work. Then at the bottom of the page I found “Proudly Powered by: LotusCMS“. The web application is using a Content Management System which are known to offer several attack vectors due to vulnerable plugins and poorly designed modules. Whenever I find any CMS, the first thing I do is to download its source code (if available) to have the better understanding of the folder structures and skimming through the codes. This is also very useful to make the exploits (if any) for the CMS to work properly. The source code for LotusCMS can be downloaded from here.

Next, I quickly checked for any vulnerabilities related to Lotus CMS using searchsploit.

The output confirmed that 3.0 versions of LotusCMS is vulnerable to Remote Code Execution but I was not aware of the LotusCMS version running on the victim. I tried the exploits from exploit-db but none of them worked.

Finally, here I found a LotusCMS exploit to get the reverse shell. The exploit expected the home directory of LotusCMS on the remote server as the input. This might get tricky because the exploit will fail if we pass the invalid parameter. It is where the output of dirb (which I ran earlier) came to rescue.

By comparing the dirb output and the LotusCMS archive downloaded earlier, I found that the home directory of the web application was same as the home directory of LotusCMS.

Getting Reverse Shell

I opened the netcat listener on port 1234 to receive the incoming connection.

Now running the exploit with proper parameter will give back the reverse shell with limited privilege.

Post Exploitation

Starting with the post exploitation enumeration, I checked for the users in the home directory. There was a user  folder “loneferret”  containing a file CompanyPolicy.README

Looking for stored credentials

Since mysql is running on the machine, there might be the chance that the credentials to the database is saved somewhere in the web application configuration files. The following command helped to check for the hard coded string “localhost”

The output confirmed that the mysql connection details are stored in gconfig.php file

Content of gconfig.php reviled the mysql credentials

Navigating the database

With the mysql credentials, I logged in to the mysql database to look into the tables present.

The passwords in the table was stored in hash format. I used crackstation to crack the password for loneferret.

I tried to SSH to the victim as loneferret and the password starwars  and it worked 🙂

Privilege Escalation

The next objective was to get the root access on the machine. I checked for the commands which the user loneferret can run on the machine

The user has access to the hex editor “ht” which was very interesting. Sudo access to any editor can be abused to escalate the privilege by editing the sudoer file and add following line to give root access to a particular user (here loneferret)

loneferret ALL=(ALL) ALL
The above line means: The loneferret can execute from ALL terminals, acting as ALL (any) users, and run ALL (any) command. In simple words it means loneferret is now root.

I edited the /etc/sudoer using the ‘ht’ editor to make the user loneferret as root. Before editing, I set the environment variable TERM to make ht editor work.

Note:  Take utmost caution to edit /etc/sudoer file especially using ‘ht’ editor. It may break the system if incorrectly edited. The above file may be edited in different ways to get root access.

Once the changes are saved, loneferret can now execute ANY commands.

Switch user to become root

I hope this write-up was helpful. Share this if you found it useful. If you have any questions or suggestions please leave you comments. Subscribe to the mailing list to get updates for my future CTF write-ups and blogs.

Happy Learning 🙂

The author is a security enthusiast with interest in web application security, cloud-native application development and Kubernetes.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.