Re: Mitigating Phishing Attacks

[Drew Perry <aperry () MURRAYSTATE EDU>]

I'll posit a different set of hiccups. We are a Google Apps for Education
University. All of our email accounts are essentially Gmail accounts. While
we have administrative user control, we no longer have the ability to block
senders or filter messages independently. However, we do have a searchable
local archive established in order to address litigation hold requests
without having to subpoena Google. In the event of a "send us your
credentials" flood, we've historically been able to search for users who've
responded with their creds and pre-emptively disable their accounts,
requiring a call to the help desk and a new password. The downside is that
newer spam runs aren't asking for replies, similar to the OWA page from the
OP, we regularly see links to a Google Docs spreadsheet form. Without an
email response, we're unable to track who actually loosed their account
upon the bad guys.
Fortunately, Google does a pretty thorough job of a) disabling our users
for us once their account is compromised, and b) stalking all those
illegitimate Google Docs forms. Typically, by the time I visit it to check
it out, it's already been disabled. We run a report daily to identify
disabled users and attempt contact to get them back up and running. We also
bop them on the nose with a rolled up newspaper and firmly say "No!"

Drew Perry
Security Analyst
Murray State University
(270) 809-4414
aperry () murraystate edu

***MSU Information Systems staff will *never* ask for your password or
other confidential information via email.***
*
*



On Wed, Nov 14, 2012 at 5:15 PM, Joel Rosenblatt <joel () columbia edu> wrote:

> Hi,
>
> This GULP presentation 
> <http://www.nysernet.org/**workshops/2011/GULP.pdf<http://www.nysernet.org/workshops/2011/GULP.pdf>>
> has a section on using GULP to discover compromised accounts
>
> Thanks,
> Joel Rosenblatt
>
> Joel Rosenblatt, Director, Network & Computer Security
> Columbia Information Security Office (CISO)
> Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> http://www.columbia.edu/~joel
> Public PGP key
> http://pgp.mit.edu:11371/pks/**lookup?op=get&search=**0x90BD740BCC7326C3<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90BD740BCC7326C3>
>
>
>
>
> --On Wednesday, November 14, 2012 4:23 PM -0600 Steven Tardy <
> sjt5 () ITS MSSTATE EDU> wrote:
>
>  0a) log all authentications(failed and successful) to a database.
> > (something homegrown similar to: Grand Unified Logging Project, GULP)
> >
> > 0b) create a database of ip addresses of "known bad guys"
> > (the phishers will keep trying from the same ip addresses)
> > export database to "known bad guy" DNSBL.
> >
> > 1) scour auth database for nigerian/anonymous-proxy logins.
> >     notify security team *immediately* of login from "known bad guy".
> >
> > 2) outbound email server hold/quarantine email on "known bad guy" DNSBL.
> >
> > 3) watch outbound queues/graphs for jumps in size.
> >
> > not perfect, but catches/prevents quite a bit.
> >
> >
> >
> >  It would be useful to know your top 3 strategies for
> > > preventing and mitigating such occurrences. Thanks.
>
>
> Joel Rosenblatt, Director, Network & Computer Security
> Columbia Information Security Office (CISO)
> Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> http://www.columbia.edu/~joel
> Public PGP key
> http://pgp.mit.edu:11371/pks/**lookup?op=get&search=**0x90BD740BCC7326C3<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90BD740BCC7326C3>