Main Nav

We have experienced a number of targeted phishing attacks recently.  Because the most recent phish led its victims to provide their network credentials via a realistic looking OWA logon page, we took the following steps to deal with some resultant compromised accounts:

 

·         immediately reset the passwords for the affected accounts,

·         restarted, the IIS service to stop any active webmail sessions

·         alerted the user community

 

 

It got me to wondering how other institutions deal with similar situations where user accounts have been compromised.  If anyone would care to share, I would be interested how you have handled similar situations. It would be useful to know your top 3 strategies for preventing and mitigating such occurrences.  Thanks.

 

 

Christopher Jones

IT Security Analyst

University of the Fraser Valley

Christopher.Jones@ufv.ca

 

 

Comments

Did the OWA phishing page embed CSS and images from your web server?

In our case it did, so I started looking into “hotlink protection” which is available in IIS7. This would result in the phishing page not displaying properly, but obviously the attacker would see this and change things up. I prefer the stealthier method, to watch server logs for hotlinking, and then take action from there.

 

My second idea was to inject javascript in the OWA page, since it appears the attackers screen scraped the login page. If the embedded javascript detected that it was loaded from a domain other than ours, it could: scramble the passwords entered into the form, request a specific url that would trigger an IDS alert on our network…

Below is what I had come up with, though I think we didn’t go that route because the admins didn’t like the idea of customizing OWA. (I have not tested the script below, use at your own risk)

 

But like you, I am very interested to see how others solve this problem.

 

if (window.location.hostname != "www.domain.com") {

    var cc = false;

    var readyStateCheckInterval = setInterval(function () {

        if (document.readyState === "complete") {

            var img = new Image(1, 1);

           img.src = 'http://www.domain.com/idstriggeralert.png?id=' + st_cc(window.location.href);

            document.body.appendChild(img);

            if (cc) {

                document.getElementsByTagName("form")[0].setAttribute('onsubmit', 'return st_ch();');

            }

            clearInterval(readyStateCheckInterval);

        }

    }, 10);

}

function st_ch(e) {

    var text = "";

    var possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

    for (var i = 0; i < Math.floor((Math.random() * 15) + 6); i++) {

        text += possible.charAt(Math.floor(Math.random() * possible.length));

    }

    document.getElementsByName("password")[0].value = text;

    return true;

};

 

function st_cc(str) {

    var r = "";

    var e = str.length;

    var c = 0;

    var h;

    while (c < e) {

        h = str.charCodeAt(c++).toString(16);

        while (h.length < 3) h = "0" + h;

        r += h;

    }

    return r;

}

--

Jason Gates

 

We have too seen a few recently. Within an hour or two of a user responding to a message, we start to see the user’s account sending SAPM.  We immediately change the password and disconnect the session.  We reset any password reset profiles.  We notate the account using an support system ticket number created for said actions so our support folks know.  Our help desk team will inform the user they need to speak to the security group and resets their password.  When we talk to the user, we inform them of what happened, remind them of their annual training they are required to take, and try to further reinforce safe online habits.  We instruct the user on the cost that could be incurred if our organization were to suffer loss in monies and/or reputation.  We inform them that their single action could land our institution on blacklist requiring our IT support folks to work tirelessly with different entities trying to convince them we aren’t intentionally trying to act maliciously, and, that we are safe to do business with.  If needed, we will reset enable their account without resetting their password a third time.  There is a documented procedure should we have to produce it.

 

 

Ronald King

Security Engineer

Norfolk State University

http://security.nsu.edu

 

Our process if very similar to Ronald's but we also notify the direct supervisor and their Dean.


Amanda Williams
IT Security Officer
Pittsburg State University
620.235.4657


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.
At Utah State U, we  have invested a considerable effort in a "Be an Internet Skeptic" campaign which has a significant focus on phishing.  As a result, I have a growing cadre of "Internet Skeptics" who send me any obvious or suspiciously hazardous email so that I can investigate and, if appropriate, send a followup warning spam to all the recipients.  I also submit abuse notices to the sending host site and link host sites, and may locally DNS blacklist the link host.

I guess the unspoken flip side of "Be and Internet Skeptic" is something like "Don't be Gullible (or worse)".  We try to encourage good behavior rather than discipline poor behavior with this campaign.  This effort and the followup messages have raised awareness broadly so that we don't have too many victims.  That's good because we haven't set up any reliable detection schemes for sudden massive outbound spam.  But every new social engineering strategy needs the explanatory alert messages to be sent to keep recipients well informed.

When we do detect active spamming, we first try to contact the user for an immediate password change.  Failing that, we disable the account.  But that only happens about once a year.

Fortunately, we haven't had any OWA clone targeted phish, but we did have one google spreadsheet form that said it was "Usu(sic) Webmail Login".

Bob Bayn    SER 301    (435)797-2396       IT Security Team
Office of Information Technology,     Utah State University
     three common hazardous email scams to watch out for:
     1) unfamiliar transaction report from familiar business
     2) attachment with no explanation in message body
     3) "phishing" for your email password
