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

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

I have the exact same problem; running Norton on the server.
Ran an online scan from Trend; no virus.
Disconnected the server from the network, flush the queue, restart the IMC; Outbound queue still fills.
We're also seeing that the orignator is <>, along with bluestell...
Set the server to only accept Inbound; queue slowly fills with bluestell, but not <>. (BTW: Disconnected, set to accept Inbound & Outbound, queue fills with both, so it's not an external connection).

If anyone has ANY info on this, please help us. This is the most bizarre thing I've ever seen

We are receiving the same types of emails. Today there were 2,500 emails to send out in the queue. We have employees that need to POP their email and send from home so I have to have the "host and users that authenticate" checked otherwise they can't send emails. I also have "hosts and users with these IP addresses" checked but the table is empty (that's supposed to prevent relaying). The emails just keep coming into the queue. Any help for both of us would be greatly appreciated.

I have the same exact reasons why I can't close all connections to the outside. People use IMAP and POP.
I also have the <> empty origination issue on hand as well.

Any ideas on this bluestell??? Does anyone have any track of its origin? I'm guessing it must have an originating network block.. or IP address that we could block.

Regards,
-Peter

HELP>>>... it just hit for yesterday 26thousand e-mails getting transferred. Anybody know of a free snoffer or something???

26018 e-mails in one day is a bit too much! HELP!

-Peter

