You wake up, alarm blaring. Your AI assistant notifies you there’s been another netrunner attack on the company. You chug down your synthesized meal replacement drink and hurriedly rush out the door, “hopefully the maglev isn’t delayed again” you think to yourself. You scan yourself into the office with facial recognition and check your metrics for security incidents, you realize you’ve gone below your allowed security KPIs this month and hope they don’t dock your pay again.

If this sounds slightly dystopian to you let me give you another situation that may sound equally unrealistic in your environment.

Your company is running a full Zero Trust set up with all the bells and whistles. You’ve got WebAuthN and Security keys on all of the services. You’ve got proxies that limit access to trusted machines and maybe you’ve even got some more advanced techniques like binary authorization (in block mode) or passwordless. Even crazier is that you have no exceptions to any of the above rules, no contractors, no downgrades, nothing!

The question now is, what do phishing attacks look like? Do you still need phishing awareness exercises and how do you protect against them?

Phishing Today

Some of the most rampant attacks we see today are password related. Attacks like credential stuffing where attackers try re-used passwords from public breach lists against multiple services. On the phishing side we have the classic, an email or message with a call to action, “just click this link and enter your creds”. Except in this case the website isn’t the one you know and love, but an attacker faking a similar-looking page and URL trying to get your juicy details.

The more advanced versions of this we’re starting to see become more common are using things like 2FA proxying; asking the user to enter in their OTP codes so the attacker can steal those too. More advanced versions of this are things like Push MFA fatigue or even worse, socially engineering a user into accepting a push request like in the recent Uber hack.

The one thing that you might notice is that all of these attacks can be prevented with technical controls. If you have WebAuthN on all your systems and security keys deployed to all of your staff then you don’t need to worry about this right?

Well… of course, attacks come in many forms and we can’t protect against all of them with security keys.

Next-Gen Phishing

Password-based attacks are a thing of the past in a passwordless world, but credential phishing is far from the only type. Like everything in security we often see an arms race in tactics. Attackers will use the easiest methods available to get access and credential-based attacks today are wildly successful, they don’t need to improve so why bother? Here are a few attack types that still work in our environment and things that we would still need to look out for.

BEC

Business email compromise aka messaging someone and convincing them to do something. Unfortunately, as much as we like to implement technical fixes, we can’t prevent this one with any amount of tech. I’m sure many security folks reading this have had someone in their organization go out and buy a bunch of gift cards because the “CEO” (aka A British teenager with a pseudonym like CyberSenpai55) asked them to. This is incredibly common and attackers are changing up their tactics, using WhatsApp and Signal to message employees. You often see new hires get targeted by this on LinkedIn so we should try and move awareness even into the pre-hire stage, letting prospective employees know how and by what methods we’ll contact them.

OAuth

OAuth phishing is on the rise and rightly so. There are a ton of potential vectors for phishers, from creating an application that looks like a more popular one or even building a legitimate app and then building badness into it. In some worst-case scenarios, these OAuth grants can give attackers access to your email that could be used to go on to do other things such as reset passwords or MFA tokens in some cases.

Malware

Instead of asking for credentials, we ask the user to execute an application or a script. If we have sufficient detections and techniques (like binary authorization) we can significantly reduce the likelihood of this, but we can’t eliminate it. Most typical examples have the user installing a dmg or exe but this isn’t the only way of getting malware to run.

If you work in any kind of developer-heavy environment you’re likely going to allow developers to run scripts locally unless you’ve managed to entirely move to remote development. Attackers can live off the land with phishing techniques by simply asking users to run a script sent in an email, downloading and running .sh, .py or other types of scripts.

New Hire Phishing

Most Zero Trust systems’ weak point is within the first few weeks. The reason here is that you need the new employee to tell you where to send the laptop and you need to securely transfer initial login details to them. The downside here is that there’s a multitude of risks since the new hire is not within your trust boundary yet. There are already a lot of publicized attacks in the onboarding process, you’ve probably heard cases of fake interviewers, people starting to use deep fakes and even attackers targeting new hires. I wouldn’t be surprised if we saw more attacks in this area and see attackers trying to re-route laptops or getting new hires to install malware on their machine “as a part of the onboarding process”.

Ditch The Phishing Exercises

