“How dare you fall for this exceptionally well crafted phishing template we explicitly whitelisted in the mail filters so it appeared to be legitimate?”
Phishing simulations are extremely popular in the business world.
Organizations these days are so worried about ransomware that they’re diving in head first, sending their employees fake gift card offers and asking them for their passwords, then sending the ones who fail the tests to training over and over again.
And I can’t totally blame them.
Ransomware has singlehandedly bankrupted a number of organizations and the gangs perpetuating the breaches are only getting better at their jobs.
The demand for some kind of solution is huge.
Kevin Mitnick started a whole business around delivering phishing simulations and subsequent training, though they’ve been criticized recently for requiring explicit approval through spam filters and other detection mechanisms.
Smaller companies are making plenty of money on education platforms with recycled content about how to spot a phishing email, how to report a phishing email, but they’re not doing any measurement.
But is it working? Is it useful?
It’s hard to say.
I’ve seen a lot of phishing attempts in my 10 years in this industry. From detecting and stopping campaigns in SOC/sysadmin roles to running many myself (internally or for clients as a pentester and red teamer), nothing really surprises me anymore.
Except, of course, the myriad of misconceptions around phishing and the growing list of blind spots organizations have about what happens next.
Many companies do next to nothing to patch vulnerabilities, secure endpoints, or segment networks - all things that make it more difficult for a successful phish to matter.
They’re one good phish (or Exchange zero-day) away from the very thing they’re spending so much money to prevent.
Why?
Because they’re placing the responsibility for preventing breaches on the wrong people: the users who can’t do anything about it.
To provide an alternative perspective, and maybe get us on the right track, here’s what I’ve learned about phishing attacks and how to approach them differently:
No one is immune.
If you think you’re not the kind of person to fall for a phishing link, you’re dead wrong.
I’ve seen even the most security-minded individuals fall for a link that was well placed and convincing.
It’s not all their fault, either. There is a direct correlation between the time and effort put into the campaign and the success rate, and we work pretty hard.
Twenty minutes of research on what someone’s interests are will give me more than enough context to include in a personalized phishing attempt to anger, worry, or offend them into falling for my red team’s tricks.
Training only works so well.
A phish that works on someone is likely to just be better than the fodder from your curriculum. Keep training on gift card offers and people will fall for them less, but they’ll still fall for me impersonating the IT helpdesk or HR.
Did you train them not to click an “Unsubscribe” link in an annoying newsletter?
Of course you didn’t because that would be silly. And I’ll keep putting my credential-stealing links there.
Click rate only matters in context.
What actually matters is what happens after.
If everyone clicks but no one enters credentials, maybe they recognized the page as malicious. This should be celebrated, not punished. Look at why the email landed in people’s inboxes before you blame them.
Sure, older software is more prone to web-based payload delivery.
Browser 0-days exist.
But those are unique threat model elements that should be uniquely considered, not universally used as flimsy justification for a click-based metric.
Neither are usually a user’s fault anyway.
MFA is just another flag to capture.
Speaking of contextualizing clicks, if someone is willing to enter their credentials, they’re probably going to enter their MFA code.
I can steal all of it if I want to. Either buy everyone hardware tokens or stop leaning on MFA as a cure-all.
So are phishing tests worth it?
Should you let a vendor through your protections just to gather metrics?
Does the training work?
I don’t have data to sway you either way, just my experiences on the blue side and the red side.
A great piece of research was recently published by some smart people at the Department of Computer Science at ETH Zurich, Switzerland that does provide data, and you can find it right here (opens in new tab).
Here are some things that I know will help:
Reward people for reporting malicious emails.
In a previous job, I wrote a monthly “Spam Hall of Shame” newsletter that lampooned user-submitted phishing attempts while breaking them down and teaching people about their various elements.
Want to know what happened?
Click rates plummeted.
Reports skyrocketed.
People had water cooler conversations about how they recognized this or that phish.
Suddenly it was much less of a problem and our risk was lowered by creating cultural momentum.
Keep stuff out of inboxes.
Seriously, just reduce the number of bypass events as much as you can.
This is your first layer of defense. If you want to test it, and you should, champion someone to build the skill set to do so. Or hire for it.
But test it.
Test for post-delivery impact.
What can actually happen after just a link click? Nothing?
What about credential theft, MFA or otherwise? What about host compromise?
This is the stuff that actually matters in a real attack, which is the situation you’re trying to avoid, is it not? Penalizing a user for falling for a phishing attempt while not protecting them on either side of the attack is deflection, not improvement.
Castles have walls to protect people. If it was possible to stop an invading army by publicly shaming citizens, no one would need walls, but that’s not how it works. Educate people to understand the “why” behind more security-oriented thinking.
Turn your users into heroes who have a part to play in the organization’s security, not liabilities that weaken it by just existing.
Final Thoughts
SpecterOps, a firm I highly respect, recently posted this article on how they’re changing the way they do phishing engagements (opens in new tab) from here on out.
It is, in a few words, highly valuable perspective.
Especially because we’ve been dealing with this same quandary internally: we know we can phish well enough to get clicks, but is it actually helping?
Sometimes it seems like it, but most of the time we’re just telling everyone what they already know, which is that all humans are suggestible. Everyone can fall for social engineering that has enough time and effort behind it.
As cool as it is to spend a ton of time on initial access attempts for that “I’m in” moment, at some point it might just not be in the cards, so as pentesters and red teams, we have to provide value somehow.
The “automatically move to assumed breach after X amount of time/effort” model is superior in this regard. We can’t waste time either proving the inevitable and then calling it a day like a breach just isn’t possible.
They’ve communicated this better than anyone else, including me, and I think they deserve the last word based on how well they articulated the current state of phishing exercises.
If you can take one thing away from it, it should be this:
People are not entry points you can close, patch, or update. They are a component of the greater security boundary around which you should be placing mitigations like better email security, payload detection, and more.
In other words, measure what you can do about a successful phish before and after a human being acts like a human being.
Penalizing a user for falling for a phishing attack while not protecting them on either side of it is blame deflection, not security improvement.