A worrisome new kind of attack is making the rounds on the Internet. This new threat isn't a worm like SoBig or Slammer, and it isn't a virus like Swen--it's an insidious spam attack that victimizes innocent Exchange Server systems. And this attack is succeeding far more often than it should.
Spammers are scanning the Internet looking for SMTP servers. These spammers use retrieved banner information to identify Exchange servers, then use the SMTP service to mount brute-force password-guessing attacks against well-known accounts on those servers. That's right: Instead of attacking the increasingly well-defended Windows remote procedure call (RPC) services that most organizations use for logon authentication, this attack sends a barrage of SMTP AUTH LOGON commands until one succeeds.
"But wait a minute," you say. "Exchange Server 2003 and Exchange 2000 Server have relaying turned off by default!" Yes, they do--for unauthenticated users. But if a spammer manages to snag an authenticated user's credentials, the spammer can authenticate to your server and use it to blast out millions of spam messages. As a consequence, your server (and possibly your entire IP block) will likely end up on a variety of blacklists--and you'll probably receive a flood of angry messages from irate spam recipients. To make matters worse, all this activity probably will fill your queues and transaction logs, slowing your server's performance.
This attack's dastardly nature is worsened by the fact that the attack is mostly invisible unless you've turned on auditing for account-access events. The SMTP log that the Microsoft IIS SMTP component maintains doesn't record the use of SMTP AUTH, so you can't look for a sudden spike in the number of AUTH requests to indicate that you're under attack. Your first warning sign might be that your server starts getting waves of spam-generated nondelivery reports (NDRs). Fortunately, protecting your servers against this attack is a simple process.
First, make sure that your administrator accounts have strong, complex passwords with more than 15 characters that are a mix of letters, numbers, and symbols. (When a password has 16 or more characters, Windows can't locally store the password's easily-cracked LM hash.) Other user accounts also should have complex passwords, but protecting your privileged accounts against brute-force password guessing is especially important.
Second, if you don't allow relaying, consider turning it off completely on all external-facing servers. If you do allow relaying, I suggest you reconsider your decision. For example, if you allow relaying to support external POP users, consider whether you could accomplish this task another way (e.g., by using the users' ISPs).
Third, consider disabling both basic and Windows integrated authentication on any SMTP virtual server that faces the Internet. Doing so prevents password-guessing attacks, but it also prevents users from authenticating before sending email. If you must leave this feature enabled, make sure that you also enable account-object auditing and regularly monitor the Windows event logs for long series of event ID 528, which failed logon attempts generate.
Fourth, if you use an Intrusion Detection System (IDS), configure it to watch for failed SMTP authentication requests (i.e., tell it to look for the text "535 5.7.3 Authentication unsuccessful" at offset 54 in packets on TCP port 25). This warning will alert you to an attempted attack.
Microsoft knows about this type of attack and will probably take measures to protect against it at some point. Until then, keep a careful eye on your servers to make sure they aren't being attacked. (And thanks to Andy Webb, who first brought this subject to my attention.)
