Download as pdf or txt
Download as pdf or txt
You are on page 1of 4

April 3, 2019

Using Your Mail Server Against Youf


CYBERSECURITY
BY MATTHEW CREEL

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 IDmcreel. 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 IDroot 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.


You’ve heard our thoughts… We’d like to hear yours
The Schneider Downs Our Thoughts On blog exists to create a dialogue on issues that are important to organizations and
individuals. While we enjoy sharing our ideas and insights, we’re especially interested in what you may have to say. If you
have a question or a comment about this article – or any article from the Our Thoughts On blog – we hope you’ll share it
with us. After all, a dialogue is an exchange of ideas, and we’d like to hear from you. Email us at
contactSD@schneiderdowns.com.

Material discussed is meant for informational purposes only, and it is not to be construed as investment, tax, or legal advice.
Please note that individual situations can vary. Therefore, this information should be relied upon when coordinated with
individual professional advice.

© 2020 Schneider Downs. All rights-reserved. All content on this site is property of Schneider Downs unless otherwise noted
and should not be used without written permission.

You might also like