RELAY?? But I fixed it already!..now what? 30

[POSAPAY]

Hey all,

On my Exchange 5.5 I have setup the routing, as well as only except from authenticated sources.
Running McAfee GroupShield5.

yet .. currently the Queues is full with like 400-800 e-mails spinning through it constantly.
Destination is random, origin is "bluestell__@_______.___"
The underscores are random characters.
right after the bluestell, there are two characters that seem to follow the incremental rule with the alphabet.
starts out as "aa" and goes up to "zz" then restarts.
The domain after the @ seems to vary from e-mail to e-mail.
Mostly common domains, such as hotmail, yahoo, att.net..etc.

The headers seem to be missing, I can't figure out what IP or server it is coming from. Simply no header contents.

Anybody have any ideas? My usual daily 1500 e-mail traffic just went over last two days to 9000+ emails.

I just turned off notifications, and disabled outbound responses to reduce the e-mail count and processes...but I'm looking for a way to make sure this person can't connect to my server. Anybody have a similar case before?

Thanks,
-Peter

 

[alanmalm]

The Bluestell messages are authenticated spam. Someone has compromised your systems and have one of your usernames and passwords. That is how they are getting in. In Exchange 5.5, if you go to Exchange Admin - Internet Mail Service - Routing tab - Make sure it is set to "Reroute" - then go to Routing restrictions button. Unselect the Hosts and Clients that successfully authenticate, then OK on out and restart the IMS service. This should stop the authenticated spam. This will be a problem if you have pop3 users however. They would have to have static ip's and be added in the second box of the Routing restrictions.

This is from one who knows.....

 

[hungman]

I have done extensive testing today on this problem and even when I've disconnected the server from the network, the IN and OUT directories under the IMC folder still repopulate. It only does this when IMS is running. Stopping IMS prevents this from reocurring.

By changing the local passwords for admin and IUSR accounts, this stopped the repopulation of these directories. I still am wary of the presence of a malicious app on the server, however.

I've also noticed outside attacks as well.

 

[HeadHoncho]

I too have been hit by this freak.... It started with code loaded in the Explorer Bar found by searching the registry for bluestell.. Apparently this is a chat/IM link that is corrupted from one of my users on a YAHOO I/M personal page crap install, very much a security risk since it opens up a pipe thru your firewalls. I suggest you limit this type of activity to none for your users. I pulled the machine off the network but damage was already done. This link is coming from CHINANET Chongging province network(

http://www.senderbase.org/search

-use the found IP to track) and I have blocked about 50 or more addresses but to no avail since these people have over 9,000 IP's to work with. I used a program called Active Ports from

http://www.downloads.com

to monitor Port 25 SMTP and capture the IP Addresses being used. I also followed James's advice on the monitoring and it works to find your weakness. Good Luck and I hope MicroCramp figures out a way to bolster their software to give us a chance in the future.

Matt

 

[cmolnar]

Hi Everyone,

I followed James instructions and found that the attack had used a TEST account that i had created a while back. Since the account was no longer needed i deleted it and that stopped submission of new messages into my queue. This account did have a strong password.

The problem that i had however was there was still a LOAD of messages in the outbound waiting to be delivered queue. I had sorted by orginator and deleted 10,000 at a time. Which certainly took it's toll on our mailsserver performance. Deleting 10000 messages from the queue would take about 15-30 minutes each time.

you where all a INVALUABLE resource on this problem.. Thanks everyone.

 

[james3838]

If this indeed a Virus/Worm and your topology DOES NOT require end users to submit to your internet facing machines via SMTP, then I would highly recommend turning off authenticated relay!

For those that have been hit by this (I have not), do you see lots of failed logon attempts? I would expect to see the log flooded with them if it was a dictionary attack. If its a virus or worm though, they may have another way to obtain/modify the password.

More information from those affected would be appreciated.

 

[cmolnar]

Have'nt been exactly flooded with them. However i am getting roughly 40 failed authentication attempts per hour.

Each failed login (4183) is trying to use the \test account. Never any other account.

There are no sucsuful logins since i deleted the test account. (2010) I did not have maximum loggin of IMC on during sucsesful authentications.

The IP address the 4183's are coming from are
219.153.153.254
211.158.76.227
211.158.89.77
211.158.51.203 (the vast majority of them are from this address)
218.70.136.247
218.70.137.148


hope this helps at all

 

[james3838]

I betcha this is the w32.swen.a@mm.html
See

http://www.sarc.com/avcenter/venc/data/w32.swen.a@mm.html

for details.

Check out step 12 for why I think its this virus. It is prompting infected users for authentication information.

 

[sbass2]

James3838,