Check your NT accounts, especially Guest. I broke down and called MS on this and they said that is the most logical solution. On the network causing me problems, Guest was enabled (I know I didn't enable it). Disabled that, disabled all dormant accounts, removed and re-added the IMC and low and behold, all was clear. I'm giving it a few hours before I give the final cheer, but I'm pretty confident that was it.

I just checked... no guest account.
Also it doesn't seem to show a logon account creating the traffic. Is there a patch?
-p

With regard to the users popping their mail........The reason that we needed the "hosts and clients that successfully authenticate" ticked was so that users could send mail as well as receive it (or so I thought). The more I thought about it, the more I thought this was wrong. So I contacted my users' ISP. The users should be sending SMTP messages via their SMTP server, not our exchange box. With this particular ISP, that has to be setup so they put in a ticket for that. Anyway, what I found when I unticked the "hosts and clients that successfully authenticate" but left ticked the "hosts and clients with these IP addresses", I would no longer get the SPAM messages. My problem was two fold, I needed my users to be able to send SMTP messages. When I gave them that ability, I was getting SPAM messages as well. Now that I've figured out how they can send mail, I can untick the "hosts and clients that successfully authenticate" and stop the SPAM from coming in. Another note, I did have a guest account activated which I has since disabled. The SPAM is still coming in but not near as much as it was before disabling the guest account.

Thanks to all for the assistance and "sounding boards".

Well, that is a nice solution... but what if the users don't have any alternate SMTP options?

My scenario has become worse...now I'm seeing all random from outside addresses sending e-mails to outside random addresses.

It looks pretty much like a relay to me... but relay test websites, showed it being okay. Telnet tests showed it being okay and safe.
The only change lately, has been an upgrade of McAfee GroupShield4.x to GroupShield5.x
The new GroupShield blocks by subject line nicely.. but this relay/spaming is totally random, and I can't even lock on a sender's IP address, since the headers are completely missing. The most I see out of it, is notifications of failed outbound e-mails coming to the Admin box, with attachments.. that have no headers saved.

Anybody have any ideas? Perhaps run me through what to check for relaying?

I have the first two boxes checked in routing.
Authentication adn specify by IP. Both essential to my clients. Where else can e-mails come through???

This is a bit annoying.. because I go in to the que.. and see over 6000 e-mails in there.. I select all.. delete them.. and now I have 8000 e-mails.. new ones! to delete.

Would Exchange 2000 or.. Exchange 2003 solve this issue perhaps?

HELP!
thx
-peter

I am having the same issues.  I have over 2000 inbound and outbound message failures in my que, I kind of think that the relay is on for some odd reason, however, I don't know how to fix it.  

We have the exact same problem. Our Configuration is Win NT sp6a with MS Exchange 5.5 SP 4.
From 10 or maybe 11 of september, the mail server - That is Also Web and Proxy server And PDC - started to have 20000 mails in the queue each day. It seems like there is a proccess that i can't find that sends those mail to bluestell__@_______.__.All Scans for virus where clean .I Think of that because i tried to take the computer out of the LAN and cleal twice the queue but the problem was still there. All the settings in order to ensure open relay attacks are already done and tested.
I Think that maybe a virus or a hacker did that because i see your messages concerning the same problem all started after 11/09/2003.. If anybody have any idear, it will be helpful..

Thanks in Advance..

I’m having the same problem.  I just found this on the Microshaft site:

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

This was apparently not well publicized because Microshaft considers the severity to be “low”. I know this wasn’t installed on my server, so I’m giving it a shot.  

Hope this helps.  


Joe Klobedanz
Network Administrator
Oxford Instruments
600 Milik St.
Carteret NJ 07008

Phone: (732) 850-9387
Fax:      (732) 541-1845
Joe.klobedanz@ost.oxinst.com

http://www.Oxford-instruments.com

I've got the same issue.  I've tried the above patch with no luck.  My problem started September 3rd.  Server has not crashed, just gets bombed with the messages stuck in Outbound Queue.  Scanned with Trend online and Inoculan locally and nothing found.  My firewall log shows lots of traffic on Port 25 but it shows it as FTP instead of SMTP.  Also shows the inbound traffic as being received with a valid address.  Tried disabling all inactive accounts and restarting the IMC.  Made all users shut off PCs at night to see if traffic subsided but that didn't work either.  

Thanks,

Mapman04

Well, I downloaded that patch, took the server offline.
Deleted all items showing up in the que...and I guess there were more somewhere on the server still saved for future delivery that showed up after deleting everything from all four areas of the QUEUES.
So I had to select all items, delete, refresh... and repeat this like 15 times, until nothing else showed up anymore.
waited about 10-15 minutes.. and a couple more originating from <> showed up.

Weird.. server is physicly disconnected. Where did these come from??

So after clearing those out, I applied the patch, restarted the server, and reattached it to the network(plugged the network cable back in)
.. waited..waited..
and the bluestall stuff started showing up again.

So.. the patch was worthless as far as I could tell unfortunately. Has anyone started an issue ticket with Mocrosoft, or any anti-virus or anti-spam company yet?

My daily e-mails are up from 1500/day to 65000/day it is starting to effect the delivery times of proper e-mails.

thanks,
-Peter

FYI - I'm seeing this issue on an Exchange 2000 SP2 environment at a client site right now.  Still trying to dig into where exactly it's coming from.  Thus far I've done the following:

NetMon dump on Exchange filtering for TCP/25 traffic.  Although I noticed a lot of attempts going out from Exchange to the internet containing BlueStell addresses, I didn't see one occurance of an inbound SMTP connection that contained the BlueStell addressing info.  This leads me to believe that the email is coming from inside the network.  Perhaps a virus/worm.

Unfortunately, this doesn't leave me with many options for determining where the traffic is coming from because everyone here uses Outlook MAPI therefore all of the mail data is going to be tunneled in RPC which makes it more difficult to analyze the sniffer dumps.  I'm going to keep plugging away at it, but thought it would be helpful to pass along this info.  If you've found a solution, please post it to the thread so everyone can benefit.

Thanks.

Shawn

This bluestell is quite a hard worker!
I use Sybari's Antigen for Exchange with Spam Manager. When I first noticed bluestell in my outbound queue (9/15) I created a spam filter to block any inbound emails whose email address includes bluestell. Since then I catch an email every 5 seconds for about an hour at a clip, then a pause, then another hour of slamming. We need to catch this fool. I'll be analysing my smtp traffic further in hopes of finding the source.

Gene

We have been getting dumped with the same thing. It appears to be coming in internally because we have blocked smtp incoming traffic. The only way I get it to stop spamming other people is to block the range of IP's it sends to on the outgoing. Any help would be appreciate.

Turn your Diagnostic logging to Maximum for MSExchangeIMC -> SMTP Interface Events.

Look at all SMTP Interface Events in the Event logs.  Look for both 2010 Events (successful login) for accounts that SHOULD NOT BE AUTHENTICATING as well as 4183 Events (failed login).  It appears that what ever this is (virus/hacker/spammer) is using weak password attacks to authenticate against servers.  

The Guest account is only one of the accounts that are targeted.  Local Admin accounts are also being targeted.  There maybe other accounts as well.  

Looking at 4183 events will tell you which accounts you need to make sure are either disabled or have strong passwords.  
The 2010 events will show which accounts are being currently used to relay mail.

Thanks for the tip james3838.  I did just as you suggested and was able to find the account it was using.  I disabled it and the messages have appeared to stop!

Regards,

mapman04

Thanks for the tips guys/gals...

  I have an IP address linked to some suspecious failed logins (now that I've disabled the weak account). Not sure I should post it here, but it begins 211.158. anyone else? Perhaps this clown can be tracked down?

I am using Exchange 2003, and I can find the Diagnostic Logging screen, but the options are different. Does anyone know which option I need to set to maximum?

James3838 is right. It is a compromise on weak local account passwords. Change your local Administrator password, diasable guest, etc to fix the problem!

Glidman

James3838, your idea works on an Exchange 5.5 system, but do you know the MSExchangeIMC equivilant in Exchange 2000?

I think I found one of the companies responsible, they should be blacklisted:

BLUE STEEL:
Phone: 85 230158569
Fax: 85 230158571

If anyone has time, do your best to destroy them.

And a note, you have to be at SP4 on Exchange 5.5 to apply the patch mentioned above.  From what I've read about this though, it isn't supposed to help much.

"Turn your Diagnostic logging to Maximum for MSExchangeIMC -> SMTP Interface Events."

OK, I give. How do I do this please? I'm new to administering Exchange and all help is appreciated!

Thanks!

Corie

pmarsala,

I've determined the equivilant for Exchange 2000 to be MSExchangeTransport then choose SMTP.  It might be the same for 2003.  Give it a try.

Also, will it mess stuff up if I remove the group 'GUESTS'?
I have already disabled the user guest account, but the group includes the IUSR_servername and IWAM_servername accounts.
Is this necessary, or just a hole that hackers can exploit?

Thanks!

Corie

Exact steps for Exchange 5.5:

Start->Programs->Microsoft Exchange->Microsoft Exchange Administrator
Connect to your Org
Find your internet facing server
Select its properties (either select it and type <alt><enter> or hit the property button)
Select the Diagnostics Logging Tab
Select MSExchangeIMC
Select SMTP Interface Events
Change Logging Level to Maximum
Hit Apply
Wait for new messages to come in (it will only log starting from when you increased logging)
Start->Programs->Administrative Tools->Event Viewer
Select Application Log
Select View menu item
Select Filter
Change Event Source to MSExchangeIMC
Hit OK
Go through logs looking for suspicious 2010's and 4183's.


Exact steps for Exchange 2000/2003:
Start->Programs->Microsoft Exchange->System Manager
Find your internet facing server
Select its properties (either select it and type <alt><enter> or hit the property button)
Select the Diagnostics Logging Tab
Select MSExchangeTransport
(Exchange 2000) Select SMTP Protocol
(Exchange 2003) Select Authentication
Change logging to maximum
Hit Apply
Start->Programs->Administrative Tools->Event Viewer
Select Application Log
Select View menu item
Select Filter
Change source event to MSExchangeTransport
Look for Event ID's 1708 for suspicious successful logons.

Hi James3838, I have been following this thread. I tried looking for the user authentication you said. In the 2010 events, it says

"connection from <ip address> successfully authenticated (AUTH LOGIN) as \administrator."

However, we do not have any user account with the name adminsitrator in our domain!!

We are using Windows NT 4.0 Server. For your info, Our exchange server is the member server in the DOMAIN.

How can I know the exact login procedure used by the spammer?

Regards
KBADMIN

KBADMIN -

\administrator is the local machine administrator

Unfortunately I don't have any NT4 boxes around anymore, so I can give you details on how to change the password/disable the local administrator account, but look on the box itself for a local Administrator account.

Hopefully someone else can post exact details.

Hi Again..

After I tracked Messages Via The Event Viewer, I Saw that There are no succesfull authenticatoin events (2010) but only some 4183( Logon Failure ). The Ip Addresses From Which The 4183 Events Come are :

219.153.150.231,
219.153.153.201,
218.70.9.109,
218.70.10.129,
211.158.77.11,
218.70.8.5,
218.70.10.97,
219.153.152.44 and
211.158.76.167 so far.

The Account that is trying to authenticate and it seems that it can't is \webmaster.
In the Server, that as i mentioned in my previous mail is Primary Domain Controller,Proxy,Web and Mail server the webmaster account existed 2-3 years ago but i have deleted it because we did not longer needed it.So this is the reason that the spammer could not authenticate.

The Problem still Continues.Today, i found 45000 mails in the Administrator inbox. Those mails are reports for those undeliverable mails sent by the spammer.For The moment , i have stopped the mail service trying to clear the queues and the administrator mailbox.I have applied the patch mentioned above by jklobedanz
( http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-011.asp )
 but the problem still persists. I have Also Already applied another patch delivered by microsoft on 10/09/2003 ( http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS03-039.asp )
but it did not did anything.
Anyway , this is my current status. I will continue to dig in the system trying to find something. If I find anything, you will be the first people to know.

If anyone have any idears, please share it with us. It will be very helpfull.  

Thanks in Advance..

SOLUTION FOUND !!!!!!!!!!!!!!!!!!!!!!

Dear All..

I Have Find A Temporary Solytion.

From The Routing Restriction Page On The Internet Mail Service Properties,( Internet Mail Service --> Properties -->Routing --> Routing Restrictions )Do The Following :

Last fields In the screen are :
Specify The Hosts And Clients That can NEVER Route Mail.
Add in this section The following Ip's :

219.153.150.231,
219.153.153.201,
218.70.9.109,
218.70.10.129,
211.158.77.11,
218.70.8.5,
218.70.10.97,
219.153.152.44 and
211.158.76.167 with subnet mask 255.255.255.0 to all.


After You Do That, Restart The IMService.
The Administrator Account Will Again Start Receiving Mails but not outbound, only inbound mails that after a few minutes will end.Clear the administrator mailbox for the junk mail and you are ok. The Outbound Queue Will stay empty with no problem.

If The user change ip address and the new one is not listed, then you must just add it to the NEVER ROUTE Mail Mask.

This Is only A temporary solution, worked fine to me for the moment.
I Hope that someone finds a better permanent solution.

Hope It Works for you all..

Hi all i just saw this thread. I had the same problem a couple of months ago.

check out my posts for resolution

Thread10-602113 must say that for about a week after i solve the problem i still had many failed authenticated attempts, but as the days passed the attempts slowly stopped

I tried looking for events 2010 and 4183 and none of them show up. Do I not have something configured to display these events?

Hi..All,

I hv been facing this peoblem since last one week...frequency of incoming mails are very high with sender name bluestell*@*.com/net.

I hv checked my system guest account..its disabled..is there any other way out...Pls.suggest..

Thanks in Advance..

Best Regards

All.

Solved issue at the client site I was at.  James3838 was right on with the diagnostic assistance.  In our particular scenario it was the local admin account that was being used.  However, I'd like to make everyone aware that the local admin account on the Exchange server in my client's environment had a very complex password.  I know for a fact because I had run the Baseline Security Analyzer against it a few weeks back and it never complained about a weak or blank password.  Plus the net admin there told me it was a complex password.  Which brings me to my next thing, how did someone get that password/set that password.  The only thing I can think of is there was a code exploit published around Sept 11, 2003 for the MS03-039 security bulletin (read info at http://www.microsoft.com/security/security_bulletins/ms03-039.asp - FYI this is the second RPC vulnerability/blaster patch).  Anyway, the exploit is capable of creating a local admin account.  Since the use of the Exchange server as a SPAM relay was using local Administrator in this case, I have to wonder if the machine was compromised with something due to the MS03-039 patch not being on the server yet.  (I know, I know - it should have been on there already but I'm only at this client site once a week so I have limited time to enact server changes, especially ones that require server reboots).  Anyway, we're applying MS03-039's patch now, but I STRONGLY urge anyone out there who is experiencing the bluestell issue to ensure they've patched ALL vulnerable servers AND workstations with MS03-039 as well as renamed all Admin/Guest accounts and reset passwords.  Keep in mind that if Exchange is set to allow authenticated users to relay then ANY workstation or server on your network is capable of relaying this SPAM through your Exchange server.  Good luck all.  FYI - the patch requires a reboot to be effective, don't forget!

Shawn

I fixed the problem and here is what I did.

First I did what James3838 suggested withthe SMTP connection and the event view.  I didn't get any events to pop up....so..

Through Group Policy I implemented the Password Complexity Requirement on all users.  Then forced each user to change the their password.  

After about 20 minutes, the emails stoped.  

When I walked in this morning I was receiving and sending about 4000 messages every minute and had 1096 connections in the queue.  

After I performed the Password change.  It has been running for 4 hours and I have only hav about 10 connnection in the queue and my network speed has increases 10X.  Even though I couldn't find the exact culprit changing the passwords fixed the issue.

Same here, when I checked the event log after enabling SMTP logging, I found that it was the CFO's account that was getting hit. I made him change the password on his account and so far, no more attacks.
I also added the list of IP's to the 'never route' table, and added the fix from MS.

Thanks again!

Corie

Hey All,

THANKS TO EVERYONE, it finally stopped!

Steps I took:

1) installed all recent patches
2) Maximized the logging, and looked, and found couple of odd user IDs.
3) deleted all unnecessary user login IDs
4) changed Administrator password (letters + numbers)

