Re: Recent Phishing Uptick

[Paul Chauvet <chauvetp () NEWPALTZ EDU>]

That is a FANTASTIC idea. There are sites which are often used for phishing but not exclusively enough that we can 
block them. Doing that (via our Ironport of those URLs are detected) is a great idea. 

We will probably be implementing this here. My sincere thanks for this idea! 

P.S. Would you be willing to share (on-list or off-list) a list of the URLs of these hosting services that you use this 
for? 

Paul Chauvet 
Senior Linux Systems Administrator 
Chair, Information Security Oversight Committee 
Computer Services 
State University of New York at New Paltz 

Phone: (845) 257-3828 
chauvetp () newpaltz edu 

----- Original Message -----

> Speaking of phishing forms on the free hosting sites We watch for a
> couple dozen of those hostnames in email messages and add this
> warning at the top of the message before delivering it:

> Warning: Do not enter your USU A-Number and password on any web form
> linked from this email message. This warning has been inserted here
> by Utah State University's IronPort Spam Filter System.
> The USU spam filter has detected in the message below a link to a web
> form hosting service ( link ) that is SOMETIMES used by "phishers"
> to get your email address and password for their use. You must
> decide if the link might serve some other legitimate purpose that is
> important to you. Thanks for being an Internet Skeptic!

> For information about why this warning was added to this message see:
> https://it.usu.edu/computer-security/be-an-internet-skeptic/form-services/

> ==== ORIGINAL MESSAGE BEGINS BELOW THIS LINE ====
> and I get a Bcc: of the message and report the link to the hosting
> site. Some hosts are very prompt (minutes) about disabling the form
> while others can take a day or more.

> Bob Bayn SER 301 (435)797-2396 IT Security Team
> Office of Information Technology, Utah State University
> Do you know the "Skeptical Hover Technique" and
> how to tell where a web link really goes? See:
> https://it.usu.edu/computer-security/computer-security-threats/articleID=23737

> From: The EDUCAUSE Security Constituent Group Listserv
> [SECURITY () LISTSERV EDUCAUSE EDU] on behalf of David Curry
> [david.curry () NEWSCHOOL EDU]
> Sent: Wednesday, February 19, 2014 6:15 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Recent Phishing Uptick

> We are also a Google Apps school. Starting in mid-November and
> increasing until now it's occurring two or three times a week, users
> in our domain have been receiving phishing emails sent by other user
> accounts within our domain. The attempts are all pretty rudimentary:
> "your email is over quota," "security upgrades mean you need to
> confirm your information," etc. with a link to a form on some free
> web hosting site (yolasite or other). No logos or other trickiness,
> just plain text written by folks with varying degrees of English
> proficiency. The content is not what has us concerned, the volume
> is. We've had nearly two dozen of them (different senders) since the
> first of this year.

> What's been confusing us is that every single one of these appears to
> have been sent directly from Google, i.e., the sender was logged
> into the Gmail account. They were not sent from outside our domain,
> or dumped in via some open relay. This seems to be confirmed by the
> fact that, with two exceptions, each compromised account has sent
> one, and only one phishing email--we're guessing this is because as
> soon as we receive a phishing email, we try to contact the owner of
> the account and have him/her change his/her password. The only two
> exceptions were people we were not able to contact quickly.
> Sometimes Google beats us to it and disables the accounts for
> sending spam, but not always.

> Just this week, I started looking at the Google Admin Reporting SDK,
> which lets you retrieve, among other things, a login history for an
> account, including IP address, AND, whether or not Google called it
> a "suspicious" login. It's not completely clear what "suspicious"
> means, but it seems they will flag it if you login from an
> unfamiliar IP range, or two widely separated geographic areas in a
> short time. If you'd like to try this on your domain:

> 1. Sign in to your domain with an account that has Super Admin
> privileges
> 2. Enable the Admin Reporting API on your domain if you haven't
> already
> 3. Visit Google's API Explorer (
> https://developers.google.com/apis-explorer/#p/admin/reports_v1/ )
> 4. Click on "reports.activities.list"
> 5. At the top right of the page, click the "off" switch to "on" to
> authenticate via OAuth2.0
> 6. Put a user email address in the 'userKey' field (e.g.,
> user () yourdomain edu )
> 7. Put 'login' in the 'applicationName' field
> 8. Click 'Execute'

> Now you can use your browser search function to look for the word
> "suspicious", or just browse through the output looking for
> interesting things. I did this yesterday for four or five of our
> accounts that had sent phishing emails recently, and found some
> interesting things:

> * For all but one of the accounts, Google had identified a
> "suspicious" login. All of these came from Nigeria -- two different
> ISPs there.
> * For the one account that didn't have a suspicious login, the
> account was clearly "owned" by the bad guys; ALL the logins for the
> past few months came from Nigeria and the UK (my guess is that the
> "suspicious" login occurred so long ago it's no longer in the
> history).
> * The "suspicious" login occurred at least two weeks before the
> account was used to send the phishing email. There was one exception
> where it occurred a couple of days before.
> * In most cases, the accounts seemed to get logged into multiple
> times between the first suspicious login and the sending of the
> phishing email.
> * Once the user changed his/her password, the unauthorized logins
> stopped.

> The above was all a terribly manual process--look up the data in API
> Explorer, manually read through JSON-formatted output, look IPs up
> in geolocation and ASN databases, etc. My new project is putting
> together an automated version of the steps above to dig up
> information about these accounts. I'm hoping that the accounts all
> exhibit the same characteristics, which might mean a script that
> runs nightly looking for suspicious logins from suspicious locations
> (e.g., Nigeria) can be developed and we can, maybe, start taking
> some proactive action.

> One thing that still has us puzzled, though, is how all these
> accounts got (or are getting) compromised. Is it just users
> responding to phishing emails and filling out the forms? Or was it
> some major event (the Adobe compromise comes to mind from a timing
> standpoint, but we have no evidence to suggest it had anything to do
> with this)?

> Sorry for the length of this response. But honestly, I'm a little
> relived to hear that someone else is having the same (or similar)
> problem, and it's not just us.

> --Dave

> --
> DAVID A. CURRY, CISSP • DIRECTOR OF INFORMATION SECURITY
> THE NEW SCHOOL • 55 W. 13TH STREET • NEW YORK, NY 10011
> +1 212 229-5300 x4728 • david.curry () newschool edu

> On Wed, Feb 19, 2014 at 6:15 PM, Peter Setlak < psetlak () colgate edu >
> wrote:

> > Over the past few weeks we saw a dramatic increase in the level and
> > sophistication of phishing against our domain. The phishers not
> > only
> > used compromised accounts from other Universities but from our own
> > as well. They also copied some images from our main website as well
> > as screen-scraped our accounts-reset page.

> > There seem to have been two different campaigns going; one more
> > sophisticated than the other.

> > They only sent emails at night or early morning, none were sent to
> > my
> > inbox (security admin).

> > We use Google Apps and of course, they were of no real help.

> > I was able to track down the logins from an IP range owned by
> > Spotflux VPN services ( spotflux.com ). The IP range was
> > 162.210.196.160-175.

> > We also saw logins from a Nigerian IP range (41.203.69.x).

> > After contacting their support, one of their techs was able to
> > correlate some information and found 142 different machines in the
> > Nigerian IP range was using their VPN service. He null-routed them
> > and it has been a few hours but we have not seen any logins since.

> > Has anyone else seen this uptick in phishing?
>
> > Has anyone else seen these IP ranges knocking at their doors?
>
> > Has anyone else seen this scenario before?
>
> > Does anyone have suggestions for working with Google to get better
> > reporting and options?

> > I would really like to see the ability to do two things through
> > Google:

> > 1. Deny certain IP ranges from successfully authenticating into our
> > domain. Obviously, Google has to allow all users from anywhere use
> > their services; if I could set our App domain to automatically log
> > someone out if they logged-in from a certain IP range, that would
> > be
> > very helpful. We have no students in Nigeria (currently).

> > 2. Pull an email from users' inboxes before they respond. In this
> > case, perhaps the first 15 users in my domain might see and click
> > on
> > the email - hopefully at least one sends it to ITS. Then, we could
> > pull that email from the remaining users' inboxes before they ever
> > get a chance to open it.

> > Perhaps there is something Google offers or a Google-integrated
> > third-party offers that would allow me to do this?

> > --

> > Thank you,

> > Peter J. Setlak
>
> > Network Security Analyst, GSEC, GLEG, GCPM
>
> > Colgate University
>
> > ---
>
> > psetlak () colgate edu
>
> > (315) 228-7151
>
> > Case-Geyer 450
>
> > skype: petersetlak

> > Think Green! Please consider the environment before printing this
> > email.

> > Engage with Colgate University:

> > News blog , Twitter , Facebook , Google+ , Delicious , YouTube ,
> > Flickr , Pinterest , LinkedIn