Internal : TryHackMe Writeup
Internal is an interesting capture the flag that mimics a real world penetration test assessment.
In this walkthrough, we will cover how to :
[+] Enumerate a web server using different techniques
[+] Exploit a WordPress website
[+] Exploit a Jenkins server
[+] Perform pivoting
[+] Escalate our privileges
Note 📝 : This writeup focuses more on the methodologies used to complete the challenge rather than providing you only the flags.
With that said, let’s kick off !!
[Task 1] — Pre-engagement briefing
You have been assigned to a client that wants a penetration test conducted on an environment due to be released to production in three weeks.
Scope Of Work
The client requests that an engineer conducts an external, web app, and internal assessment of the provided virtual environment. The client has asked that minimal information be provided about the assessment, wanting the engagement conducted from the eyes of a malicious actor (black box penetration test). The client has asked that you secure two flags (User.txt and Root.txt) as proof of exploitation:
Additionally, the client has provided the following scope allowances :
- Ensure that you modify your hosts file to reflect internal.thm
- Any tools or techniques are permitted in this engagement
- Locate and note all vulnerabilities found
- Submit the flags discovered to the dashboard
- Only the IP address assigned to your machine is in scope
[Task 2] — Deploy and Engage the Client Environment
Having accepted the project, you are provided with the client assessment environment. Secure the User and Root flags and submit them to the dashboard as proof of exploitation.
Setup the hosts file
Reconnaissance
Nmap Scan
Let’s perform a Nmap scan to check the open ports and the services running on those ports as well as their respective versions.
We have two open ports : HTTP (tcp/80) and SSH (tcp/22).
Let’s now perform some service enumeration.
Service Enumeration
HTTP Enumeration
Knowing that the client requests us to conduct an external, web app, and internal assessment of the virtual environment, we will start by enumerating the HTTP server.
First and foremost, let’s take a look at the webpage using our browser.
We will also use a web technology profiler addon called Wappalyzer.
A web technology profiler finds out what a website is built with.
As you can see, Wappalyzer provided us with information regarding the version of the Apache server (2.4.29) as well as the Operating System running on the server (Ubuntu).
Great! Let’s go to the next step which is about vulnerability research.
Vulnerability Research
In this section, we are going to perform a vulnerability research using SearchSploit and Nikto.
SearchSploit
Here, we are going to use SearchSploit to check if the identified Apache version (2.4.9) has some public known exploits.
Unfortunately, we found no exploit related to our Apache version. Nevertheless, let’s conduct a Nikto vulnerability scan.
Nikto
Syntax : nikto -h URL
Note 📝 : -o is used to save the output into a file.
Let’s break down the information returned by Nikto :
- The version of the Apache server (2.4.29) is outdated. Unfortunately, as you already know it, we didn’t find any vulnerability related to this Apache version while running searchsploit.
- The /phpmyadmin and /blog/wp-login.php files were found. We will deep dive into these files during the exploitation phase.
Though, we obtained some interesting directories via Nikto, it’s well thinking to conduct a directory/file enumeration in order to not miss any other useful directory.
Directory and File Enumeration
In this section, we are going to perform a directory/file enumeration using Gobuster :
We found the same directories that Nikto returned namely :
/phpmyadmin/
Here we can see a login page to connect to the MySQL database.
Moreover, Wappalyzer returned us other interesting information such as the DataBase Management System (DBMS) used by the target (MySQL) and the back-end programming language used by the server (PHP).
We can leverage this login page to perform a dictionary attack. Nevertheless, we will attempt that in the exploitation phase.
As of now, let’s focus on enumerating as much as information we can in order to determine the best attack path that can lead us to a better exploitation.
In addition to browse the webpage, we can also try to perform a directory/file enumeration from this path as follows :
Too bad for us :(
We found some directories but they all have access restriction.
Indeed the “401-Unauthorized” status code tells us that we need to authenticate (for example by using our credentials) to get the requested response whereas the “403-Forbidden” simply tells us that we don’t have the permission to see the requested resource whether we are authenticated or not.
- /blog/
Great, we can see that this is a wordpress website.
Furthermore, we were able to find the wordpress version (5.4.2) thanks to Wappalyzer.
Let’s now perform some directory/file enumeration against the wordpress website.
Excellent! We found some interesting files such as /wp-admin and /wp-content.
- /wp-admin
Simply put, the WordPress admin dashboard often called WP admin panel is the control panel for your entire WordPress website. It’s where you can create and manage content, add functionality in the form of plugins, change styling in the form of themes, and lots more.
By default, you can find the WordPress admin dashboard by appending /wp-admin to the URL of your WordPress website as follows :
https://yourdomain.com/wp-admin
Let’s check this out :
As you can see, we have been redirected to the login page.
Indeed, if you try to access the admin panel without being logged, WordPress will automatically redirect you to the login page.
Note 📝 : You can also browse the WordPress admin login page URL by adding /wp-login.php to the URL of your WordPress website as follows : https://yourdomain.com/wp-login.php
- /wp-content
wp-content is a core folder within your WordPress website that stores all your site files. Its content includes :
- Plugins
The plugins folder contains all the plugins that you can manage from your dashboard.
- Themes
The themes folder contains all the themes that you can manage from your dashboard.
- Uploads (/wp-content/uploads/)
The Uploads folder has all the media items that you upload in your posts.
Fantastic! We come to the end of the enumeration phase.
It’s time to move on to the exploitation phase now :)
Service Exploitation
HTTP
In this section, we will try to get an initial foothold to the target system by using the information that we gathered during the enumeration phase.
PhpMyAdmin
First and foremost, before performing any dictionary attack, let’s try to login to the database by using the phpmyadmin’s default credentials.
To do that, let’s try the following credentials (username: root & password:’’)
Unfortunately, the administrator of the database disabled the empty password login feature.
You may be wondering, what about the credentials “root:root” ?
Well, let’s give it a shot !
Hmm, it also doesn’t work.
Knowing that the default credentials did not work, let’s perform a dictionary attack against the phpmyadmin login page. For that, we can use Burp Suite.
First of all, let’s intercept the login request using Burp Proxy.
After successfully intercepting the request, let’s send it to Burp intruder using the ‘ctrl + i’ shortcut.
Once there, we will perform a Pitchfork attack using the mysql seclists default credentials.
Note 📝 : For those interesting, this tutorial can help you understand how to perform a pitchfork attack using Burp Suite.
Unfortunately, this attack returned nothing useful for us.
However, let’s try to exploit our wordpress website.
Wordpress
To refresh your mind, we found a login page as well as the version using by WordPress during the enumeration phase.
Let’s use WPScan to enumerate more juicy information that can lead us to expand our attack surface :
Syntax : wpscan --url TARGET_URL
--url : use to specify the target URL
Note 📝 : The -e option is used to perform users enumeration.
Amazing! Though we did not find any vulnerable plugins or themes, we did find a valid username \0/ that we can leverage to perform a dictionary attack against the /wp-login page.
Another way to confirm that the identified username is valid consists of monitoring the login error message. Here is how to do that :
Let’s try to use a random username just to confirm that it works fine :
As you can see, WordPress returned an error saying that the specified username is unknown which simply means that the user doesn’t exist.
Note 📝 : It’s well stressing that “monitoring the error login message” may not work all the time. In fact, this depends on how WordPress has been configured.
Excellent! Now let’s kick off our dictionary attack.
As far as I’m concerned, I am going to use WPScan to perform the attack. Here is how to do that :
wpscan --url internal.thm/blog -U USERNAME -P WORDLIST
For that to work, you will need to replace USERNAME by admin and WORDLIST by a wordlist of our choice.
Woohoo \0/, we found the admin user’s password.
Now let’s connect to its account.
We now have the administrator’s email address : admin@internal.thm.
Let’s write it somewhere. After all, who knows ? It can be useful.
As you can observe, I have successfully logged in as the admin user.
Let’s start interesting things . Will you ?
In our case, we will be mainly focused on the Appearance section.
After clicking on Appearance, click on Theme Editor (Appearance > Theme Editor) as follows :
After clicking on Theme Editor, we are going to replace the 404.php file with a php reverse shell in order to obtain a reverse shell.
FYI, you can also find the php reverse shell script locally on your Kali Linux machine in “/usr/share/webshells/php/php-reverse-shell.php”.
Note 📝 : You will need to edit the php reverse shell file by setting the IP address as well as the port on which you will be listening.
Once done, let’s setup our netcat listener.
After that, let’s browse the 404.php file to obtain our reverse shell :
Great! We got our reverse shell.
Before going any further, let’s stabilize our command shell using the python pty module :
Wonderful! Now that we got an initial foothold to the target system, let’s explore some post-exploitation techniques.
Post-exploitation
We will start with local enumeration.
For that, we can start by taking a look at the filesystem.
Let’s take a look at the /var/www/html directory.
This directory is often used to store files that are part of the website’s content when a web server, such as Apache or Nginx, is installed on the system. Simply put, it is the base directory for websites.
Here we found the wordpress directory.
Let’s examine its content :
Amazing, we now have access to all WordPress files including the wp-config.php file which is one of the core WordPress files. It contains information about the database, including its name, host, username, and password.
This file allows WordPress to communicate with the database to store and retrieve data (e.g. Posts, Users, Settings, etc). It’s also used to configure advanced options for WordPress.
Interesting! Let’s try to connect to the database using mysql command :
Let’s use the “wordpress” database, then display its tables :
After that, let’s display the rows related to the “wp_users” table.
As you can see, we only have one row set in the wp_users table.
Too bad, this row only concerns the admin user. This is useless in our case see that we already know his password.
Another way to connect to the WordPress database would have consisted of using the phpmyadmin login panel from our attacker machine as follows :
With that said, let’s keep on our filesystem exploration by taking this time a look at the /home directory :
Great! We found a new user called aubreanna.
Nevertheless, we cannot access his home directory see that we do not have the permissions.
Huff 😮💨 !! We explored lots of things but unfortunately we have not been able to escalate our privileges so far ?
Knowing that the target is running a Linux OS, we could have tried other techniques such as :
- Checking for misconfigured cron jobs.
- Trying to abuse the Sudo feature.
- Trying to manipulate the PATH environment variable.
- Checking for SUIDs and SGIDs.
- Checking for public exposed SSH keys.
- Checking for kernel exploitation.
Taking a look at each of these privilege escalation vectors manually would have been really exhausted, therefore I decided to automate the process by using the well known linux post-exploitation script: Linpeas.
For that, I setup a HTTP python server on my attacker machine, then I downloaded the Linpeas script on the target system as follows :
As you can see, the SSH server allows “Root Login” which simply means that we can connect to the SSH server using the username root.
However, this is not useful because we don’t have the root user’s password.
Sounds interesting! Linpeas returned that some files have been found in the /opt directory which is usually empty.
In this directory, a particular file caught my eye : wp-save.txt.
Let’s take a look at it :
Fantastic!! This file contains the user aubreanna’s password. Let’s try to connect to his account using the su command :
Great! We now have the user.txt flag in our possession. The last flag to secure is : root.txt. Let’s go get it 🏃♂️! Will you ?
By taking a close look at the content of the /opt directory, you can see that there is another interesting file : jenkins.txt.
Let’s examine it :
As you can observe, we can access the jenkins server (172.17.0.2) from our compromised system. This is because, both systems share the same network (172.17.0.0/16) as you can see on the image below :
Let’s try to access the jenkins server from our attacker machine :
We received no response, which is expected since we are not on the same network as the server. This can be confirmed by using the traceroute command :
In order to reach the jenkins server from our attacker machine, we need to use a technique called pivoting which consists of using a compromised system (pivot) to access to another system that we cannot access directly from our attacker machine.
For that, we have numerous options. We can add a route using Metasploit or use SSH if it is enabled on the target system.
In my case, I am going to add a new route using Metasploit.
Nevertheless, we first need to generate a reverse shell payload in order to get a meterpreter shell.
Now let’s first setup our metasploit handler, then execute the reverse shell on the target machine to get a meterpreter shell :
Super! Let’s now add a route to the 172.17.0.0/16 network :
Though, we can now access the server (172.17.0.2) in msfconsole, we still cannot access to it outside msfconsole.
In order to access it outside msfconsole, we need to setup what’s called port forwarding.
After properly setting the port forwarding, we should normally be able to access the jenkins server.
Let’s check this out :
BINGO \0/, we are now able to access the Jenkins server from our attacker machine.
Let’s try to enumerate this server, then exploit it if possible.
Nmap Scan
Interesting. We got the version of the server and the robots.txt file.
Let’s take a look to the robots.txt file.
Sounds great! Let’s perform a directory/file enumeration.
We did not find much information. However, let’s take a glance at the /oops directory:
Hmm, nothing interesting here except the version (2.250) used by jenkins rest api.
See that we didn’t find anything from now, let’s try to perform a dictionary attack against the login page using hydra.
However, we need to find a valid user or a list of users before performing the attack. After a quick search, I found this :
Therefore, I decided to use admin as username for the dictionary attack :
And guess what ? I got the password \0/.
After our attack, let’s connect to the server using the credentials we found :
From there, we can access the script console by browsing “Manage Jenkins” > “Script Console” or by visiting the sub-URL /script on our Jenkins instance.
After opening the script console, we are going to run a reverse shell script wrote in Java :
Here we go !
Great, we obtained a reverse shell. However before moving forward, let’s first stabilize our shell using python’s pty module as follows :
Once done, we will try to escalate our privileges. For that, we are going to download Linpeas on the target machine, then execute it :
Interesting! Linpeas warned us regarding the /opt directory which is usually empty.
Nevertheless, in our case it contains a file called note.txt.
Let’s take a glance at it :
Hoorah \0/, this file contains the password of the root user.
Knowing that the SSH server allows “Root Login”, we can go ahead and connect to that account :
Excellent! By taking a look at its home directory, we can find the root.txt file :
Conclusion
To sum up, this was a captivating and challenging CTF in which we covered how to perform an external and internal penetration test using various tools and techniques.
That’s it, I hope you learnt something guys.
Do not forget to click on the little clap icon below if you enjoyed the content and to subscribe to my newsletter to keep up with my latest articles.
References
https://www.hackingarticles.in/wordpress-reverse-shell/
https://www.n00py.io/2017/01/compromising-jenkins-and-extracting-credentials/
https://pentestmonkey.net/cheat-sheet
https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/
Contact
LinkedIn : https://www.linkedin.com/in/konateolivier/
GitHub : https://github.com/0liverFlow