I also had to change the password for a few services in the services control panel, that use Administrator as the logon.
Services include: SQL server, Exchange server and each of its services, McAfee GroupShield and its services(like 5 different services)

Did this around 1am, so it wouldn't disrupt anyone.
Rebooted the boxes, forced a Domain Syncronization.

now it is 11am, and last night the queue had like 2000 e-mails in it.. now it is 4.

once again THANKS TO EVERYONE!
-Peter

Here is what the the culprit looked like for me.

Come to find out it was an administrator account on a TRUSTED domain.  Then perhaps it should be TRUSTED if they put their administrator password as "password".  What were they thinking.


--------------------------


Event Type:    Information
Event Source:    MSExchangeTransport
Event Category:    SMTP Protocol
Event ID:    1708
Date:        9/18/2003
Time:        9:37:24 AM
User:        N/A
Computer:    <SERVER>
Description:
SMTP Authentication was performed successfully with client "exceeded".  The authentication method was "LOGIN" and the username was "<DOMAIN>\<USER>".

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.....

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.

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(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 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

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.

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.

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

I betcha this is the w32.swen.a@mm.html
See w32.swen.a@mm.html" TARGET="_new">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.

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?

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.

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

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

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

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

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, "Windows cannot disable object useraccount because:  Insufficient access rights to perform the operation," when I try to change password or disable them.  Any clues about this?

Thanks!

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., "A new TCP/IP SMTP connection has been made to host 216.127.87.1 (for skis-zveza.si).  Logfile: <none>", and some Event IDs 3010 ("An attempt to connect to host webtopmail.com failed.").  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?

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 "notifications" 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

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 "Change" 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 "Routing--> Routing restrictions, remove the tick from "hosts and clients that sucsufully authenticate"

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.

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!

Here, here!

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

Joe

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". 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 "no call list" 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.

Wow. I don't know why I didn't check here first! I've been fighting this thing since September the 9th when the first 10000 e-mails in queue brought my 5.5 Exchange server to a halt. I finally today found that by checking the 'Clients can only submit if homed on this server' check box on the connections tab under IMS properties that this halted the slamming that I was taking. I've spent more time in the last 3 days on this server than I have in the last three years! Thanks for all the help!

Hello All,

  Thanks again for assistance fixing the bluestell issue...

   for a while I have seen messgages in the outgoing queue originating from <> I have checked the logs for allowed logons, they aren't coming from anyone listed there. Anyone know where they may be coming from?

Thanks
Joe

OK, same thing happens to me yesterday but I was able to discern the senders IP address by turning on SMTP Protocol and Interface logs.  I blocked the address 211.158.88.246, which is another CHINANET Chongging province network IP address.  There's a couple of things I've found out while researching this problem that might answer a few questions I've seen posted here.

1st:  "I've deleted all the messages in the queue and restarted the service with the machine unplugged from the network but more messages keep showing up."

This one boggled my mind too for a while but an in-depth search of the system log produced this:  

"Event ID:3038    An attempt to remove processed messages from the outbound store que has failed.  The removal will be retried later.  If the messages are not removed before the service is shut down, the mail will be resent at service startup causing duplicate mail."

The only way to avoid this is to shut down the service, go into the exchsrvr\imcdata folder and delete the contents of the "out" folder and the queue.dat file and then restart the service.  Microsoft KB324059 article details this process.  So there is no internal source or virus spamming your server....

2ND: "I've applied all the patches and my system still allows e-mail to be relayed."

Yup, tore out handfuls of hair on this one too but I kept digging and found out that this is by design and that not everything you might think is happening, is actually happening.   If someone sends and e-mail formatted like this name%otherdomain.com@yourdomain.com to your Exchange server, it will accept it and generate a NDR after failing a directory lookup.  Microsoft says this is acceptable as it does not forward the message.  Well, a great lot of help that is to us as our servers still have to process it. This is effectivly a DOS on our servers by flooding it with requests that the server will queue and attempt to process.  This is all detailed BTW in Microsoft KB304897 article (look at example six) and can be verified at http://members.iinet.net.au/~remmie/rela...;(look at the last test and then check you IMS queues)

The only true solution seems to be to go third party for a spam killing type of appliance or software as Exchange just doesn't cut the mustard.

Hope this helps!

ImWoody

This is what finally stopped the relaying in my domain:

set routing to route the domain to inbound, click on restrictions, and choose Hosts and Clients with these IP addresses, and leave the field blank. This effectively shuts the relay door. You can test by typing the following at a command prompt:

telnet servername 25

where servername is the name of your Exchange server. The Exchange server will respond with a message similar to 220 host.domain.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.10) ready. Then enter the following commands. The commands are case-sensitive, and the punctuation (e.g., colons, angle brackets—< >) is important, so include all the marks.