I'm not sure I buy into W32.swen as being the source of the authentication breach. Remember that most people have been affected via local user accounts such as Guest, Test, Administrator, etc. on the local machine. There shouldn't be any users in receipt of email for those local user accounts and none of the users would have access to those passwords. I still question whether or not we are seeing a rootkit created that takes advantage of the MS03-039 exploit. Sample code was already published on a Chinese website on Tuesday (funny that's where most of the IPs are coming from too). I don't know for sure as this is all speculation, but it seems odd to me that the sample code for the MS03-039 exploit allows the attacker to create a local admin account and set it's password. It just seems like too much of a coincidence. Although it could just be that. Anyone else have thoughts on this?

 

[james3838]

Sbass2 - That is quite possible. But I've also seen people reporting non-guest/admin accounts being compromised that had strong passwords. Since W32.swen asks for this information, its the best target at this point, especially for the non-generic account compromise scenarios.

Its also possible that W32.swen has code to compromise MS03-039 as well, since it would be easier to exploit inside a firewall as a result of user infection. BTW - this is not limited to MS MTA's. If you browse through other MTA message boards, you will see this problem being reported there as well, also indicating the W32.swen connection.

In any case what ever is causing this is making me a lot more cautious and watchful of my machines, and end users. A friendly reminder to end users from the IT department about how upset we get when we are forced to work overtime because of end user virus infections has already been sent. We are also contemplating sacraficing a virgin employee as an example just to empasize our point.

 

[POSAPAY]

On my NT4/Exchange5.5 it must have been Administrator or Test account. Or both.
As soon as I deleted the test and changed the password on Administrator, all spaming slowed.. things in the que had to be deleted for about an hour more since e-mails must have backed up in buffers or any temporary storage areas, but after that... they've been gone!

My Administrator account's password was all lower case 6 characters. The new password is twice as long with numbers and some special characters.

The test account was a more probable cause, since its password was "test". Little bit too easy.. eh?
So I deleted that.

The Guest account was disabled to begin with, so no trouble there.

My recommendation to everyone, is to look over all accounts.
Delete any unused accounts. And for all others change passwords.
Especially the Administrator account, make it a complex password, and try not to use that account often. Keep it as a backup. Also... remember, if you run FTP...everything is in clear text, and any logins' password can be snatched too easily (I've been there.. it wasn't pretty)

Latest issue.. the microsoft patch virus e-mails..too many different ones to filter'm out easily.

Any suggestions?

Thanks, -Peter

 

[noaustin]

Thank you all. While in my case (Exchange 2000 behind PIX Firewall) I could not find the failed logons, resetting everyone's password seems to have at least slowed the bluestell down. I also blocked all incoming traffic to port 25 and the mail still showed up. So it seems to be internal.

I also placed a delete rule in our Trend Scanmail to delete anything with "bluestel*" in the from field. This is the first rule and at least reduced the load on the server for incoming mail and prevented about 60,000 messages per hour ending up in the queues.

I worked on this all night and the early reports from the office are that the mail server is up, there is no delay in outgoing mail, and people hate strong passwords. ;-)

Thanks to james3838 for the "step by step".

I know this is not over, but perhaps it's at least temporarily mitigated. Any thoughts on no failed logins?

Thanks, Noah

 

[Jimmulligan]

Aloha!

I have nothing useful to add, sorry, but I'd just like to say "Thanks" to everyone who has posted. The Exchange 5.5 box I'm responsible for has "bluestell" and this seems to be the only place on the Net that is aware of the problem. As they say, misery loves company.

Using advice posted here I found through event 2010 that someone from an outside ip addy (which changed) was authenticating as Administrator. I still frankly find this hard to believe as the Administrator account pw was quite strong, but I made it stronger.

This slowed substantially (still not sure completely) the flood of bluestell traffic, though I still see mail being generated with <> in the from field. This mail is also spam.

Sorry I can't offer a definitive solution, but thanks everyone for posting!

Jim

 

[POSAPAY]

The <> e-mails are a different issue. Those are generated more or less by Exchange server itself.
For example... some junk mail is being sent to your company zyx.com
The e-mail is sent to userxyz@xyz.com
But...you don't have a username: userxyz, nor any alias accounts.
Exchange will respond, and will send an e-mail noting, that no such e-mail account was found. These usually endup being <>(empty). Now, when the original sender's e-mail address or mainly domain name doesn't exist, they can get stuck in the queue for a while until it times out. The reason it shows in Exchange as <>(empty) is to avoid an infinite loop. Other wise servers could pass e-mails back and forth saying.. I don't have such account.. and the other replies, I don't have such account.

This can be pretty annoying for Administrators looking at a list of <>(empty) e-mails queued up. But they will time out and that's the end of them.

If anybody finds a solution to that...let me know!
I suppose that would need to be a separate thread perhaps.

Thanks,
-Peter

 

[MoreBlahBlah]

James3838:

I've been hit with this problem . . . Event ID 3024 warned that the SMTP queue exceeded 25000 items and wouldn't accept any more.

Two issues.

First, I receive a lot of 4183s (over 500 4183s) but no 2010s since July 10. Shouldn't each logon, including mine, be recorded?

Second, I disabled / changed passwords on most accounts, but I have two accounts that generate an Active Directory eror, &quot;Windows cannot disable object useraccount because: Insufficient access rights to perform the operation,&quot; when I try to change password or disable them. Any clues about this?

Thanks!

 

[MoreBlahBlah]

