TRYHACKME-WALKTHROUGH ON THE BOX “INTERNAL”

6 min readOct 30, 2020

My Solution to This Box

first we conduct a port scan on the target to discover open port and also discover what services are running on those port, and also their version
> nmap -sV -sC -A <machine_ip>

her we discovered that several ports are open which includes port 80 and 22
to enumerate further we browse through to the site using the following strings on the browser
> http://<machine_ip>:80

we found nothing so we keep enumerating further. now we are going to bruteforce the address to discover hidden directories using a tool called GOBUSTER
> gobuster dir — url http://10.10.216.94:80 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

here we discovered several directories which we will visit. after visiting serveral directory, now we have discovered our website is running on a wordpress CMS.

we will try to login to but discover a signup page. but we dont have any credentials to login, the next step is to discover a user and then bruteforce the user account
to discover the users password. this can be accomplished with the use of WPSCAN tool.
first we discover a user account
> wpscan — url http://10.10.216.94/blog -e vp,u

now we’ll try to bruteforce the account to discover a password which we could use to login the site.
> wpscan — url http://10.10.216.94/blog -U admin -P /usr/share/wordlists/rockyou.txt -t 60

for us to be able to access the site we need to add the ip address to our host file

now visit http://<machine_ip/blog on your browser and login to the site with the discovered credential

after login we surf through the dashboard. notice here we can upload a reverse shell file to get a cmd shell on our machine.

now after changes have been made and the file has been uploaded, first open a listening connection using netcat on your terminal, then on the browser navigate to the file to spawn a shell on your command line.
<machine_ip/blog/wp-content/themes/twentyseventeen/404.php

after getting the reverse-shell, we try to navigate to the users home directory which was not possible so we searched other directory and file eg wp-save.txt to discover the users credential which we will use to login via ssh

now we then use the credential to ssh into the machine using the discovered account

we can now discover the user.txt flag

*Now to get root flag*

if you look properly here there is a file called jenkins.txt, when we cat the file we discovered something interesting.
The file hints that there is an internal Jenkins server running on a 172.17.0.2:8080 address internally.

We can utilize a SSH tunnel with the Aubreanna user to gain access to the internal server in order to access it via our browser.
Notice that doing this also offers that we have access to the 172.17.0.0/24 network.

after tunneling into the internal server, lets visit the site running on the webserver. here we discover the site is running on a jenkins server,
and also we need login credentials.
> 127.0.0.1:8080

our next step to get the credential is to bruteforce the login page. there are several tools to do this, here i used OWASP ZAP
The below example uses ZAP. By capturing a failed log in attempt we can try to use admin as username and brute force the password field with a wordlist.

Considering the differences in size between response header sizes we can determine the correct password from an incorrect one and successfully log in.

Jenkins has a couple of different methods of command execution on the host machine, and I find the easiest to be utilizing a Groovy reverse shell in the Jenkins scripting console.
on the left pane in the dashboard click manage jenkins and select script console.

Utilizing the reverse shell and starting a netcat listener on the assigned port grants us access to another shell on the host.
Image for post

note= string host should be your IP address

now we get a reverse shell on our machine

The command line is limited, however, and it appears that we are actually inside of a Docker container. After manually enumerating more,
we can discover credentials for the root user in the /opt directory as before.