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 192.168.15.250 EHLO - -
2010-11-18 00:00:35 x.x.x.x localhost 192.168.15.250 MAIL - -
2010-11-18 00:00:35 x.x.x.x localhost 192.168.15.250 RCPT - -
2010-11-18 00:00:37 x.x.x.x localhost 192.168.15.250 DATA - -
2010-11-18 00:00:37 x.x.x.x localhost 192.168.15.250 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 (http://blog.jeffels.net/), 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: http://www.amset.info/exchange/smtp-relaysecure.asp

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!