Skip to main content

Shutting down an SMTP AUTH Relay attack

We recently had a client whose Exchange Server (configured by another I.T. company, mind you) was continously being blacklisted with no immediately identifiable cause. Our first responders checked the normal stuff and verified that the server was not an open relay in any obvious way. At the time I jumped in on the support ticket, the server did not have the proper logging enabled, so we couldn't see exactly what was occuring.

The first step was to determine if anyone was actively spamming. There are a couple logs and tools that are useful for checking current Exchange connections, but we ran Exchange User Monitor overnight on the assumption that it was a client machine sending mail via the Exchange server. However, we didn't spot any MAPI or OWA connections being made in the off-hours, so we moved on to enabling some additional logging in Windows.

First, we enabled SMTP logging in IIS to give us a bit more information as to what connections were being made. Our logs (truncated with x.x.x.x to preserve privacy) showed the following:

#Fields: date time c-ip cs-username s-ip cs-method cs-host cs(User-Agent)
2010-11-18 00:00:34 x.x.x.x localhost EHLO - -
2010-11-18 00:00:35 x.x.x.x localhost MAIL - -
2010-11-18 00:00:35 x.x.x.x localhost RCPT - -
2010-11-18 00:00:37 x.x.x.x localhost DATA - -
2010-11-18 00:00:37 x.x.x.x localhost QUIT - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionResponse - - - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionCommand - EHLO - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionResponse - - - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionCommand - MAIL - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionResponse - - - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionCommand - RCPT - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionResponse - - - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionCommand - DATA - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionResponse - - - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionResponse - - - -
2010-11-18 00:00:44 x.x.x.x OutboundConnectionCommand - QUIT - -

Thousands of these lines logged while the client's business was closed (11:00pm to 3:00am) indicated not only massive amounts of spam being sent out, but that the attacker was external and was authenticating to the network. The first 5 lines show an EHLO connection, slightly different than the HELO in that it supports authentication, coming from an external source (which we subsequently traced to the UK and notified the business owner). The next set of lines is a spam message being sent from the local Exchange server out to the next victim.

While we had initially checked and made sure the server was not an open relay, allowing anyone to send to external domains without authenticating, most servers still allow authenticated relaying by default. This means that if you can authenticate by SMTP to the Exchange server with a valid username/password, you can relay to external domains. Not a big deal, as long as none of your users have a compromised account or weak passwords.

In order to spot which account was compromised, we turned to the Windows Event Logs. These showed a series of 1708 informational messages in the Application log as well as Success Audit messages in the Security log that pointed to an account that had been created called "test". I won't go in to why this is a bad idea for a username, but the password we found was even worse...

My colleague, Jon Jeffels (, did a little extra work and ran THC-HYDRA to crack the user account via SMTP authentication, probably the same way it was broken to begin with. Within a few seconds (with transforms applied) we had a password of "test1" to go with our username of "test" ... not very secure, folks!

Preventing SMTP AUTH Relay Attacks

There were a myriad of things that could have prevented this problem:
  • The best solution, in my opinion, would be to use an external mail filter of some sort. There are a lot of other reasons for this, and hosted solutions are too cheap to have any excuse for not using one. Use Smart Host settings in combination with this (and secure inbound connectors while you are at it).
  • Simply enforcing password security would have helped this temp user account stay secure
  • Or how about just not forgetting to delete TEMPORARY accounts?
  • Setting something besides the default lockout GPO of 50 attempts and 10 minute lockout would have been nice also. Perhaps 3 attempts and a 30 minute lockout?
  • Disable external relaying all together. Unless you have external users utilizing Exchange via POP3 (*shudder*), you shouldn't really need it. Check out instructions here for Exchange 2000/2003:
While we have a ton of fun catching and shutting down attacks, the "real" attack was the password compromise that probably had occured weeks earlier. This was a totally preventable problem that was probably caused by a tech creating a "test" account, so shame on all of you I.T. companies out there who are using weak passwords and should know better!


Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.