Re: Dealing with compromised Zimbra accounts

[Adam Cody <ajcody@zimbra.com>]

FYI - don't have time to look it up atm, but I believe there's been a/some rfe's filed to handle the disconnect web sessions and tracking of info/details to handle the spam highjacker situation. I'll try to remember to follow up and post rfe # if I get time later incase no one else does.

Adam

----- "Matt Mencel" <MR-Mencel@wiu.edu> wrote:

> My cohort can answer better than me as he's done most of the work
> concerning this.....but...we've kind of discovered a few things about
> spammers using our Zimbra...
> 
> 1)  The spammers don't waste much time sending single messages, except
> while testing which maybe helps our little trap.
> 2)  The spammers automation stuff only seems to work in the
> HTML(Standard) client.
> 
> So, when we find an outgoing message with an envelope that contains
> more than X (I think 50) recipients AND it's been sent from the
> HTML(Standard) client, we dump it into a queue and don't deliver until
> it's manually reviewed by an administrator.
> 
> I'd guess we're catching almost 100% of the outgoing SPAM attempts now
> when an account gets compromised.  The AJAX client may be too
> difficult for them to script around(I'm guessing), and they like to
> send to LOTS of recipients.  We've only found one or two valid senders
> who have been caught so far....and they've either switched back to the
> AJAX client or understand why we delay their multi-recipient
> messages.
> 
> Phishing is one of those issues that separates the regular people from
> the idiots....and we seem to have our fair share of the latter here. 
> Not only do they continue to respond after lots of training and high
> profile example cases....but they respond when the message is
> delivered TO THE JUNK!! folder...AND...the subject line INCLUDES some
> text that reads [Fraud Alert: Suspected SPAM]....
> 
> HELLOOO???  The lights are on but no one is home.....I imagine the
> thought process goes like this...
> 
> ....must...fight...urge....but...I...have....no....common...sense...
> must...hit..."Reply"
> button....and...give...away...my...private...info...
> 
> 
> It's cause for much consternation....but we do get a few laughs out of
> it sometimes.  Maybe immense public ridicule would work?  :)
> 
> Matt
> 
> 
> 
> ----- Original Message -----
> From: "Tom Golson" <tgolson@tamu.edu>
> To: "Steve Hillman" <hillman@sfu.ca>
> Cc: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> Sent: Tuesday, January 13, 2009 2:41:10 PM GMT -06:00 US/Canada
> Central
> Subject: Re: Dealing with compromised Zimbra accounts
> 
> It has been our experience that setting the zimbraAccountStatus to
> "locked" does kill the current session.  But you're right -- if used
> as
> a "toggle" there's no useful effect.  The mailbox has to remain
> locked
> long enough for the spammer to lose interest.
> 
> We use a semi-automated process of monitoring outbound message rates
> and
> triggering alerts.  Since our customers do have the unfortunate habit
> of
>  sending mail to massive lists of people, we try to verify messages
> as
> being "spam" before we take punitive action.
> 
> If an account is compromised, one of our admins will trigger a
> process
> to scramble the customer's password, lock their mailbox and send a
> notice to our help desk so they can conduct "customer education".  We
> do
> leave the mailbox locked until the customer has been contacted and
> reset
> their password.
> 
> Inbound, we make very heavy use of the anti-phishing-mail-reply group
> that was spun off from the hied-email-admin list onto Google groups. 
> It
> is an excellent resource.
> 
> --Tom
> 
> Steve Hillman wrote:
> > Hi folks,
> >   Now that we've moved all of our students over to our Zimbra
> implementation, we're starting to see Zimbra accounts get used for
> spamming (after being successfully phished) -- we've had 3 in the last
> 3 days.
> > 
> > We're having to invent new ways of dealing with these -- simply
> changing the password or locking the account doesn't actually stop the
> current session. Our session timeout is 12 hours, so this would allow
> the spammer to keep functioning for quite awhile unless we can kill
> the session programmatically. 
> > 
> > I've found that setting the account to 'maintenance' mode will
> terminate the session *if* the end-user tries to do anything while
> it's in that state, but it's not enough to just flip the account into
> maintenance and back out.
> > 
> > I'm just wondering if any other sites are dealing with this yet, and
> if so, if you've figured out a semi-automated way of locking and
> unlocking the accounts?
> > 
> > (btw, we're also looking at Milters to do password detection (to
> prevent the phished account in the first place) and outbound rate
> limiting (to limit the damage the spammer can do), so if any of you
> are doing/done any work in this area, I'd love to hear about it
> too..)
> >