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:
<>, Result: failed, Status: 5.1.1 550
is not a valid user

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

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

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: <>, To: <>, Size: 2275,
Sender-Host:, User:

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 "", 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 ("") 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.

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> How to find password hacks in your Kerio Mailserver log

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us