1 type
HELO me
The server will respond with 250 OK and possibly identify your IP address and your host name.

2 type
MAIL FROM: someaddress@somedomain.com
Again, the server will respond with 250 OK.

3 type  
RCPT TO: nobody@afakedomain.com
The server will respond with 550 Relaying prohibited.

Using a valid address from your GAL, enter
RCPT TO: thegaladdress@yourdomain
The IMS will reply with 250 OK when it accepts the address.

To close the session, type
QUIT


If you do not get the 550 RELAYING PROHIBITED message, you need to try again.

So this stopped the main problem, now all I have to worry about is the 529 errors that pop up every 12 seconds on the security log...

Thread10-659407 this helps!

Corie

The <> messages are typically NDR or (Non Delivery Report) messages from the Postmaster. Most often, this is what is called NDR spam which is a loophole in the RFC.

The fix in Exchange 5.5 and Exchange 2000 is a third party utility such as Praetor from cmsconnect.com or Mailsweeper. The best fix is Exchange 2003 where all this (and more) magically disappears! Exchange 2003 has RBL listing capabilities as well as the abilities to remove NDR spam.

You are absolutely right about what it is.

IMWOODY - -

"If someone sends and e-mail formatted like this name%otherdomain.com@yourdomain.com to your Exchange server, it will accept it and generate a NDR after failing a directory lookup."  You are correct!