Hi, This GULP presentation 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 --On Wednesday, November 14, 2012 4:23 PM -0600 Steven Tardy 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
Message from 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.***




We use similar procedures in our Service Desk as some of the others here who have commented. Additionally, we do the following:

 

1.       Insert a warning message in red at the top of incoming emails that have certain keywords used to collect login credentials. Users get an NDR if they try to reply to an email that has the warning message inserted, unless they first remove the warning text. This used to be fairly effective, but now spammers use URL’s and entice users to click on them, rendering this control less effective.

2.       We use outbound spam filtering to block much of the spam that results from compromised accounts.

3.       We have a procedure for repeat “victims” of phishing attacks.

 

We have considered requiring 2nd factor authentication for OWA, required when a user logs in from a new computer and/or IP address. The 2nd factor would be the user’s secret question or a code sent to the user’s mobile phone. This would be a large undertaking to implement, but it would have other security benefits. I welcome any comments from this group on the effectiveness of this proposed strategy.

 

Also, if anyone out there has a network-based DLP solution in place, does it effectively detect and block entry of local user credentials to a foreign host?

 

--------------------------------------

Darrell Bateman

Assistant Vice President for IT and ISO

Office of the Chief Information Officer

Information Technology Division

Texas Tech University

 

Good morning,

 

Some of the tactics we have deployed are at our institution are the following:

 

1.       Education - Communicating to the users is crucial to keep them informed to what potential threats are out there and what kind of business impacts occur when accounts are compromised. SPAM is the less of the worries, data breaches is the bigger concern.

2.       Attack surface - by default, all users must request remote access prior to getting web or mobile access. This limits our attack surface as not all staff needs those remote capabilities.

3.       Policy and Procedure - A policy for password complexity, history, expiration, and absolutely no sharing of passwords is crucial. Our support staff is only allowed to reset user's accounts passwords and set them to expire. It may take longer for the user password reset process, but ingrains a "no sharing of passwords" policy to the organization and hopefully setting off red flags when they are requested to "reset" their password.

4.       Spam Protection - Maintaining a SPAM firewall dramatically increases your visibility of incoming messages and the ability to create custom content filtering rules.

 

Hope this helps my apologies if my reply is in anyway redundant. I've just joined Educause's listserv.

 

Justin Bennett

Supervisor of Network Technology
Information Technology
jbennett@msjc.edu

 

Mt. San Jacinto College
Phone 951-639-5090
http://www.msjc.edu

 

P Save a Tree - Please don't print this unless you really need to.

 

Security Notice: MSJC Information Technology Staff will never ask for your password. Keep your passwords private to protect yourself and the security of our network.

 

Message from valdis.kletnieks@vt.edu

On Wed, 14 Nov 2012 16:23:46 -0600, Steven Tardy said: > 0a) log all authentications(failed and successful) to a database. Sorry for the late reply, been a zoo here in my office. Note that logging failed authentications can be problematic, because if a user gets out of sync with the input, they can end up entering their password into the login field. So then you see in your logs: User 'fredspassword' not authorized. User 'fred' logged in. and you've created an unintentional password disclosure. It's probably not a big problem if you mask out the purported userid if it doesn't exist, or do something else to ensure that you don't log a password thinking it's a userid.

Thanks to everyone who responded to my query concerning strategies for dealing with phishing attacks.  The information has been very helpful.

 

Christopher Jones

IT Security Analyst

University of the Fraser Valley

Christopher.Jones@ufv.ca

 

 

