Skip navigation

Phishing: Recognizing the Bait

When I was a kid, I had the good fortune of frequently fishing with my dad in the bayous of southern Louisiana, one of the world's most fertile littoral ecosystems. We didn't always catch anything, but I enjoyed the attempt. However, for the last year or so, I've been more concerned with phishing than with fishing. Because you're probably reading this column as an email message, the likelihood that you've gotten phishing email yourself in the last month or two is excellent. The Anti-Phishing Working Group (http://www.apwg.org) issued a report in May 2006 that claims an increase of more than 250 percent in the number of new phishing sites in the last 12 months—a statistic that I find easy to believe.

On the face of it, phishing might seem like an end-user problem. As an Exchange administrator, you might not be concerned about your users accidentally disclosing their own personal eBay or PayPal passwords or the credentials for their bank accounts. However, there are two good reasons to worry. The first is mostly humanitarian: What if some less technologically astute acquaintance or family member falls for a phishing scam? Not every email user has the same degree of technical savvy (and skepticism) that you do.

The second reason to worry is more directly job related: An increasing number of phishers are targeting individual companies with messages that closely mimic their internal systems for employee benefits and the like. Last year the Wall Street Journal reported that, out of a pool of 500 West Point cadets, 80 percent were tricked into revealing personal information after a test spear-phishing attack (http://online.wsj.com/public/article/SB112424042313615131-z_8jLB2WkfcVtgdAWf6LRh733sg_20060817.html?mod=blogs). Phishers are getting smarter, better organized, and more sophisticated all the time.

Unfortunately, the tools we administrators have to fight phishing haven't improved in proportion to phishers' skills. When you think about it, phishing email is really just a special class of spam, and to the extent that these messages are intercepted now, it's usually because of effective spam filtering. Of course, some filters are more effective than others; if your server-based spam filtering is poor, you shouldn't expect to get much relief from the phishing onslaught.

One way to fight phishing, of course, is to block URLs associated with phishing fraud at the browser. This is the approach adopted by companies such as Microsoft, EarthLink, Google, and Netcraft. These companies all make browser add-ons (or, in Microsoft's case, a browser—Internet Explorer 7.0) that look at the URLs you visit and, using either a centralized lookup service or heuristics, attempt to determine whether the page is fraudulent. These add-ons are helpful, but they don't address the root cause of the problem: the phishing email that arrives in our inboxes in the first place. (Another problem with add-ons is that some of them work better than others. I'll have more to say on this subject in a future column.)

Perhaps a better way to block phishing email is to use the email analysis and screening tools we already have and adapt them to catch phishing messages. So far, only a few vendors I know of are taking this approach. For example, Microsoft Exchange Server 2007 and Exchange Server 2003 SP2 both set a property called the phishing confidence level (PCL) on incoming mail. The PCL, which is determined by rules in the Microsoft Exchange Intelligent Message Filter (IMF), serves a function similar to the familiar spam confidence level (SCL): It helps the mailbox server and the client determine whether the inbound message is wanted. In the case of the PCL, Microsoft Office Outlook 2007 and Outlook 2003 SP2 can use the server-generated PCL, along with the SCL, to flag an incoming message as a potential phishing attack to warn the user. To get the benefit of this filtering, you should upgrade both Exchange 2003 and Outlook 2003 to SP2, then teach your users about the InfoBar on the email message and how to use the information it provides.

You might also consider filtering incoming phishing email by doing some simple subject filtering. Look at the APWG report I cited earlier and you'll see a list of the top domains attacked by phishers; in some cases, you might be able to block messages claiming to be from those domains without ill effect.

Long-term, widespread deployment of Sender ID (which I've written about before; see the list of articles below) will help reduce the incidence of phishing by giving us better, more automated tools to reject messages that claim to be from one domain but are really from another. Until then, we'll have to depend on the tools at hand and hope that the tool vendors can keep up with the phishers.

Access these related articles at http://www.windowsitpro.com by entering the InstantDoc ID number in the InstantDoc ID box at the top of the Web page:
"Sender ID: Back From the Grave," October 28, 2004, InstantDoc ID 44353
"Sender ID and FUD," July 21, 2005, InstantDoc ID 47140
"The Sender ID Standard," Exchange & Outlook Administrator, November 2004, InstantDoc ID 43917 (This article is normally available only to subscribers of the newsletter; however, it will be available to nonsubscribers until September 7, 2006.)

TAGS: Security
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish