Re: Recent Phishing Uptick

["Joel L. Rosenblatt" <joel () COLUMBIA EDU>]

I think that this is a bug in their report - our users log in using
saml when the use the web interface and password when they use their
device password - we only give Google the device passwords, which are
only used to log in using phones or if someone wants to do IMAP
directly to Google

I have been trying to send them a bug report, but their seems to be a
bug in that process :-) ... it's keeps on dumping me back on the admin
page

When I get an answer from Google, I will pass along what I find out

Thanks,
Joel


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


On Thu, Feb 20, 2014 at 4:20 PM, David Curry <david.curry () newschool edu> wrote:
> I knew I saw that somewhere once.... but then I couldn't find it again when
> I wanted it.
>
> Anyway, I did manage to get some password output. In our domain, we use
> separate accounts for Google Administrators, and they are password-based
> rather than SAML (so that we can get into the admin console if our SAML
> stuff is down or broken). If I look up my administrator account then, I get:
>
> {
> "kind": "admin#reports#activity",
> "id": {
> "time": "2014-02-18T20:30:10.000Z",
> "uniqueQualifier": "51101285xxxxxxxxxx",
> "applicationName": "login",
> "customerId": "C01fxxxxx"
> },
> "etag": "\"D9R4-hwaf8ZZEeXP-Hlyt8X8_a4/2BI0VOjS5a2l7kvuxxxxxxxxxx\"",
> "actor": {
> "email": "xxxxx () newschool edu",
> "profileId": "1170122297xxxxxxxxxx"
> },
> "ipAddress": "149.31.xx.xxx",
> "events": [
> {
> "type": "login",
> "name": "login_success",
> "parameters": [
> {
> "name": "login_type",
> "value": "google_password"
> }
> ]
> }
> ]
> },
>
> But I have yet to see this for a "regular" user (who would be using SAML).
>
> I'm still guessing that they're only looking at the web interface. Part of
> my reason for thinking this, aside from the fact that both I and you are
> both seeing only SAML events, is that they do not have any indicator in the
> output of what interface was logged into (web, pop, imap, android, etc.).
> Also, I think what's being recorded is ANY login to Google Apps, not just
> Gmail. So if you log in directly to Drive or Sites, for example, it would
> record that as well.
>
> Over in the reports.userUsageReport.get report you can get some more
> granular last login information, but it's only the most recent time, not a
> list of times:
>
> {
> "name": "accounts:last_login_time",
> "datetimeValue": "2014-02-15T08:36:41.000Z"
> },
> {
> "name": "accounts:last_sso_time",
> "datetimeValue": "2014-02-12T19:45:12.000Z"
> },
> {
> "name": "docs:last_interaction_time",
> "datetimeValue": "2014-02-13T14:00:26.000Z"
> },
> {
> "name": "gmail:last_access_time",
> "datetimeValue": "2014-02-15T07:25:02.000Z"
> },
> {
> "name": "gmail:last_imap_time",
> "datetimeValue": "2013-12-07T22:37:29.000Z"
> },
> {
> "name": "gmail:last_interaction_time",
> "datetimeValue": "2014-02-15T00:23:05.000Z"
> },
> {
> "name": "gmail:last_webmail_time",
> "datetimeValue": "2014-02-14T21:09:06.000Z"
> }
>
>  --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 Thu, Feb 20, 2014 at 2:01 PM, Joel L. Rosenblatt <joel () columbia edu>
> wrote:
> > Hi Dave,
> >
> > I found this statement:
> >
> > Note: The login activity report only audits explicit password and
> > SAML-based single sign-on (SSO) logins.
> >
> > on this page
> > https://developers.google.com/admin-sdk/reports/v1/guides/manage-audit-login
> >
> > So someone at Google thinks that they are finding both
> >
> > I will keep on digging
> >
> > Thanks,
> > Joel
> >
> >
> > 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
> >
> >
> > On Thu, Feb 20, 2014 at 1:56 PM, David Curry <david.curry () newschool edu>
> > wrote:
> > > Joel,
> > >
> > > I have not yet figured that out; I only see SAML as well. I have a
> > > suspicious that only web-based logins (and not POP/IMAP, etc.) are being
> > > recorded here, although I have not yet found a documented answer one way
> > > or
> > > the other.
> > >
> > > --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 Thu, Feb 20, 2014 at 12:49 PM, Joel L. Rosenblatt <joel () columbia edu>
> > > wrote:
> > > > Hi David,
> > > >
> > > > I have been looking at our login reports and I only see saml logins
> > > >
> > > >        "name": "login_type",
> > > >        "value": "saml"
> > > >
> > > > I am much more interested in the password logins - how do you get a
> > > > report of those?
> > > >
> > > > Thank you,
> > > > 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
> > > >
> > > >
> > > > On Wed, Feb 19, 2014 at 8:15 PM, David Curry
> > > > <david.curry () newschool edu>
> > > > wrote:
> > > > > 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:
> > > > >
> > > > > Sign in to your domain with an account that has Super Admin
> > > > > privileges
> > > > > Enable the Admin Reporting API on your domain if you haven't already
> > > > > Visit Google's API Explorer
> > > > > (https://developers.google.com/apis-explorer/#p/admin/reports_v1/)
> > > > > Click on "reports.activities.list"
> > > > > At the top right of the page, click the "off" switch to "on" to
> > > > > authenticate
> > > > > via OAuth2.0
> > > > > Put a user email address in the 'userKey' field (e.g.,
> > > > > user () yourdomain edu)
> > > > > Put 'login' in the 'applicationName' field
> > > > > 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