Using Your Mail Server Against Youf

Occasionally on penetration testing/ethical hacking engagements we encounter misconfigured mail servers which creates an opportunity to either gather information on usernames or send emails impersonating internal users. Hackers love this scenario – we have encountered instances where threat actors find these vulnerable servers and just pour impersonation phishing attempts through, attempting to trick users into sending gift cards, bitcoin and wire transfers. Probing the mail server is a regular part of our pentest methodology at Schneider Downs and something we hunt for on each test. In the rest of this article I’ll break down what this looks like from an offensive perspective, including how you can check for this on your own domain, and touch on a few methods that can be used to secure your mail server.

Finding Your Mail Server

During reconnaissance, testers (and attackers) are going to try enumerating systems registered to your domain name, including your email server. There are many ways to do this (here is one with a GUI called DNS dumpster), but I’ll use the command-line utility dig here. Specifying the MX (mail exchanger) record will pull back only the mail server(s) for the specified domain.

In the answer section, you can see that the MX record for this domain points to the same host we put in the dig command, meaning that is the mail server. This is not always the case.

Connecting

Most of the vulnerable mail servers we see are still using port 25 for SMTP – usually the use of port 587 or 465 indicates the server requires TLS/SSL and authentication before commands are evaluated. We could scan the host to see what ports are open, but let’s just try connecting on port 25:

Port 25 is open, and we are now connected! Now it’s time to see what we can do. SMTP servers offer several commands, but we’re most interested in enumerating usernames and sending email.

The VRFY Command

The VRFY (verify) command checks for the existence of a user ID on a domain. This is typically disabled on the server because it could potentially allow an outsider to check for valid user IDs, which often correlate to internal usernames. Let’s try issuing a few commands:

With the first VRFY, you can see I’m checking for the existence of a user on the domain with the ID mcreel. The server issues a 553 no such user response. Next, we try checking for the user ID root, which receives a 252 response (meaning: Cannot VRFY user, but will accept message and attempt delivery). Code 250 is the success code you want to look for – but root likely exists on the domain since the response differs from mcreel, which we suspect is a truly invalid user ID.

An outsider can potentially use this concept to brute-force user IDs. I have found this method useful on engagements where company usernames are constructed haphazardly or with middle initial in the user ID.

MAIL FROM/RCPT TO Commands

In the event that the VRFY command is disabled, the MAIL FROM and RCPT TO commands can be used to accomplish the same thing. These are the commands used to start actually composing an email.

Any address can be entered into the MAIL FROM field. If you actually attempt to send an email, an address you know or previously enumerated could be placed here as an impersonation attempt. In the RCPT TO, you enter your email recipient. Above, you will notice that I first try to make the recipient an external email address. This is denied by the server – if you can send from an external address to an external address, the mail server is called an open mail relay, which could allow the server to become a source of spam. Next, in the RCPT TO fields, I start guessing user IDs. Again, the ID mcreel gets a 553 code, but the ID root gets accepted with a 250 code, indicating the ID is valid.

DATA Command

After picking out a target on the vulnerable server, you can attempt to phish them. The DATA command allows you to send a plaintext or HTML email to the target. The DATA command follows your MAIL FROM RCPT TO setup. Here is a real example in which I attempt to get the selected target to download a malicious HTA payload:

The DATA command closes with a line containing a period. A server response follows, 250 in this case, indicating that the email will be queued for delivery.

Mitigation

Mitigation starts with determining who has the ability to access and control the mail server. If your company has its own mail server, it’s up to you. Some companies use a third party – in which case if, the server is vulnerable, you have to discuss changes with them or find a new provider. If you use a cloud service such as Office365, you may not own the mail server, but you should still be able to adjust settings that configure it. I’ve seen mail servers in all 3 scenarios that are vulnerable to the types of attacks shown above.

 Below are a few points to consider when securing your mail server:

• Require TLS or SSL.
• Allow messages from local IP addresses to local mailboxes and non-local mailboxes.
• Allow messages from clients that are authenticated and authorized.
• Consider whether you need to allow messages from non-local IP addresses to local mailboxes.
• Never allow messages from non-local IP addresses to non-local mailboxes.