"Microsoft says this is acceptable as it does not forward the message.  This is effectivly a DOS on our servers by flooding it with requests that the server will queue and attempt to process.  This is all detailed BTW in Microsoft KB304897 article (look at example six) and can be verified at http://members.iinet.net.au/~remmie/rela...;(look at the last test and then check you IMS queues)"

Right again, although it is not just Microsoft that says this. It is an RFC standard. The RFC requires the ability to send an NDR and you WANT this ability. Just for grins, what if I sent your company an email that would save you 10 million dollars and fumble-fingered the address? What if you didn't know I was sending it? You would never get the message and I would "assume" that you got it.

You wouldn't really know without calling or getting the NDR.

All the major spam lists only care if the message actually is relayed (not just accepted). Otherwise, EVERYONE would be on spam lists!!

--Alan

Well a friend of mine and I found a possible problem, we are still scanning the drives right now and have found two trojans so far. Netspy and executer, they scan random unassigned ports and steal passwords.

You can download the scanner from here,

http://www.softandco.com/download/Anti-T...

Make sure it's updated and run a full scan. I was running Anasil network monitor and seen random port scans coming from the IP of the Exchange server. It would only try and connect to ports that were unassigned to other services or programs.

I'm sure he'll post later to fill y'all in with more details, but from reading through the thread it seems as if nobody has run a trojan scan yet. Norton Corporate didn't pick up either one of these trojans either.