In addition to investigating spurious logins and scrubbing passwords, as described above, we also installed the MS02-011 (Q289258engi386.EXE) patch as discussed in this thread by lfour and jklobedanz, but with disconcerting results. First, we found thousands of messages in the queue. What's worse, the event log shows tens of Event IDs 2003 (e.g., &quot;A new TCP/IP SMTP connection has been made to host 216.127.87.1 (for skis-zveza.si). Logfile: <none>&quot;, and some Event IDs 3010 (&quot;An attempt to connect to host webtopmail.com failed.&quot. I don't really know what a 2003 is, but I have no reason to believe that this server should be connecting to _any_ other SMTP host. Anyone familiar with this connection process?

 

[georgeks]

For those that have succesful authentications of non existing domain users the problem is low security and a flaw in smtp service that allows that behaviour.

These are the accounts , the spammer was using when i had the same problem.

administrator
admin
root
webmaster
www
data
server
test
abc

Try this :

1) Take the server offline IF possible if not create the above usernames in usermanager for domains and secure them with a good password. In that way you ll still have connections but they ll be failed and you wont get any more spam to relay.

2) Empty the inbound and outbound queues . Be careful not to delete legit mail.

3) Read these articles

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q310669

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-011.asp

and download and apply this fix

http://support.microsoft.com/default.aspx?scid=kb;en-us;304115

THE FIX IS POST SP4.

4) Change the passwords of all administrative accounts. Combine letters with numbers and symbols. Upon reboot many services will fail to start due to the account change. Go to control panel>services > double click on every failed to start service and fill in the new password.(the most propable services to fail are exchange services, antivirus services)

5) Check one by one if possible every account to see if it s been added to other groups (admin group etc) or modified recently.

6) Delete the admin accounts previous administrators have left in the server. (If any)

7) Disable the guest account. Dont delete it.

8) Disable all the NDRs. You can do that in exchange admin>configuration>connections>Internet Mail Settings. on the upper right corner there is a button &quot;notifications&quot; click and uncheck all the boxes. (you choose send notifications for those non delivery reports and you have everything UNchecked below)

9) Make sure you have all the latest patches from microsoft installed (not only for exchange but for the os as well)

10)Make sure you are relay secure. And test the server with ordb.org etc.

11)Check the contents of c:\ and c:\winnt\ for suspicious folders and content. The previous admin didnt bother with updates and patches and i found lots of trojans and malicious software in the server.

12) Except from your antivirus a trojan scanner - remover would be a good idea. I used tauscan for a while.

13) (Optional) To increase my server's security i opened
exchange admin>configuration>connections>Internet Mail Settings. Went to the tab called Delivery restrictions and selected the accept messages from > list , pressed the modify button and added all my legit domain users. Applied and restarted ims. (you can put the all the usernames the spammer uses in the reject from list except administrator of course)

14) Delete the accounts you created in step 1

15) You ll propably have lots of failed authentication attempts after that but dont bother slowly they ll go away

16) If you also want to stop the connections you can ban them on your router or firewall but i wouldnt suggest that as you might cut off legit mail.

Thats all if i remember something else i ll post.

Good luck
George

 

[cmolnar]

Georgeks, you can't disable NDR's in exchange 5.5, the step listed in #8 will disable the notifiactions, for the events you have selected, to the mailbox listed to the left of the &quot;Change&quot; button. (usually the Administrator mailbox)

The most important thing you can do if your be plaqued by Bluestell attacks, is like James and others have said. Under &quot;Routing--> Routing restrictions, remove the tick from &quot;hosts and clients that sucsufully authenticate&quot;

Unless you have remote clients that are legit using your exchange server to send mail.. (like laptop users on the road using exchange for SMTP)

P.S. about 4 days after disabling the comprimised account, and removing the check for hosts and clients that sucsuffuly authenticated, my 4183's have stopped. I have FINALLY cleared the queues of outbounds, and things are back to normal.

 

[DColcl]

Folks, I just want to extend a sincere, heart-felt thanks to you for the help in dealing with this situation. I too was under attack and I thank God that I was able to find not only this thread, but this website.

Thank you!

 

[MusicManJoe]

Here, here!

Thanks all! My attacks have also stopped, due to techniques applied, which I learned from this thread! Thanks again!

Joe

 

[tdclark]

I was getting thousands of bluestell messages before i found this thread in a Google search. After turing on the Event logging for SMTP it was found they were coming from a User Account 'backup&quot;. Resetting the password to some gobbledy-gook one fixed it. Thanks for everyone on this forum. I am clean now and although I feel violated and a bit embarrassed (someone turned me in to SpamCop) I haven't been blocklisted.

I am glad that the European Union has declared spam illegal, but our own government has taken another tack and are working on a &quot;no call list&quot; like they have for telemarketers. Last week a judge declared spam to be legal, under the First Amendment, but I think the courts need to look at relay. If it is legal, what is to stop people from nailing billboards on the side of our homes to target ads to our neighbors. Personally, I think SMTP Relay should be a felony, and not protected by the First Amendment.