Introduction

“Security education and awareness darling, it’s all the rage! It’s simply to hot right now.” Ok stop, let’s take a minute to get some context. It’s the year 2021, organisations are taking a battering round the globe from cyber criminals who are deploying ransomware, extortion, and fraud via a range of methods but one you can’t not have heard of is phishing.

In this post today, I’m going to look at realities of initial access, phishing and some questions I think people should be asking themselves about the idea of phishing their own userbase. I try and look at this from multiple perspectives because I think it’s a complex subject. Let’s start with initial access methods!

Common Patterns of Access

If we look at the world of technology and cyber security, you will see logs of references to frameworks and language that is enough to send even the committed to sleep! However, let’s abstract from our TTPs, our MITRE ATT&CK frameworks and our “threat actors” and let’s talk in normal English.

We have a range of entities (businesses, organisations, and people) which create the potential victim environments. To gain “initial access” to these there are several methods deployed which include:

Technical Network Based Attacks (think password guessing/dictionary attacks) amongst other “exploits” which can execute attacker-controlled code over the internet (VPN remote code execution vulnerabilities etc) along side the main topic today… tricking people!

Yes, phishing is a form of social engineering, deploying the common EMAIL to create an emotional or automatic response from a potential victim to get them to:

  • Reveal information (other people’s email addresses)
  • Reveal sensitive information (usernames and passwords)
  • Run code (open attachments in normal lingo)
  • Act as a proxy (do something because a criminal simply asks them to)
  • Act under duress (sextortion is a good example, the criminals claim they have compromising pictures (Kompromat/компромат) and request money to keep them hidden from friends, family, and employers)

There are simply a ton of possibilities, some are relatively tame, others can be the start of a chain that takes down an organisation (really! This isn’t FUD this can and does occur sometimes).

Phishing Chains

The chain of events can be simple of complex, let’s just look at a simple chain:

  1. Criminal uses a free email account (gmail in this example)
  2. They send an email to the potential victims
  3. The email has a link to a credential harvester hosted on a legitimate but compromised web server (or simply a legitimate service like google forms)
  4. The link asks the victim to input credentials, which they do, not because they are stupid or reckless, because when you look at it, people are human, they are clicking on a link and following on screen instructions just like they do in everyday activity and interactions with computer systems
  5. Once credentials are submitted it redirects the user to a legitimate service
  6. The criminals then use the credentials to gain access to your mailbox or remote company services and continue their journey

And thus, your investments in controls may have done relatively little to protect you from this chain. This of course doesn’t include a range of scenarios and options which can be used to attack legitimate services, to man in the middle-encrypted connections, to relay credentials for multi-factor authentication etc.)

Essentially regardless of method used phishing results in one or more of the following:

  • An unauthorised party gaining your credentials
  • An unauthorised party gaining mailbox access
  • An unauthorised party gaining service access
  • An unauthorised party gaining remote code execution capability
  • Someone acting upon false information to enact tasks (e.g., make unauthorised payments etc.)

Long and short of it, this is using social engineering alone or combining social engineering and technical exploitation to steal and abuse the victims capability to achieve the evil goals.

They trix us!

Let’s think about this for a minute, lots of phishing relies upon:

  • Fear
  • Urgency
  • A promise of reward
  • Deception

Some of which you will see elsewhere in “benign” settings. Let’s look at some of my emails from reputable companies:

Graphical user interface, text, application, chat or text message

Description automatically generated

Graphical user interface, application, website

Description automatically generated

Both examples are legitimate services, both include a welcoming of fearful message, both ask me to click a link.

Now think about self-service password reset prompts!

Text

Description automatically generated

Now you might be here thinking, but Dan you started this blog talking about criminals and nasty cyber phishing and now all you are showing us are emails from legitimate companies. Exactly! This is exactly right, I am. Because these emails aren’t too far off the phishing ones. Now think about that for a minute…

  • Emails are designed to be read
  • Emails are designed to be accepted from unknown senders
  • Links are designed to be clicked on

Combine this with some realities, humans can be

  • Can be tricked
  • Make mistakes

This reality of the world is important!

So, you want to phish your own customers/users?

Ok now let’s get into this, let us start with one of the most important questions. WHY?

  • WHY do you want to phish your users?
  • WHY do you want to trick them?

But let’s not stop there:

  • To WHAT end?
  • WHEN will you be done?
  • WHAT does success look like?
  • HOW will you measure the exercise?
  • WHEN will you run it?
  • HOW often will you run them?
  • WHAT will occur if they click?
  • HOW will you track clicks?
  • Will you steal credentials?
  • Will you execute code?
  • Will you whitelist your sender domain?
  • WHO will you be emulating?
  • WHO will you target?
  • What will be the outcome of the phishing?
  • What will you do differently once you have the (currently unknown) results?
  • HOW will users report?
  • So WHAT?
  • HOW will the audience respond?
  • Will they be happy?
  • Once you have credentials or RCE will you go further?
  • HOW far will you go?
  • Will you test your IR processes?
  • Will you do this yourself or will you outsource it?

There are so many questions to think about from a simple line of “Run phishing simulations”. The answers to these are unique to each scenario and organisation however these are the type of things we need to consider.

Risks

So, let’s say we’ve gone through all the questions and we think that a phishing simulation is a good idea and considering our security programme portfolio a good investment vs other options let’s look at some of the risks:

  • The phishing is picked up fast and the domain blocked, the first run shows a strong posture, but that’s just a snapshot in time, what if this was luck? What about the one that sometime in the future gets through?
  • You erode trust of your userbase
  • You realise that you know exactly what you knew before
  • You can present a downward trend graph but only for so long
  • If someone does get through what occurs? Does the investment in time, money etc. actually stop the zero day or bad case day?

There are clearly more but you get the idea, even if this is a feature of your current security capabilities you must think about what this looks like holistically. There are risks of both conducting and not conducting a simulation, but one thing is for sure, baddies will be giving you a 24/7 365 non-simulation scenario, so there’s that to consider, but there’s also the fact that this isn’t a binary choice. You could deploy a hybrid scenario.

I’ve not talked about phishing simulations for a long time, I wrote a guide many moons ago about using GoPhish:

https://www.xservus.com/wp-content/uploads/2019/02/A-day-out-Phishing.pdf

I’ve also posted before on phishing sims being part of developing a defence against phishing (so does my opinion now differ? also haha the same title for both)

A day out phishing

A likely scenario

Let’s take a realistic scenario:

  • You decide to run a phishing campaign against your own people
  • You stand up some infrastructure or rent a service
  • You phish your users
  • Over fifty percent of them click the phishing link within 48 hours
  • Of those 50% 20% gave their credentials
  • One person reported the phish to the helpdesk

You now know what you probably could have guessed before that your organisation is vulnerable to phishing! Great…

  • In doing so you have scientific proof
  • You also might have alienated a ton of people you need to trust you

Let’s Park the second bullet and go on the scenario further:

Ok we are vulnerable to phishing (reality check you always will be), what can we do about it?

  • Implement MFA (Not a silver bullet but makes it much harder)
  • Implement hardware token based auth (Hard to do but this is very effective)
  • Improve mail security defences (architecture and/or configurations)
  • Deploy a programme of security awareness training (CBT vendors love this but does this truly work? Does this stop the extortion or eliminate the threat?)
  • Ensure staff are aware and understand reporting processes (this is often under looked – this part is important)
  • Improve detection and logging
  • Improve overall security posture to limit impact post compromise (assume breach)

Erosion of trust and options

Now ok I might have missed a few things out as I tap tap tap away but when we look at simulated phishing, I reckon there are significantly strong arguments both to do this and to not do this. The risks I see are the trust erosion when conducting this internally. When people don’t trust the security team that’s a major problem, likewise, simply outsourcing this could potentially damage business relationships with key suppliers. Now this might all sound negative, but frankly it shouldn’t be. There’s a ton of options:

  • Communicate sims clearly
  • Develop a process and method which does not alienate your customers
  • Don’t just focus on the “users” look at the lifecycle and posture holistically
  • Consider the outcomes and impacts, drive for objectives that are positive and not focused on end user shame and belittlement
  • Consider assume breach and skip the phishing actual people part
  • Use a white box clear communications approach
  • Test the reporting process
  • Test the response process
  • Test the technical controls
  • Consider investments in other areas
  • Include phishing in pentesting, red teaming and purple teaming
  • Make education part of the culture not just a CBT

Summary

Ok so I might appear a bit Dr Jekyll and Mr Hide about phishing simulations, because well I am. I think they CAN be a useful tool as part of a wider security programme; however, I often feel people deploy this as a point solution to drive CBT projects or to simple create something measurable. The challenge with phishing simulations is that they are a complex topic. The outcome of a bad planned and executed simulation doesn’t give us greater insights into our posture and doesn’t improve security and business communications. Conversely when looking at how to develop a good posture and culture this may include simulations. The key difference from my pov is style, approach, communications, and follow-on actions. I don’t personally care about clicks on links, I don’t really care about lost creds, I care about what have in place to identify, protect, detect, respond, and recover to cater for the scenarios when controls and humans fail, so that on a rainy day there’s an umbrella handy and shelter available. As to whether self phishing is a good idea, I think that’s a question you need to think about, because it isn’t a yes or no answer (for me!)

Leave a Reply

Your email address will not be published. Required fields are marked *