Announcement

Collapse
No announcement yet.

SBS Exchange 2003 - Spam attack

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • SBS Exchange 2003 - Spam attack

    We are running SBS2003 (Exchange 2003) all up to date. We got hit with a SPAM attack starting last Friday (7-22) at 7:21 AM. It continued through the weekend and I finally got it stopped (I believe) on Tuesday afternoon. Part of it was due to NDRs being allowed. The check box was set even though they had been disallowed since a large NDR attack several years ago. That was easy to fix, clear the check box, thus dis-allowing NDRs. I suspect the large # of NDRs was due to the following, bigger problem.

    First noticed that our outgoing mail was not being processed because the outbound SMTP queues were filling up with SPAM. We are NOT setup as an open relay but allow authentication, as is typical and required for ActiveSync. On Tuesday 7-26, I required everyone to change their passwords and several people had "password" as their password. I received a number of Unsuccessful Security Audits in the Event log for a particular user who had just changed his password from "password" after he had left for the day. Since then, all the SPAM msgs that are being processed have "submitted date/times" between 7/21/11 7:21 AM and 7/26/11 12:34 PM. This tells me that the attack has been stopped from outside the building.

    Since then, I have been trying to clear the outbound SMTP queues but they continue to fill. I now have upwards of 38,000 queues with a multitude of SPAM messages in each one. I am using Server Management to monitor and clear them. However, this was taking an awful long time, so I obtained "aqadmcli.exe", which is a good tool to clear the queues from a command line. I then automated this with a script file that runs every 10 minutes. I am still in the process of editing the script file to add more domain names to the "delmsg" commands. It appears that wildcards will work so I can do a "delmsg z*.com,flags=all" to cut down on the typing, but I'm not sure. My question is this:

    When I stop SMTP service for any reason and restart, it seems like the queues fill up again with the same SPAM msgs, but I can't tell for sure since most of the spam msgs are from 2 or 3 senders (spoofed I'm sure) with the same text. An example is this:

    I had tens of thousands of msgs originally destined for "yahoo.com". With the script running every 10 minutes, "yahoo.com" queue was pretty much cleared in a few hours. Then when I stopped/restarted SMTP, yahoo.com queue starts to rapidly fill again. I have verified that the SPAM traffic filling up the queues is NOT coming from outside the building anymore by disconnecting all network cables.

    My thinking is that the SPAM is being processed into the outbound queues from a file somewhere (pre-routing queue?) and that by stopping/restarting SMTP service it is starting over again to populate the outbound queues from this "file somewhere" that holds all the inbound SMTP traffic prior to routing.

    OR,

    I have a virus that is generating the traffic internally. This seems unlikely as I've done multiple scans with ANti-malware and TrendMicro (clean) and a "search" of the hard drives for phrases in the SPAM or the Senders shows up only in the queues.

    I am going to try and let the automated script run over the weekend without interruption to see if the queues just need to be flushed

    Anybody have any more insight into this or can comment on my approach or tell me where to look for a file that is used to hold the msgs prior to routing? Is it plausible that by stopping/restarting SMTP, I'm interrupting the flush and need to let it finish? Any help or comments appreciated.

    Oh and top of that our Email Server RAID drives crashed Wed nite and wouldn't rebuild. That took a day away (all Thursday) away from trying to clean up the queues. I'm heading home, it's been a long week.

    On the plus side, I've learned more about Exchange 2003 this week than I have in the 4-5 yrs we've had it up and running. When things are running smooth, there's no need to jump in and monkey with stuff.

  • #2
    Re: SBS Exchange 2003 - Spam attack

    First - "We are NOT setup as an open relay but allow authentication, as is typical and required for ActiveSync."

    That is wrong.

    You do not need to have authenticated relaying enabled for ActiveSync to work. If you have no POP3/IMAP users then you can turn off authenticated relaying completely.

    The behaviour you are seeing is perfectly normal for this kind of attack. When a spammer has successfully got hold of an account and server they will abuse it until it dies. They could dump many 100s of thousands of messages on to the server. Exchange is a very poor bulk emailing tool, and therefore it will take some time to process those messages. Not really a lot you can do other than removing the messages from the logs. It can usually take anything between six and eight hours to get rid of all of the messages. It isn't a quick process and there is no way to speed things up.

    Using "password" for the password, even for a temporary measure is a bad idea, because it will be the first thing that will be tried. Even if I am setting a temporary password I will use something a little more secure than that. It is just unfortunate that a spammer was attacking your server at the same time.

    It is unlikely to be a worm internally as that isn't how they work. For a worm to send email via Exchange, it would have to infect a workstation, then find the Exchange server, and finally get credentials to send the email. Too much hassle for the worm writers - plus corporate machines with Exchange are harder to infect. Most of them have their own SMTP engine, because they are trying to infect home user machines, bigger numbers to attack, more machines not locked down.

    Simon.
    --
    Simon Butler
    Exchange MVP

    Blog: http://blog.sembee.co.uk/
    More Exchange Content: http://exchange.sembee.info/
    Exchange Resources List: http://exbpa.com/
    In the UK? Hire me: http://www.sembee.co.uk/

    Sembee is a registered trademark, used here with permission.

    Comment


    • #3
      Re: SBS Exchange 2003 - Spam attack

      Originally posted by Sembee View Post
      First - "We are NOT setup as an open relay but allow authentication, as is typical and required for ActiveSync."

      That is wrong.

      You do not need to have authenticated relaying enabled for ActiveSync to work. If you have no POP3/IMAP users then you can turn off authenticated relaying completely.

      .....
      Simon.
      First of all, thanks for the reply. I stand corrected. I checked my notes from our previous issue with ActiveSync and iPhone email not working. I had to modify the authentication settings on HTTP & OMA Virtual Directories. Doesn't appear that I touched anything on SMTP then.

      I have setup SMTP Virtual Server Properties to allow anonymous access in order to get email from the Internet. Relay Restrictions are checked to "Allow All computer which successfuly authenticate to relay, regardless of the list above" (there are 3 IP addresses in the list, our internal & external IP addresses for our Exchange Server and 127.0.0.1) Are you saying I should uncheck this? If all it's necessary for is IMAP4 & POP3, I guess I could uncheck it and see what (if anything) quits working.

      As an update, the script I wrote is running every 10 minutes and keeping the queue contents down. However, I still have an awful lot of queues (>38,000) but mostly with under 40 messages in each one. My suspicion is this:

      Retries on messages that haven't yet been deleted are causing previously cleared queues to be created. I've looked at some of the messages and there are dozens of recipients at different domains. In other words, if I clear the "yahoo.com.hk" queue of SPAM messages and a message in a queue for "att.net" that hasn't been deleted yet is "retried", does the message also get queued again for "yahoo.com.hk"?

      Also, can I just delete message files in the mailroot/vs1/queue folder without any repercussions without using Server Management or aqadmcli.exe? It seems to work although I'll sometimes get a "file in use message" when I try and do more than a few. I also wonder if that can somehow mess up Exchange.

      Comment


      • #4
        Re: SBS Exchange 2003 - Spam attack

        You don't need any of those IP addresses listed for Exchange to work correctly. Certainly do not need the external IP address, and the internal address shouldn't be required either unless there is another application on the server that needs to use Exchange to send email.

        If you want to delete the messages manually then you will have to stop SMTP to do so. That will also mean though that any legitimate email that hasn't been processed could get deleted, which is often why other methods are used.

        Have you secured the server to stop how the server is being abused?
        http://exchange.sembee.info/2003/smtp/spam-cleanup.asp

        Simon.
        --
        Simon Butler
        Exchange MVP

        Blog: http://blog.sembee.co.uk/
        More Exchange Content: http://exchange.sembee.info/
        Exchange Resources List: http://exbpa.com/
        In the UK? Hire me: http://www.sembee.co.uk/

        Sembee is a registered trademark, used here with permission.

        Comment


        • #5
          Re: SBS Exchange 2003 - Spam attack

          Update - The outbound queues are flushed. We're pretty much back to normal although a few domains are still rejecting our SMTP traffic as SPAM. We've been delisted from the public blacklists that we were on, so hopefully things will clear out. We have locked down the server after the attack but still see attempts (which fail) to get through in the event logs. The problem stemmed from a user who had a password of "password". We are instituting a mandatory "change password" policy every quarter and have eliminated any kind of relay (including authenticated) on our SMTP Virtual Server (at Simon's recommendation). Creating a script to run periodically using the adaqmcli.exe utility was a big help in keeping the number of messages in each of the 40,000+ queues down until they got manageable enough to use a temporary SMTP Connector to gather them all in one place and delete them in groups of 10,000.

          Comment

          Working...
          X