Give it a try and see if it helps, we still don't know the full results yet because the scan isn't finished, but it can't hurt to try.

If you want to try Anasil, you can get a demo copy from here,
http://www.anasil.net/

Thanks to everyone on this list for helping me find the problem with my server. Bluestell has sent 100,000 messages through my machine since September 2nd.
Here's something that might help others:

- Turn on SMTP Protocol logging to maximum.
- Wait for spammer to start using your open relay.
- Shut down IMS.
- Examine the protocol logs in \exchsrvr\imcdata\log
- Search for 'LOGIN authentication successful'
If found, you will see log entries like this:

9/11/03 6:12:54 AM : <<< AUTH LOGIN
9/11/03 6:12:54 AM : >>> 334 VXNlcm5hbWU6
9/11/03 6:12:54 AM : <<< YmFja3Vw
9/11/03 6:12:54 AM : >>> 334 UGFzc3dvcmQ6
9/11/03 6:12:54 AM : <<< ########
9/11/03 6:12:54 AM : >>> 235 LOGIN authentication successful

- Use a base-64 converter such as http://www.wc.cc.va.us/dtod/base64/ to decode the characters above, and you will see what account is being used to break into your server.

9/11/03 6:12:54 AM : >>> 334 Username:
9/11/03 6:12:54 AM : <<< backup
9/11/03 6:12:54 AM : >>> 334 Password:
9/11/03 6:12:54 AM : <<< ########
9/11/03 6:12:54 AM : >>> 235 LOGIN authentication successful

