How to find password hacks in your Kerio Mailserver log

I had a call this morning from a customer who found that he had been put on various blacklists. When he examined his mail log, he could easily see why: his server was sending out thousands of spam emails directly through the Kerio® server. That's when he called me for help.

What he had noticed in the log was messages like this:

[03/Aug/2012 14:05:21] Sent: Queue-ID: 501c1268-0001243c, Recipient:
<acarbon@netzero.net>, Result: failed, Status: 5.1.1 550 acarbon@netzero.net
is not a valid user

[03/Aug/2012 14:05:21] Sent: Queue-ID: 501c1268-0001243c, Recipient:
<acardona@epix.net>, Result: failed, Status: 5.1.1 550 #5.1.0 Address rejected.

[03/Aug/2012 14:05:21] Sent: Queue-ID: 501c1268-0001243c, Recipient:
<acarenas@aol.com>, Result: failed, Status: 5.1.1 550 5.1.1 <acarenas@aol.com>:
Recipient address rejected: aol.com

Those are simply the end result, however, and won't help us find out who or what is sending these. My first suspicion, of course, was a compromised machine, but he had already checked every machine - none were infected.

To find the source, I asked him to log into his Linux mail server. We could find what we need on a Windows server, but it's quicker with Linux (or if you have Cygwin on Windows). I asked him to cd to /opt/kerio/mailserver/store/logs and do this:

grep 501c1268-0001243c mail.log | head -1
 

On Windows the logs are in Program Files\Kerio\mailserver\store\logs by default unless you have put Store somewhere else - then it could be (for example) D:\keriostore\logs (or whatever you called it). You can just open the log file with NotePad and search for things that way. Not as quick as Linux or Mac but you can do it.

The "501c1268-0001243c" is the Queue-ID: for one of the messages. The "grep" extracts all lines matching that id and the "head -1" strips out all but the very first, which gives us:

[03/Aug/2012 14:03:27] Recv: Queue-ID: 501c1268-0001243c, Service: SMTP,
From: <admin@redbullcarwrap.com>, To: <acaraballo@adelphia.net>, Size: 2275,
Sender-Host: 173.16.65.213, User: sales@xxxxxxxxxxxxxxxx.com
 

This line tells us that the user responsible for sending this message is "sales".

My customer immediately said: "But sales isn't a real user!"

Well, it has to be. I asked him to look into his configuration and sure enough, "sales" was defined, but only to forward everything to other users. Most likely it was defined a long time ago and because nobody actually ever logged in as "sales", the password was weak - nobody thought about it.

So, this hacker guessed the password and was able to relay spam email. A simple fix was to change the password to something long and obscure. For good measure, he also blocked that ip at the firewall, though I warned him that these spammers don't use their IP's for long, so it could end up owned by someone legitimate later - he should take the block off after a few weeks.

Wrong method for 'sales'

That sales user never should have existed, however. It should have been an alias for a real user or a group delivering to multiple users. It could also be an alias delivering to a public folder, but it should not be a real user.

Why? An alias or group can never be used to authenticate. It has no password - it can receive mail, and you can use it as a "reply-to" address, advertise it on your website and on business cards. but it can never be used to send email - therefore it is inherently more secure. You should consider that when creating accounts like "sales", "service" and the like - there is no reason for them to be real users.

For that matter, there's no need for your own email address to match what you want people to use when sending you mail. If your email is "bob@xxxxx.com", you could have "bob" be an alias for an address like "b06by" and you'd use THAT for authentication, thereby making your advertised email address ("bob@xxxxx.com") immune to password guessing. Of course that "b06by" will be visible in email headers, but it does improve security.

By the way, that's not a bad idea for your administrative accounts also. As noted at 10 crazy IT security tricks that actually work:

Renaming privileged accounts to something less obvious than "administrator" is often slammed as a wasteful, "security by obscurity" defense. However, this simple security strategy works. If the attacker hasn't already made it inside your network or host, there's little reason to believe they'll be able to readily discern the new names for your privileged accounts. If they don't know the names, they can't mount a successful password-guessing campaign against them.

Comments?

More Articles by Anthony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.