Can users' phish emails be a security admin's catch of the day?

Published: 2012-11-27
Last Updated: 2012-11-27 13:12:39 UTC
by Chris Mohan (Version: 1)
2 comment(s)

Blocking phishing emails is part and parcel of now commonplace technology controls, supplied by a wide range of vendors and, depending on your viewpoint (or how many angry user phone calls received daily), they do a great, resonable or bad job of blocking this type of unsolicited email. Despite the technologies deployed, ultimately the human factor is at play [1]. If someone in your company is going to click a link, open an attachment or click on a link to download a password protected file, then go to another site to get the password to open the file and have to install an old version of Java to see the Christmas Chickens dancing Gangnan style, then our reliance on user awareness training and constant reminders is the final safety net. 


The ones that get through the technical controls are the ones that cause pain, either from afore mentioned angry users or, more seriously, possibly having to spin up some form of incident response. The question should be can these phishing email that evade our front line defenses be of more use other than to be forwarded to the filtering vendor with a pithy comment along the lines “another one gets through – again”?

Something to think on before you tell the user to “just delete that, it ‘s a stupidly obvious phishing email” have a read of some of the Anti Phishing Workgroup’s reports [2]. Phishing attacks clearly works and is still on the increase, so ignoring this problem is doing a disservice to your company and the staff.

Here is one way to get a bit more insight to the impact those nasty phishing emails to your network, then appy some defense and awareness in one fell swoop. I’m going to focus on the most common type of phishing email, one that contains an obfuscated URL leading to a malicious site.

Once you have a phishing email, a quick look at the source html will clearly show the link to https: // is actually pointing to http: // muhaha-I’ This tells us we have a real phish on our hands to deal with.

With that single URL, it enables you to search firewall, proxy and DNS logs[3] to see if anyone on your network has followed that link. And with that you now know the current impact of that one phish email to your organization. 

Add it to the firewall/proxy block and alert rule, or better still, to a redirect rule that sends the next hapless phishing victim to a user awareness internal page educating them on what a phishing email is. This provides a list of people to receive the next batch of user awareness training and again shows the scale of how effective this phish was after the block was added.

“Ah-ha!” I hear you cry “How do I get the phishing email in the first place, if my users don’t know they been phished in the first place!”

Well, that’s a fair point, but you can use the natural, local resources of every IT/Security admin: The helpdesk/support team, well known unused email addresses directed to one mailbox ( e.g. administrator@, webmaster@, abuse@ etc), the entire user population and “Bob”, the guy that seems to always get spam and phishing emails first. Either you already know who the “Bob” in your company is or the support staff most definitely will.

Have them forward known or suspected phishing emails to your special mailbox to investigate.  Those that are real phishing email can be added to URL defenses and can be also added into your newly created Phishing scam blog/wiki/intranet site with recognition being given to the person that reported it. This provides a great teaching and reference material for not only staff but they can use it to warn their friends and families as phishing targets anyone with an email address.

To make some security graphics for those all important weekly/months reports, create them from  the numbers of URLs the added phishing blocks, number of staff that clicked on the before and after the blocks were place and the number of phishing email reported by staff. That should keep management happy and provide historical charting of the amount of reported phishing events to help frame the overall security awareness health of the staff.

You’ve now gone from a one lone skirmisher to an army against the menace of phishing emails. Getting the staff working for you to protect the company is one step closer to improving the over all security posture (and possibly being able to go home on time).  

As ever, feel free to pitch in any thoughts or comments.


[1] Top tips to help the human element


 [3] Some great tips on fun security stuff to do with DNS

Chris Mohan --- Internet Storm Center Handler on Duty

2 comment(s)


Couldn't agree more. I recently setup DNS filters with RPZ (response policy zones) in bind at work. I've got a make file that fetches an updated list of known hostile domains and known compromised IPs, combines that with my own blacklist/whitelist rules and generates the RPZ zone data. I'm then logging bind rewriting queries using RPZ and using net-snmp and logmatch rules in snmpd.conf and cacti/nagios to graph how many RPZ hits per minute we get.

Yeah, it means sometimes I'm adding a rule to prevent DNS from resolving a URL in a phish after some users have seen that email, but often before all of 'em have. cacti/net-snmp lets me quantify for management the usefulness of my own RPZ zone and the spamhaus RPZ zone.

We fairly routinely see spikes RPZ rewrites (preventing something bad from resolving) to around a dozen per minute in both sets of RPZs.
Web administrators should also make sure that any secondary accounts used online do not have administrator access.

I have seen dodgy links on physics forums and it looked like the person was deliberately acting as a crank and trying to incite the 'forum mafia' to click on the link. Talk about a reverse honey pot.

Diary Archives