Some helpful (hopefully) information about our Blue Steel mystery person...

I visited the Blue Steel website, or at least one of them, and in the FAQ (www.grasphere.com/twt/faq.html)found the toll-free number, (888-271-1767).  Of course I called and left a message, (no, not for their product...) :) , and then I searched out that number on Google and found it on another site, (www.devineworld.com), which has the phone number 310-459-2111, so I traced that number and found the following information listed in Google.

Ruedi Devine, (310) 459-2111, 18219 Coastline Dr, Malibu, CA 90265
R Schinz, (310) 459-2111, 18219 Coastline Dr, Malibu, CA 90265

Hope this helps.

Let me know if there is anything from this...  I am sick of spam...

fINSTER (tHE rEAL oNE)

fINSTER, what does any of this have to do with a company called Blue Steel??  Don't bother those poor people!  All of the spam being talked about in this thread is using a bluestell** email address (bluestell, not bluesteel) and is coming from China.

===================

To quote Posapay,

"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."

===================

Return-Path: <bluestellfg@hotmail.com>
Return-Path: <bluestellem@msn.com>
Return-Path: <bluestellkg@aol.com>
Return-Path: <bluestellod@msn.com>
Return-Path: <bluestelllj@earthlink.net>

Please forgive me if I'm wrong, but aren't the spam in question just a little like the ones I have listed above?  Perhaps we're getting different spam.  If so, I apologize.

If your spam, and my spam ARE from the same people, whom I like to think of as 'The Penis People', then the information I posted before should at least be considered a lead.

