Re: Dealing with compromised Zimbra accounts

[Adam Cody <ajcody@zimbra.com>]

Not sure if this was the one I was recalling or not:

http://bugzilla.zimbra.com/show_bug.cgi?id=34054
probably related : http://bugzilla.zimbra.com/show_bug.cgi?id=3204

not sure about this one...
http://bugzilla.zimbra.com/show_bug.cgi?id=34441

Looks like they need some Votes/Comments... do as you will.

Adam

----- "Adam Cody" <ajcody@zimbra.com> wrote:

> 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..)
> > >