VulnHub: Kioptrix Level 2

The actual exploitation of Kioptrix Level 2 is really easy only if you go through proper enumeration and analyzing everything that you have. Gaining access to the machine is really simple but the main fun begins after that while escalating your privileges.

So, let’s begin!

Initial Enumeration

For enumeration, we can get started with running an nmap scan and trying to access the machine via a web browser to see if some website is hosted over there.

The results of nmap are like

It can be seen that ports 22, 80, 111, 443, 631, 1006 and 3306 are open on the target machine.

Gaining Access

When we access the IP address, we can see a login page is hosted over there.

The first thing that could come to our mind after looking at this login page would be SQLi. So, we can try to pass ' OR 1=1-- as the username as well as password. As this SQLi works, we are redirected to another page from where we can ping machines on the network.

We can first simply try the loopback IP i.e. “” to which we can get a response like

Now that we are sure that the ping command is being executed in the background, we can check if OS command Injection can be performed from here.

To test OS Command Injection, we can send simple input like “; whoami” and see if the result gets reflected in the output

On the last line, we can see that apache is returned. So, we can be sure that OS Command Injection can be performed over here. Through the same method we can gain a reverse shell as well by sending a command to create a reverse shell

And along with that we need to start a listener to get the reverse shell

Now, as this is a dumb shell we can upgrade it using the method explained over here.

Privilege Escalation

The first thing that we can check for are the commands that our user could run with sudo privileges using the command sudo -l but it asks for password which we don't know.

The next thing that we can check is if any cronjob is running on the system

But we can’t see any such suspicious cronjob running over here.

We can also check if there are any other users on the system and if we can access their directories.

It can be seen that there are two users on the system “harold” and “john” but we don’t have access to anyone’s directory.

Now, as the username is apache we can assume that this user is created for some web service. So, we can check the files in var/www directory to see if we can find some sensitive information that might help us to escalate privileges.

If we recall, then we had found an SQLi on the index.php page. So, it means that it would've been connected to some database in the backend. So, we can try to read the code for index.php in /var/www/html to see we can find some useful information.

And the very beginning of the file we can find MySQL login credentials for user “john”. Just to check if there is a case of password reuse we can first try to switch user to “john” or “harold” using the password “hiroshima” before check the database.

But it appears like there is no password reuse over here. So, we can move and see if any useful information can be obtained from the database.

It can be seen that there are 3 tables. We can check each one of them.

Beginning with table “mysql”

It can be seen that there are multiple tables in this database but the one that appears to be the most interesting is “user”.

Because there are a large number of columns in the table, we can select only the columns that we are interested in which are Host, User and Password.

From the table, we can see that for both root and john the password value is same. This password appears to be a hash and to check that we can use hashid

As per hashid this hash could be a MySQL323 hash. So, we can use john to crack this hash.

But this appears to be a rabbit hole as we got the same password that we had obtained from the index.php file.

But we still have 2 more databases to explore. So, we can move on to the next database “test”.

But this database does not contain any tables so, we can move on to the next database “webapp”.

In the “webapp” database there is only one table names “users”. And in that table we can see two entries each for “admin” and “john”. On checking the password values with hashid no result was obtained, which means that both these values might be the actual password. So, we can try to use these password to switch user. Again, there is no user named "admin" on the machine so we can try to check each password with username "john", "harold" and "root".

But sadly, none of the passwords work for any of the usernames. So, this entire database thing turned out to be a rabbit hole. We can now check details of the system to find any exploit related to the OS or kernel.

IT can be seen that system is running on CentOS 4.5 (Linux Version 2.6.9–55.EL). So, we can look for exploits associated with this.

The first link when we google for “CentOS 4.5 exploit” leads us to this exploit. We can download it on our machine and then send it to the target machine using a python server and wget. And run it as per the steps mentioned in the exploit itself.

And by running just a simple exploit script, we got the access to the machine as root!

Some Key Points to Take Away

  1. Always take a look at the details of the system while performing initial enumeration of the system for privilege escalation.


  1. Kioptrix Level 2:,23/
  2. Upgrading Shell:
  3. CVE-2009–2698 (Privilege Escalation):

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