Prime 1 ~ VulnHub


Prime 1 ~ VulnHub


Started off with IP lookup with the help of netdiscover.

Currently scanning: Finished!   |   Screen View: Unique Hosts

 42 Captured ARP Req/Rep packets, from 4 hosts.   Total size: 2520
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------    00:50:56:c0:00:08     33    1980  VMware, Inc.    00:50:56:f4:53:f7      3     180  VMware, Inc.  00:0c:29:ac:c1:b2      4     240  VMware, Inc.  00:50:56:e3:85:f8      2     120  VMware, Inc.

Just to make life easier I usually add an entry in my hosts file for easier access of the target machine.

echo "	prime1.hub" >> /etc/hosts
hosts file entry

Okay now onto the hacking!


As always, I started off with an NMAP scan against the machine.

nmap -Pn -sV -sC -oN initial prime1.hub
Starting Nmap 7.91 ( ) at 2021-02-25 00:02 EST
Nmap scan report for prime1.hub (
Host is up (0.000039s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 8d:c5:20:23:ab:10:ca:de:e2:fb:e5:cd:4d:2d:4d:72 (RSA)
|   256 94:9c:f8:6f:5c:f1:4c:11:95:7f:0a:2c:34:76:50:0b (ECDSA)
|_  256 4b:f6:f1:25:b6:13:26:d4:fc:9e:b0:72:9f:f4:69:68 (ED25519)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: HacknPentest
MAC Address: 00:0C:29:AC:C1:B2 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Scanning & Enumeration

Based on the scan that was run, I realized that port 80 was running a web server. This was the web app that was being served!

I then proceeded to run a Gobuster attack against the web server to enumerate all possible files and directories.

└─# gobuster dir -u http://prime1.hub/ -w /usr/share/wordlists/dirb/common.txt -x .php,.txt,.html  
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
[+] Url:            http://prime1.hub/
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/dirb/common.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     php,txt,html
[+] Timeout:        10s
2021/02/25 00:16:11 Starting gobuster
/.hta (Status: 403)
/.hta.php (Status: 403)
/.hta.txt (Status: 403)
/.hta.html (Status: 403)
/.htaccess (Status: 403)
/.htaccess.php (Status: 403)
/.htaccess.txt (Status: 403)
/.htaccess.html (Status: 403)
/.htpasswd (Status: 403)
/.htpasswd.php (Status: 403)
/.htpasswd.txt (Status: 403)
/.htpasswd.html (Status: 403)
/dev (Status: 200)
/image.php (Status: 200)
/index.php (Status: 200)
/index.php (Status: 200)
/javascript (Status: 301)
/secret.txt (Status: 200)
/server-status (Status: 403)
/wordpress (Status: 301)
2021/02/25 00:16:13 Finished

There were a couple interesting files and directories which were uncovered from this scan.

  • /Wordpress (WP installation)
  • /dev (dev notes)
  • index.php
  • image.php
  • secret.txt

Accessing prime1.hub/dev returned this note.


Accessing prime1.hub/secret.txt returned another note.

Following the github link led me to WFUZZ, the URL fuzzing tool.


 #    #  ######  #    #  ######  ######
 #    #  #       #    #      #       #
 #    #  #####   #    #     #       #
 # ## #  #       #    #    #       #
 ##  ##  #       #    #   #       #
 #    #  #        ####   ######  ######



COMMNAD = wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt  --hc 404

The secret.txt note also said to "do more fuzz" on all php pages that I uncovered. Thus, I started off with the index.php page.

└─# wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt  --hc 404 http://prime1.hub/index.php?FUZZ=something

I realized that the output length was different when the program fuzzed the file parameter. One of the earlier notes, told to look for location.txt. So I did.

Now this told me to use the param secrettier360 on another php page.

I headed to the image.php page and used the secrettier360 parameter to invoke a local file.

It worked! I was able to read the /etc/passwd file of the target machine. I also noticed that the user saket had the phrase find password.txt file in my directory. So I tried to read that file using the LFI vulnerability.

I was able to retrieve a password. However, It wasn't for SSH access. It was the password to one of the users on the wordpress install /wordpress.

I was able to login to the victor account no issues.


I then exploited a php file secret.php in the theme which I had write access to, to gain a reverse shell into the machine.


I then overwrote this file with a php reverse shell that I had and hit update.

Lastly to get the reverse shell, I simply triggered the php file to run and caught the shell with my netcat listener.


Privilege Escalation

I threw linpeas at the system which revealed that the kernel version was outdated and possibly exploitable.

I then looked on Searchsploit for an exploit which fit this particular system, found a suitable exploit, compiled it and ran it! This was the exploit I used for this particular kernel to perform local privilege escalation.

└─# searchsploit ubuntu

Linux Kernel < 4.13.9 (Ubuntu 16.04 / Fedora 27) - Local Privilege Escalation   | linux/local

Hosting the exploit file on a local webserver

Grabbing the exploit, compiling and running it

gcc filename.c -o output