Institutions of higher education seem to attract quite a bit of attention in the way of email phishing attacks.  I’m  fairly sure other types of institutions get with with phishing attacks as well, but since I work for a university, that’s the pool I happen to play in and the one I know best.

Everyone knows how they work:  a user gets an email from a phisher about a supposed “webmail upgrade” / “over-quota event” / “we’re cleaning old mailboxes” / whatever, and if the user wants to continue using the email services provided by <insert most-likely-misspelled institution name here>, then the user must respond back with their username and password.  If the user responds, the phisher now has another email account which they can use to send SPAM, more phishing attacks, etc.  More importantly, now the phisher most likely has a login to the institution’s VPN, the user’s account information (if there is a central “accounts portal”), and any access to confidential information that the user may have access to (with Exchange, that would of course include the user’s calendar and contacts).  This is what’s known in the business as a “problem”.

You wouldn’t believe how many people fall for these attacks, or are unsure enough that they send them to abuse@ and ask if they really should provide their account information.  Fortunately there are a few things that can help counteract these types of emails.

First things first (and this is basic email administration 101):  you should be running some sort of antivirus and antispam product(s) on your edge SMTP devices.  If you’re not, then you probably need to step back from administering mail servers and let someone else handle it.  There are many products out there for antivirus / antispam; since we’re an Exchange shop now and we get the product essentially for free with one of our campus agreements, we use Forefront Protection 2010 for Exchange Server (FPE).  I particularly like this product, as it is maintainable via PowerShell, which I pretty much live in at this point to manage Exchange 2007, so it’s nice to be able to manage FPE this way as well.  The new Forefront DNSBL included with FPE is also quite good.

Unfortunately, phishing attacks seem to evolve faster than antispam engines can update and counteract them.  Anyone who has managed a mail server for any length of time knows that there is no “antispam silver bullet”.  Everyone has a configuration that works well for them, yet I can almost guarantee that no two configurations of e.g. SpamAssassin look alike, and not one of them will provide 100% coverage.  That’s just the way it is; you can only hope to maximize legitimate rejections and minimize false positives and negatives.

Outside of that, there are other projects that aim to minimize the effect of phishing emails in some capacity.  Some will try to reject incoming attacks during the SMTP conversation; others are marketed as only trying to identify potential responses to phishing messages.  The anti-phishing-email-reply project is one that aims to "…maintain a list of accounts that are being used (or have been used) in the reply-to address of phishing campaigns" and is recommended to be used to "…actively block outgoing smtp submissions destined for these accounts".

I have been using the aper list for about nine months now (as of this post).  In the beginning I was only prepending the text “[POSSIBLE PHISHING ATTEMPT]” to a message’s Subject header if it came from an address on the aper list, but would still deliver the message to the user’s mailbox.  Even then we had a few users reply to the messages, and many other users would just forward the message to abuse@ in case we hadn’t seen it (thanks, but did you even read the subject line?).  At some point I got tired of having to wade through all of the forwarded “[POSSIBLE PHISHING ATTEMPT]” emails (since users didn’t seem to read the subject line anyway) and started redirecting the messages to a quarantine mailbox instead of delivering it to the user.  This worked out well enough–at least, to date no one has complained about missing emails that can be directly attributed to this action.  (Note that this is not true to the original intended purpose of the aper list, which is only to block outgoing replies to phishing messages.  Still, I believe many institutions do exactly the same thing.)

However, with the scenario above my edge transports still had to expend  resources to process the potential phishing messages (bandwidth, CPU and memory to run antivirus/antispam, IP checks, etc.) and send it on to one of the hub transports, which then has to process every single message against a couple of transport rules (one to detect incoming phishing messages, and one to detect possible phishing replies).  The phishing attacks kept coming, and basically I felt that we were having to do all the work and the remote phisher (or zombie computer, or hacked email account, etc.) wasn’t being penalized at all.  I decided that needed to stop.

My current solution is a custom transport agent (written in C#) that integrates into the transport pipeline on each of our edge transport servers.  The agent will (re)read a local copy of the phishing_reply_addresses file periodically and build an in-memory array of addresses to block.  The agent has hooks into various parts of the SMTP conversation.  It will first tarpit the connection, then outright reject it (with a “550 5.7.1 Address is listed on the anti-phishing-email-reply” message) if any one of the following contains an address on the aper list:

  • MAIL
  • RCPT
  • From header
  • Reply-To header

This will catch both inbound messages and outbound replies, and the edge transports don’t have to spend very much time at all on processing the message.  It also logs its actions using the amazingly flexible log4net logging framework, so the email administrator (that’s me) can decide exactly which events they want to log, and how they want to see them (event log, logfile, email…).

In conclusion, there are many methods an email administrator can use to combat email phishing attempts.  None of them are foolproof, and in fact most are reactive instead of proactive.  This is true of the anti-phishing-email-reply list as well:  it relies on mail administrators to maintain and update the list, and is not effective against “zero-day” phishing exploits.  However, it can still be an invaluable tool.

(I will be following this post up with another couple of posts about both methods I have used to integrate the aper list with Exchange.  I find that my solutions are a little more elegant than the example scripts in the aper repository.  I will update this post with links to the other posts once they are finished.)