Link to home
Start Free TrialLog in
Avatar of DuffyS40
DuffyS40

asked on

Exchange 2003 used as a relay, help please.

I have one Exchange 2003 SP2, its currently spamming out like mad, I logged the transactions and they are from outside, I have already stopped any relay under Virtual-SMTP, changed the Admin password, changed the users passwords, yet they are still coming through, I dont think its from internal PC because all the IPs are showing as external, such as from Holland, Canada etc.

What else can I do to stop this relay ??

Heres part of the log file:
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2012-06-29 11:52:12
#Fields: date time c-ip cs-username s-ip s-port cs-host
2012-06-29 11:52:12 75.180.132.243 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 66.54.152.4 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 75.180.132.243 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 46.4.167.9 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 46.4.167.9 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 80.113.5.98 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 75.180.132.243 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 193.85.160.138 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 212.79.230.246 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 212.79.230.246 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionResponse - 25 -
2012-06-29 11:52:12 178.79.147.207 OutboundConnectionCommand - 25 -
2012-06-29 11:52:12 212.79.230.246 OutboundConnectionResponse - 25 -
Avatar of Alan Hardisty
Alan Hardisty
Flag of United Kingdom of Great Britain and Northern Ireland image

One of the more common issues that you may be facing is an Authenticated Relay which my article should help you tackle:

https://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/A_2556-Why-are-my-outbound-queues-filling-up-with-mail-I-didn't-send.html

After you have changed passwords - you need to restart the SMTP Service or the changes won't be effective and spammers can continue to use the old password!

If it isn't relevant, please let me know.

Alan
Hello,

You can test your mail server from the external to know if you are open relay or not.

http://www.mailradar.com/openrelay/

If you are: your Exchange is misconfigured
If you are not: You need to work on your computers :)
When you enable relaying on your server, make sure that you choose the option only the servers listred below and enter the IP address of your main server. If you do not enable that, then you become an open relay.
Avatar of DuffyS40
DuffyS40

ASKER

Hi all, thanks for the replies.
I have narrowed it down to the server (or may be even some of the workstations),
Currently, even if I unplugged the cable, the server still generates around 300 NDRs per minute,throwing them into the queue, this has the effect of slowing the server down to a crawl, if I shutdown SMTP, then the queue would stop filling but they are refilled again as soon as SMTP service are running, so they are generated from the server, under ESM's queue page, there are almost 6000 folders, but the most filled ones are AOL.com/Yahoo.com etc , normally these are the ones that gets filled up really fast.
I have ran TDDSkiller, (AVG EMail server already installed and ran) but without luck.

I have just cloned the server onto a test server with faster hardware (Quad 3GHz and Raptors) but even on this its slow when the SMTP are running, so I am assuming that its doing something heavy in the background, the only thing that may looked out of place is the inetinfo.exe running, killed and its back, but the file location is genuine, so I am guessing could the IIS be infected and using something to run this worm or virus to spam ?

Reason for this is because I want to try running the Kaspersky /Panda / whatever Rescue CD to see if they can ID the source, this way at least I know what I am dealing with, and these dont work on RAID.
NDR's are due to a lack of Recipient Filtering and an NDR attack.

With the LAN cable unplugged, the sheer volume of emails generated means Exchange cannot cope with the amount of mail, so queues them up in memory and adds them to the queue as and when it can, so once you pull out the LAN cable, it will still queue what it has already been sent.

Do you receive emails directly or via a 3rd party?  If direct - make sure you enable Recipient Filtering as per my article.  If via a 3rd party - then they need to do Recipient Filtering - or stop using them.

You will probably find yourself listed on www.backscatterer.org (check on www.mxtoolbox.com/blacklists.aspx).  If you are - then that is because of the NDR's hitting spam traps on their servers.

If you are looking for a virus - I doubt you have one.
Hi Alan, thank you for your time, the IP is not listed on backscattrer, but said it did in the past.
I am running out of ideas now, I tried last night unplug the cable, and waited 30 mins, they were still coming out fast, around 300/min.
On my test server here now (cloned from original), without LAN, does the same thing, it did find the same trojans as on the live server yesterday but this dont seem to make much difference.Yes, done the filtering and restarted SMTP (would have if not after o many restartss)
I done a kaspersky rescue CD virus scan on the test server, nothing found,I done the usual tarpit@5 and relay according to Sambee, so I am really am baffled now and stuck for some solutions.
Okay.  If you plug in the LAN cable but disable port 25 and 443 to your server from your router / firewall, do the queues still fill up?

Who is the sender of the emails?  Postmaster or random people not on your network?
Hi Alan,
Closing 25 and 443 made no difference, left running for 5 mins, every min around 600-700 showing.
Postmaster are the main ones, there were a few from random or no ID.
When I open SMTP, the whole network would slowed down, especially internet, so something is working their socks off in the background dumping out spams?
Okay - so it sounds more likely that you have an infected PC on your network.  How many do you have and how many are switched on?

If you download and install Wireshark on a computer - then start it scanning and then record the traffic and then filter the SMTP traffic, you should hopefully see one PC that is very busy.

Once you have found the busy PC - get cleaning it with MalwareBytes or an AV package etc.
Hi Alan
We tried wireshark last night, nothing really moved on the network, there are around 30+ PCs, and onld 2 or 13 on at the time, if the queue still building this fast without the LAN cable, could it be just the server ?
I just done another scan on the test server using Avast Email Server's boot scan, which normally would find a lot of hidden objects, but came back clean.
ASKER CERTIFIED SOLUTION
Avatar of Alan Hardisty
Alan Hardisty
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi Alan,
Thanks very much for your help.
I think we found the solution, but not totally sure about the cause, this is how I view the problem.
The worm/trojans generated the fake emails, but they are generating from within and sent to within, hence theres always domething going into the queue but never leaves the building, unplug the cable make little difference as it doesnt even need to leave the machine, shutdown SMTP just paused the process.
Last night while monitoring the queue, I were deleting them manually using the FIND option to show all the emails within individual folder, so if it found say 3000 junk, I delete them, it shows under ESM's queue as gone, but in the physical queue folder \ProgFile\Exch\Mailroot\VS1\Queue .. that number stayed the same, that had me baffled.

But using the Aqadmcli, I could delete all in one go, this stopped them from repopulating, so I am guessing the worm/virus generated tons of them, but they are done badly, ratehr than spamming out, they spam back, now the NDR is returning them, but to the same location, creating the endless loop.

Make any sense to you ?  Now the ESM queue is clear, the mailroot folder is clear.
Thank you.
Good news that the queue is clear.  Keep an eye on it over the next few days and if it pops up again, let me know.

Gotta love aqadmcli.exe :D

Thanks for the points

Alan