OK that might be a bit dramatic, you should absolutely keep doing phishing awareness, but you should consider overhauling your program significantly. Too many times I see places with significant WebAuthN and Security Key usage still doing the typical credential stuffing training. The ROI on doing this is extremely low as you’re essentially training employees to look for the wrong signals and at worst wasting their time.

What I propose is that people change their phishing programs to adapt to their specific environments, the ones we are starting to see become more common today.

Better Phishing Awareness

Here are a couple of examples I’ve done in the past. You’ll find these take a bit longer to prepare but you can usually get them out in a day or so, maybe a few days if you are targeting a very high-quality phish. However you will need some very light development skills to get them off the ground. Below I’ve included a few high level walkthroughs of what I think are some better phishes for Zero Trust Environments.

Script Phishing

This is a relatively lightweight one you can get done, you’ll need a few things before you start:

  1. A server or lambda (Linode, EC2, Lambda etc.)
  2. A hosted script (shell, python, ruby, your choice, make it whatever you use in your environment, you can throw it into a public S3 bucket)
  3. A public delivery method (Email, Helpdesk, LinkedIn).
  4. Optional: A domain name relevant to your phish, if you work at Jamf.com maybe you use Jamfff.com or jameff.com. You’ll only need this if your delivery method is email and you want a similarly named domain.

Walkthrough:

  1. Spin up your server, ideally not on your corporate cloud instance. You’ll want a separate account for this.
  2. Write a quick client script that simply grabs some information from the machine such as the machine name and posts it to your server.
  3. On the server, you may want to implement some sort server-side script that accepts the input and displays tracking so you can see metrics. An easier but slightly worse UI is to just sort through logs.
  4. Work out a delivery mechanism for your script. In a previous example, we pretended to be IT asking users to fix their Zero Trust setup. In the email we included a command which downloaded and ran the shell script from a public bucket and we asked them to copy the command into the terminal.
  5. Once you’ve got everything ready and you’ve commenced the phish you can track results until such a time where you remove the script and take down the server. Always remember to publish the results and I would strongly recommend doing training about the type of phish you are doing before doing it. Nobody likes gotchas after all.
  6. Admittedly you’ll have a few people who download the script and don’t execute it, maybe even a few who start looking at the code seeing that it’s harmless in this case which may skew your numbers somewhat.

OAuth Phish

These can sometimes require a bit more dev work than the previous example, where you can usually get by with a few lines of bash. In this example we want to gain access to someone’s account by having them allow an OAuth app we created get access to some sort of sensitive scopes like email access or chat history.

  1. Create an OAuth app template that makes sense in your environment. On the easier end, this could be a Slack app, on the more difficult end, it could be an app that accesses Gmail or Outlook. The main thing to consider here is that OAuth can sometimes require app approvals by an admin to get access to certain scopes, so be careful in what you ask for.
  2. Pick a delivery method the same as before. Email, Helpdesk, LinkedIn etc. You need a way to socially engineer them to install the application that makes sense.
  3. There are a few ways you can verify the grant rates. You could build it into your application but the easiest way is to get your IT admin included on the phish. Most tools will tell you what applications are installed and how many people have installed it. Unfortunately, this isn’t the case with everything though so verify before you send the payload.

Summary

Hopefully, this has given you an overview of some of the threats that remain after we’ve moved to a full Zero Trust model and ways we can change our security awareness exercises to be more effective. With all of the focus on moving away from less secure MFA methods, I fully expect we’ll see a change of tactics to more advanced methods but we’ll still, unfortunately, see a lot of BEC I’m sure. To summarize there’s a few callouts from this blog:

  1. The best bang for your buck is implementing technical controls, if you don’t already have strong authentication via WebAuthN and device based security you should be aiming for it.
  2. We should change our awareness techniques to be as close to our real life environments as possible and focus on increasing training ROI. This is going to ultimately help us decrease residual risk for the things we can’t fix with enforced technical controls. If you have a system to track security metrics I suggest tracking employee UX or ROI as a metric, rather than only tracking improvements in security posture.
  3. We should be moving security awareness even earlier in the process. Prospective employees are being targeted and we should strive our best to protect them as well. Atlassian recently put banners on their recruitment page which is a good start.