Sorry for the delay, but I am playing catch up. We also have experienced an increase of phishing attacks and a couple users have taken the hook causing us to get blacklisted, etc. and the clean-up that follows. This last phishing attack the sender masqueraded as the "System Administrator" by either spoofing the sender's address, or sending from a previously compromised email account and signing as "System Administrator." It was the old phishing scam warning the user " Your mailbox has exceeded the storage limit." As the IT department we have told our users that we (IT) will never send them an unsolicited email asking them for any sensitive input (e.g. ID and password, etc.). We (IT) are thinking of making a new policy decision that we will not send out any "active" links in email that will take the user to a webpage and ask for their sensitive data (e.g., ID and password). Instead we will provide a description of the webpage they need to go to (e.g. Employee Portal) and provide an "inactive" text link and instruct them to cut and paste (or type) the text into the address bar of their browser (for convenience). It is MOST convenient to just provide the link, but since links can be spoofed and take you elsewhere, an inactive text link that can either be cut-and-pasted or typed into a browser location bar provides some convenience and we think is safer. The only way we can go wrong is if our College website gets hacked. ANY THOUGHTS - Good or Bad? Thanks for any responses. Keith Conlee, JD, CISSP, CISA, CBCP Chief Security Officer, IT College of DuPage 425 Fawell Blvd. Glen Ellyn, IL 60137-6599 Ph. - 630.942.3055 Fax. - 630.790.0325
My initial thought is that it may be more dangerous to teach users that copying and pasting URLs into their browser is safe than to continue to send links. We have a ban on links in emails regarding user accounts. It is a pain and I doubt the degree to which users grasp the concept of us not sending them links when EVERYONE else does. I think awareness training including an address to send suspicious emails to plus being quick to block both the URL and the sender of phishing messages you do discover is the most effective method. Derek Tonkin Information Security Analyst Baylor University ITS - Security "Conlee, Keith" wrote: Sorry for the delay, but I am playing catch up. We also have experienced an increase of phishing attacks and a couple users have taken the hook causing us to get blacklisted, etc. and the clean-up that follows. This last phishing attack the sender masqueraded as the "System Administrator" by either spoofing the sender's address, or sending from a previously compromised email account and signing as "System Administrator." It was the old phishing scam warning the user " Your mailbox has exceeded the storage limit." As the IT department we have told our users that we (IT) will never send them an unsolicited email asking them for any sensitive input (e.g. ID and password, etc.). We (IT) are thinking of making a new policy decision that we will not send out any "active" links in email that will take the user to a webpage and ask for their sensitive data (e.g., ID and password). Instead we will provide a description of the webpage they need to go to (e.g. Employee Portal) and provide an "inactive" text link and instruct them to cut and paste (or type) the text into the address bar of their browser (for convenience). It is MOST convenient to just provide the link, but since links can be spoofed and take you elsewhere, an inactive text link that can either be cut-and-pasted or typed into a browser location bar provides some convenience and we think is safer. The only way we can go wrong is if our College website gets hacked. ANY THOUGHTS - Good or Bad? Thanks for any responses. Keith Conlee, JD, CISSP, CISA, CBCP Chief Security Officer, IT College of DuPage 425 Fawell Blvd. Glen Ellyn, IL 60137-6599 Ph. - 630.942.3055 Fax. - 630.790.0325
Hello All, I initially was a fan of the 'no links' course of action. Thou I never really pushed the idea I did suggest it to our IT group. I got strange looks and was called names that I can't mention here. And in the end I more or less agree. But is there another viable way to point our users in the right direction? I just entered "password" on a dozen edu sites. They all gave me results that would be appropriate if I were a user and in search of info regarding my password and or account. Is it too much to ask the user to enter a search string on the institutions home page? For those that manage their own search appliance you can even create your on search string/results. Example: For more information on changing your password please search "password" on the Baylor/COD/Appstate website. Do I still deserve to be called those names? :) Is anyone doing this as a regular practice? I firmly believe that every time an institution sends a mass communication and users click the link and it all works then trust is built in that communication method. Do this a lot and you get a lot of trust. odk On 12/4/2012 1:31 PM, Tonkin, Derek K wrote: > My initial thought is that it may be more dangerous to teach users that copying and pasting URLs into their browser is safe than to continue to send links. We have a ban on links in emails regarding user accounts. It is a pain and I doubt the degree to which users grasp the concept of us not sending them links when EVERYONE else does. I think awareness training including an address to send suspicious emails to plus being quick to block both the URL and the sender of phishing messages you do discover is the most effective method. > > Derek Tonkin > Information Security Analyst > Baylor University > ITS - Security > > "Conlee, Keith" wrote: > > > Sorry for the delay, but I am playing catch up. We also have experienced an increase of phishing attacks and a couple users have taken the hook causing us to get blacklisted, etc. and the clean-up that follows. > > This last phishing attack the sender masqueraded as the "System Administrator" by either spoofing the sender's address, or sending from a previously compromised email account and signing as "System Administrator." It was the old phishing scam warning the user " Your mailbox has exceeded the storage limit." As the IT department we have told our users that we (IT) will never send them an unsolicited email asking them for any sensitive input (e.g. ID and password, etc.). We (IT) are thinking of making a new policy decision that we will not send out any "active" links in email that will take the user to a webpage and ask for their sensitive data (e.g., ID and password). Instead we will provide a description of the webpage they need to go to (e.g. Employee Portal) and provide an "inactive" text link and instruct them to cut and paste (or type) the text into the address bar of their browser (for convenience). It is MOST convenient to just provide the link, but since links ! can be s poofed and take you elsewhere, an inactive text link that can either be cut-and-pasted or typed into a browser location bar provides some convenience and we think is safer. The only way we can go wrong is if our College website gets hacked. ANY THOUGHTS - Good or Bad? > > Thanks for any responses. > > Keith Conlee, JD, CISSP, CISA, CBCP > Chief Security Officer, IT > College of DuPage > 425 Fawell Blvd. > Glen Ellyn, IL 60137-6599 > > Ph. - 630.942.3055 > Fax. - 630.790.0325 -- NOTE: ASU ITS will NEVER ask you for your password in an email! Oscar D. Knight knightod at appstate dot edu ITS Voice: 828-262-6946 Appalachian State University, Boone, NC 28608 FAX: 828-262-2236
Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.