[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dealing with compromised Zimbra accounts
In my dealings with this, we close the account and inform our help desk about the user id. They then attempt to contact the individual. One other thing I have noticed in 2 of the 3 times I've seen this is the zimbraPrefSaveToSent attribute has been changed to false. I don't know if this is something the spammers have set, but it is curious to me.
David Emmerich
Network Specialist II - ITS Systems Administration
Eastern Illinois University
----- Original Message -----
From: "Adam Cody" <ajcody@zimbra.com>
To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
Sent: Tuesday, January 13, 2009 3:24:30 PM GMT -06:00 US/Canada Central
Subject: Re: Dealing with compromised Zimbra accounts
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..)
> >