Page 2 of 2

Identify compromised accounts

Posted: Thu May 01, 2014 6:49 pm
by 7310pyperdown
Just got hosed by this exact situation today, and my booby-trap didn't catch it. Will take a look-see at the sasl_username and see if that proves more effective. If you have any code for this I'd sure love to see this.
[quote user="drwho18"]The script posted above is a good idea, however it doesn't really stop an in process attack (at least on my Zimbra setup). It checks for "auth ok" of which I tend to see a few, the spammer appears to hold smtp open and I see each send tagged with a "sasl_username" in the logs, checking the message ID out I see it was a new message with fresh recipients. I have modded the script to check for sasl_username, as I think that is more relevant to trip off a spam notice, however locking the account does not stop said account from continuing to spam through the server. If it tries to come in from a new IP it will try to reauth and fail fine, but I believe it will continue to function untl the SMTP session is stopped, by which time a lot of damage can be done to a mail servers reputation. Any ideas how to stop this, or reduce the max SMTP session time or something would be the way to go. I wish every sasl_username request was an actual auth attemp, maybe saslauthd is caching by default on zimbra?[/QUOTE]

Identify compromised accounts

Posted: Thu May 01, 2014 7:43 pm
by 7310pyperdown
I ended up with something very similar (in the grep/sed/awk commands)... added a logrotation at the end, so that th euser's account can get unlocked once appropriate measures are taken (strung up by thumbs, teaching moment exploited, password changed, etc)


# checks log file and gets a count of authentications sent per minute, per user

# and if the count exceeds the maxmails value the user's account is locked.







touch $accounts
su zimbra -c "/opt/zimbra/bin/zmaccts" | grep "@" | grep active | awk '{print $1}' > $accounts
#zgrep -i "auth ok" $logfile | sed 's/ / /g' | awk -F"[ :]" '{print $3":"$4,$11;}' | uniq -c | sort -n |

#zgrep -i "auth ok" $logfile | sed 's/' | sed 's/ / /g' | awk -F"[ :]" '{print $3":"$4,$11;}' | uniq -c | sort -n |

zgrep -i "sasl_username" $logfile | sed 's/' |sed 's/ / /g' | awk -F"[ :]" '{print $3":"$4,$13;}' | sed 's/sasl_username=//g' | uniq -c | sort -n |

while read line


count=`echo ${line} | cut -d' ' -f 1`

userid=`echo ${line} | cut -d' ' -f 3`

timestamp=`echo ${line} | cut -d' ' -f 2`

active=`grep "$userid@$mydomain" $accounts`
if [ "$count" -gt "$maxmails" ] && [ "$active" == "$userid@$mydomain" ]; then

echo "Maximum email rate exceeded, $userid@$mydomain will be locked"

su zimbra -c "/opt/zimbra/bin/zmprov ma $userid@$mydomain zimbraAccountStatus locked"

subject="$userid account locked due to excessive connections"

# Email text/message


echo "$userid account has been locked as there were $count connections made at"> $message

echo "$timestamp. Please have the user change their password, and check for phishing" >>$message

echo "emails if possible." >>$message

# send an email using /bin/mail

/usr/bin/mail -s "$subject" "$support"
rm -f $message

# set flag to rotate logs so that after mitigation the account does not automatically re-lock


#update list of active accounts

su zimbra -c "/opt/zimbra/bin/zmaccts" | grep "@" | grep active | awk '{print $1}' > $accounts


if [ $rotate -eq "1" ]; then

#rotate the logs

logrotate -f $logrotate_conf


rm -f $accounts

Identify compromised accounts

Posted: Thu May 01, 2014 8:10 pm
by quanah
You have to restart postfix for this to be effective, unfortunately. :/ As I noted previously, they are using a permanent smtp connection, there are not actually additional sasl_auth's occurring, that's an artifact of postfix logging. The only way to close out the connection is to restart postfix.

Identify compromised accounts

Posted: Thu May 01, 2014 8:13 pm
by quanah
Also, I'd write my own script to get the accounts via ldap, that just pulls active accounts. ;)

Identify compromised accounts

Posted: Fri May 02, 2014 5:16 am
by Klug
Quanah, does the same "caching/closing connection issue" exist when a password is changed?

Identify compromised accounts

Posted: Fri May 02, 2014 11:43 am
by quanah
There is no "caching" issue. Persistent connections are part of the SMTP specifications, and not interrupting established connections arbitrarily is also part of the SMTP specifications. The only way to force close an established connection is to restart postfix. I already had a bit of a discussion about this with Wietse. ;)

Identify compromised accounts

Posted: Mon May 05, 2014 6:16 am
by Klug
OK, got it...

As long as the spammer is connected, we're doomed. And we need to restart postfix.

Identify compromised accounts

Posted: Tue Jul 15, 2014 10:33 am
by essential_mix
If they used auth token, need to check which token is sending email and after that figure out, which user was used to create this token.

Re: Identify compromised accounts

Posted: Wed Apr 25, 2018 10:01 am
by milos.cuculovic
The shell script works so nice, thank you very much.

I have a question: let's asume we are able to solve the issue by changing the compromised user password within the same day, the script will lock it again. What do you think would be the best solution to solve this issue?
What came to my mind:

- Add a whitelist of solved accounts, but needs to be manually done and may be forgotten to then remove the solved user from that list later on
- A better solution would be to check when was the user's password changed last time? If the password change time is greater than the compromised time, then we can ignore it.

What do you think about?