Email Pentesting
Email servers are complex beasts, if you've ever tried to configure one then you'll know the pain they can cause. With this in mind it's quite common to find them misconfigured in some way that we can take advantage of.
For the purpose of this we'll make use of the following clipped nmap scan of an email server from HackTheBox as our reference point as it looks to be a pretty typical example of what you might find in the wild or on a corporate network.
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
25/tcp open smtp syn-ack ttl 63 Postfix smtpd
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.41 ((Ubuntu))
110/tcp open pop3 syn-ack ttl 63 Dovecot pop3d
143/tcp open imap syn-ack ttl 63 Dovecot imapd (Ubuntu)
993/tcp open ssl/imap syn-ack ttl 63 Dovecot imapd (Ubuntu)
995/tcp open ssl/pop3 syn-ack ttl 63 Dovecot pop3d
This will be explained in greater detail below, but the above example is a fairly standard mail server, you've got your SMTP daemon (Postfix) running to send mails, and you've also got something to retreive the mails, in this case we have Dovecot running both POP3 and IMAP daemons in SSL and non-SSL mode (that's 4 separate services for the purposes of enumeration). And your common or garden SSH port running on 22, just for completeness, which is generally how the administrator will access this machine.
Take your time with email servers, aside from all the information they can give us there can often be vulnerabilities in the services themselves which can be exploited by interacting with them. Make sure to grab proper versions where possible to help with further enumeration. {: .prompt-info }
Understanding Email
Before we can attack something we need to at least have an understanding of what it is.
Email, or electronic mail is a terrible form of communication favoured by managers and the guy in the office who refuses to join Slack because it doesn't fit into his "Workflow". But it can still be useful for phishing and otherwise abusing to gain access to systems.
Mail is a simple thing, you send mails to a server and someone uses a client to access those emails. In the case of Outlook or something like that they are constantly polling the server and will download new mails when they arrive directly to your local machine, otherwise it would be a manual process (remember having to hit "Send/Receive" to get Outlook to send your mail back in the day?)
There are a few protocols we need to be familiar with to be able to properly interact with the email server.
*We use
telnetas it seems to handle the process a bit better thannc, thoughnccan do the job {: .prompt-info }
POP3
The "Post Office Protocol", or POP3 as it's generally called. As the name might suggest this is the protocol responsible for actually delivering the mails to users. POP3 servers communicate with the other mail protocols and essentially serve as your mailbox, you can log into the POP3 server (typically running on 110, and 995 in the SSL instance) and download your mail to your local machine or just view it on the server.
IMAP
Another way of retreiving your mail, but it's much more suited to a larger environment as it handles multiple clients accessing the service simultaneously.
By default IMAP runs on ports 143 and 993 respective of if it's using SSL or not with the latter (995) being the one running on SSL. IMAP is the most common protocol for mail access alongside POP3.
SMTP
Simple Mail Transport Protocol, or SMTP is the defacto standard for sending emails. And it's what we'll be using for most of our testing as we can interact with the protocol via telnet* from our Kali machine.
Typically SMTP runs on port 25, with the secure version running on port 465 by default.
STMP Command Cheat Sheet
| Command | Description |
|---|---|
HELO |
Basic server greeting (older systems) |
ELHO |
Enhanced server greeting (newer systems) |
MAIL FROM |
Who the mail is from (can be easily spoofed) |
RCPT TO |
Who to send the mail to? user@email.address |
SIZE |
Because size matters |
DATA |
The actual body/content of the message we want to send |
VRFY |
Verify that there is a valid user to receive an email (useful!) |
TURN |
Invert the client/server relationship without spawning a new connection |
AUTH |
For when we need to actually log in |
RSET |
Essentially a "Cancel" button, closes current action without terminating connection |
HELP |
DON'T PANIC! |
QUIT |
Because this has all just become a bit too much |
POP3 Command Cheat Sheet
POP3 is a simple beast and will only ever reply in one of the following ways:
Sending Emails
Before we can start hacking email servers we need to know the basic protocol for sending and interacting with them.
Sending Someone a Mail SMTP
$> telnet 10.10.10.110 110
<SERVER BANNER GOES HERE>
<Probably something about the creator>
> HELO hacker@fakedomain.com
OK
> MAIL FROM: hacker@fakedomain.com
OK
> RCPT TO: someone@gullible.com
OK
> DATA
<A message about how to end the mail, usually a "." on its own line>
Dear Mr Guillible,
We are writing to you today as our records show that you are known to respond to random unsolicited emails asking to hand over your information. Could you kindly send us you 16 digit card number and the 3 digit security code off the back of the credit card with the most money on it to the following email address:
stealing@allthethings.com
.
<Confirmation message>
> QUIT
<closing connection>
$>
Reading Someones Mail POP3
$> telnet 10.10.10.110 25
<SERVER BANNER GOES HERE>
<Probably something about the creator>
USER someusername
+OK
PASS somepassword
+OK Mailbox open, 200 messages
LIST
+OK Mailbox scan listing follows
1 1823
2 1825
3 1819
RETR 1
+OK 1823 octets
--- MESSAGE CONTENT GOES HERE ---
Harvesting Users
The biggest problem you're going to have with testing an email server is figuring out who to target. The best place to get that sort of information would be the company website or ideally dump their entire AD listing of active users... but since we probably don't have access to the latter we'll have to make do with the former and try and scrape as much information as we can from a website or FTP server, or whatever else we can get our grubby paws on.
This writeup isn't supposed to be an OSINT primer, but that's kind of where you should be looking for more information on how to gather the kind of information that would be useful for this (emails and Names)
As well as names of potential people, we can also look at potential names for departments or teams as these will often have a shared mailbox even in small organisations.
Mutations
Again this isn't what we're really here to discuss, but one of the things you need to bear in mind is all the potential ways a persons name could end up as a username. Take the simple and common English name David Smith as an example.
That's one simple name and I've not even covered all of the possible mutations, we've not even covered the case if there are multiple people with that name, do they get numbers? There is no simple answer here unfortunately, although a pretty good one to test early is david.smith as that seems to be a pretty common one in most enterprises I've seen.
Useful Tools
- Your eyes (Voted #1 Most Useful Tool 2021)
- Screenshot tools like
eyewitness cewlfor scraping all of the words from a site/page
Username Enumeration
Now we have an idea how what the usernames might look like and how we might go about harvesting them from the email server we can think about how to verify our findings. And we don't have to think too hard before we say "sod it" and write a Python script to do all the leg work for us.
#!/usr/bin/python
import socket
import sys
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ip = sys.argv[1]
input_file = sys.argv[2]
connect = s.connect((ip,25))
banner = s.recv(1024)
print(banner)
with open(input_file) as payloads:
for p in payloads:
s.send("VRFY " + p.rstrip() + '\r\n')
result = s.recv(1024)
print(result)
s.close()
Give that bad boy a file with usernames and it will test them against the server using the very useful VRFY command. If the server isn't setup to respond to the VRFY command then it'll just fail and this isn't an option for you on this machine sadly, and it's likely that you're going to need to find credentials elsewhere.
Bruteforce
When in doubt, get the sledgehammer out.
Or in our case hydra:
One thing to try here is to use the userlist.txt as the passlist.txt as resetting a users password to their name can be quite a common fallback for some service desks {: .prompt-info }
Bruteforcing could take forever or it could be fast depending on the lists you've used. Patience is key and making sure you've done the VRFY step (if it was possible) to check that you're attacking valid users.
Practical Exploitation
Once you've got your target list and you've gained some access, it's on you to figure out how to abuse those new permissions. But here are some ideas in case you were struggling:
- Send the admins/users generic phishing emails
- Send mails to user groups
- Read peoples mails and look for passwords
- Abuse the mail and just troll people (don't do this)
- Poison emails with malicious payloads that fire when they land
Unless the mail server itself is vulnerable then you're essentially just looking at using the server to gain addtional information and potentially credentials to access other services.
PostFix Disclaimer
No this is nothing to do with me warning you about using Postfix. It's got more to do with:
/etc/postfix/disclaimer
A harmless sounding file, right? What could be dangerous about a disclaimer? But then why would I be highlighting it in a pentesting guide if it wasn't worth mentioning?
The /etc/postfix/disclaimer file is actually a BASH script that is sent along with every message. If for some reason we're able to modify that file then we'll be able to spawn a shell as whichever user is running the mail server simply by placing one at the top of the file under the shebang and setting up our listener accordingly.
ExploitDB Link Explaining in Better Detail {: .prompt-info }
Status Codes
When you send a command to the server it will respond with a Status Code followed by some message relating to whatever it is you just asked the server to do.
Conclusions
Email is bad.
Email servers are fun.
Happy hacking.