Roxanne, I could be WAY off base here, and I definately don't want to send the dogs after the wrong fox, so to speak.  I found this thread because of my search for the people responsible for the spam in my inbox.  I don't want to have to change my email address or email domain because of some yahoo.  (pun intended).

If our spam IS the same stuff, simply follow the trail I outlined in my first post and check it out for yourself...

BTW, I'm not even sure there is anything we can do realistically or legally with this matter anyway.  At least not from my out-of-country perspective.  My tiny home-based business can muster little.

Anyway.  Please respond and let me know if I am really this clever or not.

Thanks.

fINSTER

fINSTER and roxannes,
you both have made a point, and while you both have your argument for it, these won't solve the issue with Exchange.

The patches are great.. the password changing is nice fix.
But I'm assuming, if one "person/company/hacker" was able to do it, then can others also do the same?

Can easy passwords be compromised in the future?
What can be done against it, and how are these passwords compromised?

I don't care if people like bluestell are out there or not, as long as the servers have proper protection, their existence won't even be known.

So how does a password compromise start?
What type of software is used for that, and how?
Any particular ports in use that admins should watch and log?


BTW...I wouldn't mind smacking the person that spamed my server...but unfortunately that won't solve the server's vulnerability.
Also... THANKS TO EVERYONE FOR YOUR HELP!
-Peter

hi, i did all what they said here to solve the problem described in the 2 first sections.
1/took the server offline
2/monitoring
3/after resetting the passwords and deleting unknown administrator accounts i saw indeed a backup user trying to connect
4/applied the post sp4 fix (ms02-11) included and all nt hotfixes available
5/queue kept on filling so i added all internal recepients to the restrictions tab and turned on relay to these ipadresses with all others blank
result : bluestell stopped ; a few <> appeared for 10 minutes and then mailserver was clean

i tried sending / receiving after applying all this and left
now i'm getting 550 5.7.1 relaying prohibited when sending to that domain.
telnetting is blocked so i can't check remote.
any suggestions on this ?
thanks

Can you post more details? Have you checked www.ordb.org to see whether you re blacklisted or not? Misconfigured client / server? CAn you say more about what you did in step 5? The procedure i described above, except my exchange server has also being applied to 23 more exchange servers (in different domains)without any complications. Can you describe the configuration of your routing restrictions. Normally you dont have to fill in any ips . Sorry for the late post but i m out of the office most of the time.
Good luck and keep us informed
George

I have the same problem "Bluestell" spam mail.
I have followed all the Georgeks steps but the problem still exist.
I have changed all administrator users password with very strong password but I have always the same problem, in the event log I found:
Connection from 211.158.51.155 was successfully authenticated (AUTH LOGIN) as \administrator.
And many message in the outboud queue.
PLEASE HELP ME!!!!THANKS!!!

I am having the same symptons on our server.  Here are the steps I tackled to date:

1 - took the server out of production and updated all the patches for Exchange 5.5
2 - enabled all the logging to look for an account that might be used to send SPAM
3 - changed the password for every user, service, etc. on the NT box
4 - cleared out the pending emails
5 - basically, did everything listed here but the SPAM is STILL coming...

We run Norton Anti-Virus and a Trojan/Worm program, but they find nothing.

Anybody have any more ideas to resolve?

Add every IP you find in the event log to the 'IP addresses that can NEVER relay' box that under 'relay restrictions' on the routing tab.
Also, uncheck the box next to 'hosts and clients that successfully authenticate'.
Check the box next to 'hosts and clients with these IP addresses', but leave that box blank!

Hope this helps.

Corie

Ok, I had this problem last week and it took about 6 or 7 hours to resolve. I tried everything that was posted up here through 9/23 but nothing worked. Ultimately, I applied the MS patch, stopped Exchange, deleted the in and out queues (yes emails will be lost) and then removed the Internet Mail Service and then re-created it. The user's Exchange box has been bluestell and NDR free for a week solid now, although I can see remote machines trying to connect using an \abc and an \administrator account. This might be worth a shot if you've tried everything else.

I had the bluestell spam here as well, and when I followed several of the steps above I found that the account that was connecting to our exchange server was one that did not exist on the machine at all. (nor on our domain).

It was "admin". So I creat