Best Practices for Effective Phishing Campaigns

Introduction

1. Presenter's Credentials & Overview 

- [Bobby] Again, welcome everyone to today's webinar, Best Practices for Phishing Campaigns. I'm Bobby Kuzma, Director of Research, Strategy, Enablement here at Core Security, a HelpSystems Company. And I'll be going through some interesting material today on how to design, build and run effective phishing campaigns for a variety of purposes, not just for pen testing but as part of an overall security program. So, let's get started here. First off, what we're going to cover. Why do we phish, some things for setting goals and rules of engagement, best practices for building effective phishes including some examples that we've had recently and used. And then what do we do with this data when we're done? So, I'm gonna open up a poll real quick, just to get a little bit of information from everyone. How do you use phishing in your security program? Well, we'll get started. And I'll turn back and use this a little bit, feel free to put in more than one answer if it applies.

Why Do We Phish

1. Measure Click Through Rates 

So, why do we phish? Phishing is a fact of life, unfortunately, on the receipt end and from an attacker standpoint, it's also one of the most effective ways to get into a network environment. It is the preferred vector for malicious actors. On the recent Verizon DBIR, the 2019 version, 94% of malware deliveries came in by email, which is a fairly impressive statistic considering that almost all organizations have some kind of spam filtering and email hygiene. And it's been a best practice for quite some time to strip binaries from inbound emails but there's always that use case. So, thank you for doing the poll. 80% of breaches reported in the DBIR involved phishing, maybe not at the start but they involve phishing as a critical element. Yet the click rates that are reported by various testing vendors have been hovering at 3%. So, they're at the lowest rate ever which tells us a couple of things that are interesting. It could be that our user populations are being really good at detecting the types of phishing emails that are used to test whether or not people respond to phishes which tells us maybe we have a bit of a statistical liberation. Maybe we've got a survivorship bias because clearly companies and other organizations are getting breached and it starts with phishing. So this is a clear and present problem. This is something that isn't necessarily being addressed. And there's so much of it going on that even if only 3% of those tests are being clicked on and let's say that maps adequately to the real world, 3% of emails is still a lot of emails. I don't know about you but I probably get a thousand emails a day. So, if I'm clicking on 3% of those that might be phishes, that's still going to be a problem.

2. Test Our Technical Controls 

We're gonna phish for a couple of reasons. First off, we wanna test our technical controls. So, we've got spam filtering. We've got message hygiene in place. We've got various rules in our email infrastructure that are supposed to help protect our end users. Are those working? Are they effective? Are they operating as designed? Is there's some new techniques for bypass that we need to evaluate? These are valid things to check with the phishing campaign. They're not necessarily what everyone thinks of when we're doing a phishing campaign but having that assurance of, yes, the controls are effective. Yes, they're operating as designed is a good and important thing. Now, not every organization is necessarily going to have the ability to check in mass those controls. And we all know that there are certain users who there are exceptions. There are different roles that require more flexibility. That type of validation should be part of your phishing campaigns. So, we'll get a little bit more into that in just a few minutes. How long have do you use case for phishing? Is testing your users and your user training? Everybody loves when they have to sit down through their quarterly or annual, don't click on the links that look hunky training, don't open attachments from people you don't know, people that you're not expecting to receive attachments from. And then how do we test to see if it's working? We send a bunch of obvious phishes to the users or we send some not some obvious issues to the users, depending on our design and what we're trying to test. Sometimes we design these ourselves. Sometimes we rely on templates from third party vendors, which way you choose to go depends on what you're trying to accomplish. We can use these phishing tests to test our network segmentation. Then, we get a payload onto the machine and we get access to credentials and we collect those credentials. Once we have those credentials, then we use them to escalate that system to system, once we're in an unprivileged user environment, can we escalate from there? Can we get where we're not supposed to be? Phishing tests can be used to test that segmentation. I'm not necessarily a big believer in using them in that way, because it's often more effective to start with an assumed breach scenario when you're doing that type of testing.

3. Understand Who's Most Vulnerable 

So, what do we wanna think about when we're planning a phishing campaign and establishing our levels of engagement? First off, we have to know what we want to achieve when we're doing a particular test. There's oftentimes a drive from users, from management to do one test and call it lovely. Well, it's hard to design a test that covers all the scenarios and does so effectively. So, I tend to try to suggest that we treat each phishing campaign like an experiment and we develop a hypothesis. Can we evade the spam filter by doing Unicode-based look alike domain forgery? Can we evade the technical controls in a particular way? We design our experiments to test it and we figure out who we're going to target. We don't want to necessarily go and test the entire organization at once. We also want to have a valid sample size, trying to phish a particular user, a sample size of one, isn't necessarily the best thing that one can do. I certainly don't like being singled out, our user populations probably don't either. In fact, I know that they don't. Depending on the size and spend to build engagement, you can run multiple, simultaneous phishing campaigns at once, each with different goals. You may be familiar with the concept of AB testing. With this, you do slight variations and hit a statistical sampling of your population and seeing what works and what doesn't. So, we want to target a limited group of each test. Now, depending on the size, again, I tend to prefer going with a department or group within an organization. It depends on the work chart. And there's a couple of reasons for that. One of them is that the pretext in the phish that's effective per se, HR, may not be effective for finance, may not be effective sales, may not be effective for support, may not be effective for engineering.

4. Identify Most Successful Attacker Trends 

So, attacker behavior tends to be either broad spectrum scattershot, we're just going to tumble the water and see what comes up, to use a phishing metaphor, where there's very little targeting and I'll show you an example of that a little bit later on. When you specifically look at what a group does and use that to build the phish, that tends to have a much more effective rate and it more closely mimics the behavior of attackers that are doing deliberate targeting. So, while spear phishing is a thing and whaling is a thing, we wanna avoid doing personalized targeting in these campaigns. And a lot of that is because of the risk of developing an us versus them mentality within an organization. Your job as a security professional is to ensure the security of the organization to help achieve its mission. If the population of users in the company look at you as the enemy, that doesn't help achieve the mission. Now, certain users with high privilege or high value do need to be exercised more frequently and they are subject to more personalized threats. And that is a necessity. But going specifically after Susie from accounting with an email is probably not the best thing for gaining Susie from Accounting's compliance in the long run, that tends to build resentment and within an organization, you got to work there. Those types of tests when they have to be done are better suited for having a third party conduct them because the third party doesn't have to continue interacting on a daily basis. So, there are certain groups that are more sensitive than others, executives, for example. More often than not, I have had experiences where in the definition of ROEs, executives are particularly, higher level executives, of course, we want to be included in the test, of course you can come after us and then there's blow back when they have a disproportionate click through rate for whatever reason or it may be some other group. Executives tend to have more reach with their displeasure. So, it's part of the security exercising process. We want to ensure that we're validating, that our training is working and make sure that they get better training downstream if they need it without calling them out as being non-compliant or if not working. The goal here is always to improve the security, to help everyone level up. Some people learn better with different mechanisms. And a lot of the anti phishing training is very oriented on one or two particular learning styles. I know I learned differently than a lot of my coworkers here at Health Systems and Core Security. It's a thing. So, we also want to think very carefully about what types of attack surfaces we use in our phish and the ramifications. Let's say that your organization, once a month, on a Friday, has a bunch of food trucks come out. And there's an email that we know circulates that includes the menus for the food trucks, so that people know what they should be ordering. Probably don't necessarily want to design a phish to look like that email. That's going to have long-term implications for you as a security organization. That's not going to engender warm and fuzzy feelings from everyone in the company. Although I've had success with using phishing training emails as a phish, strangely enough, that's an interesting irony.

Building Effective Phishes 

1. Vary the Difficulty  

So, let's talk a little bit about how do we build effective phishes? So, one of the problems is that, the traditional phishing template is one where there was lots of spelling, errors and bad grammar and it's obvious that something's wrong. They look like they're written by someone who English is not their first language. There's formatting errors. They don't quite look right. Problem is the bad guys have spell check and there are actually services available in the underground of electronic crime that will provide spelling and grammar support as well as formatting support for these phishes. But you wanna have some easy wins for the end users, particularly if you're going to exercise your reporting functionality. You want to make sure that things stand out and then increase the level of difficulty as part of your campaigns. So, first thing is, think like an attacker, okay? The target of most phishing attacks is either to get malicious code into the network past the parameter, or to induce the user to share their credentials with a realistic looking site, so that those can be further attacked and leveraged for deeper penetration into the organization. Now, depending on what you're trying to achieve, those are different modalities that you're going to want to leverage.

2. Borrow From Others 

We want to use open source intelligence to build phishes that are customized to the group or to the organization. You want to be specific. If you've got multiple locations, you may want to customize them should they be generic things like via your Amazon order is delayed or FedEx is returning a shipment or the classic invoice unpaid kind of ruse, they work but they're going to have more scrutiny and less effectiveness at getting users into the mode of being critical of what's presented in front of them. So, if you know your target population, you can build really effective phishes. So, one of the things I love doing is pulling in phishes that are being used from actual campaigns. So, I'll get tidbits from the alerts that US Cert through a DHS Seesaw publishes through other intelligence sources. And I've got a couple of domains that have wide open mailboxes with no filtering at all that I just use to collect crap and go through that and find things that look good. You don't have to necessarily come up with everything on your own. In fact, I recommend that you do a mix of fully custom, bespoke phishes and taking phishes that are live and in the wild and fresh, make sure that they're sanitized so that there's no malicious payload and then make them applicable to your organization and campaigns. After all, if they're being actively used in the wild that's the current threat that your users are going to be facing, and what better way to test how your users are responding to that than by putting it in front of them in a safe manner where it's instrumented and we can collect statistics on it.

3. Consider What Fools You 

So, here's an example of a phish that I got recently and know this is subject, unpaid. And we can take a look at this. I just want to call out some details here. First thing was the subject line, okay, that got my attention. It made me look at the email but then some things started putting me out here. We have this strange, don't know where that is, I don't recognize that as a anyone that I've done business with, it's a plausibly looking email address but now we look at this strange pattern of capitalization in the body. Yeah, that's a little hunky, that calls out to be odd. Also do pay attention, the invoice number in the body and the invoice number up here don't match. Finally, the supposed that attachment was a image link going to a SharePoint hosted a PowerShell payload that would do some interesting things. Our threat research team had some fun dissecting this one. So, this was a good payload driver. The next one I'll show was a lot more effective. This one was spoofed from one of our in-house employees. So, first off, the attackers did their research. So this was masqueraded as coming from one of the folks in one of our offices who would actually be looking at the generic voicemail on the phone system. So, it's a plausible subject line, plausible but not quite right. The phone number doesn't match. So they didn't do all the homework. They got the name but when we have her on it, it was bad. They did their homework, they got the company and they knew that my email ends in core security and it's got sent to the correct email. Oh, we've got a cute little link here to click on which went to a login page for collecting my credentials. But a couple of things to check this out. First off, that's how you say is not normal for this particular person. Normally when this person sends me an email it's, Hey Bobby or Hey, but that could have been a system generated thing, it's plausible but that extra period jumped out. These are all good tells for an almost right phish, almost. So, this one came closer to actually fooling me and I'm paranoid about emails to begin with. So, this would be a good style of the phish to use in most environments if you customize them and I can strip this down and send it out, drop a question with your email requesting a stripped down copy of this if you'd like our version of it, I'm more than happy to get that send out later.

4. Don't Escalate Too Much 

So, one of the other things, phishing isn't just about email, there's other aspects to coercing a user through a pretext there, we can escalate that through from email to voice, there's you can also utilize social media depending on your ROE and the comfort level of users. On the social media side, if you use fake profiles, I will warn you in that, LinkedIn is really, really good rolling up fake profiles and identifying them. So just a heads up on that. Now, one thing though, if you've escalate past email with your phishing campaigns, you might not get more out of it than the downside risk. That can create much more strongly an us versus them attitude amongst and between the security team and your users especially if you're an in-house tester. If you're an outside consultant, that's a whole different ball of wax but we don't necessarily want to have you go gallivanting off to do these things without considering the potential repercussions within the social environment of the organization. We don't want to single out specific users unless it's for praise. So, one of the things that I strongly recommended in the downside reporting is call out users who not only didn't click on them but who followed the reporting process. You want to encourage the behavior that is good for the organization. If specific users also sent out emails to their team, warning them of a phishing campaign that was going on, that's also behavior that's incredibly useful and it's praiseworthy. Now, it might skew the data on your task, but you did demonstrate that the user and the data sharing between the users is a part of your compensating controls. So, there's good to be had there with that. And the biggest thing here is we can craft phishes all day long that people will click on. And the goal here isn't to fool the users every time, okay? If you put enough effort into designing a pretext, you will eventually succeed with every single user unless they don't even check their email which I've encountered, but you need to remember that you're working toward the same goal as the rest of the users. If you win at this, you're losing as an organization because there's a problem. And the goal here has to be oriented toward, you're a training partner. You're identifying the areas where more training is necessary. You're providing that realistic simulation where they can practice. This is like, when you learn how to drive a car, you probably studied the road rules and then you had some hands-on work. It's the same thing, you study through the training, some of the signs of a phishing attempt and now here's some attempts salted in with your email flow and try to identify them, or at least make sure that you don't act on them, it's the same type of process here.

Solve Identified Problems

1. Implement Infrastructure Changes

So, now we've got this together. What's next? So, our goal is to increase security, maybe we found technical controls that are not working the way that we thought that they were working. That's often the case where we find that something was disabled at some point in the past because of a specific use case or a very specific exception and then somebody forgot to re-enable it. That's often a thing, particularly with blocking of binaries or some organizations will block zip files and things like that. We identify problems. We work to solve them. That's always the goal. And this data that we're collecting feeds back into that. We identify those problem areas.

2. Vary Learning Styles Targeted 

Now sometimes, we might identify a fairly significant problem. Like the training may not be effective and that happens. Not everyone learns the same way and not all training is good. And the training isn't punishment and you're not the enforcer. I'm vehemently against the process that some phishing testing companies will utilize where if the user clicks on the link, they immediately get sent to training. So you've clicked on the bad thing, now for punishment, you have to sit through an hour of training. That's not the goal, that builds resentment with the users. Yes, they do need more training if they're clicking on the links. It shouldn't be punitive, that just encourages them to not pay attention and that continues reinforcing the cycle. If the training's not working, it's not going to work if you apply it over and over and over and over and over and over and over again. So, maybe something different is required. Maybe putting up examples of actual phishes that have been found in the organization at staff meetings. I've seen some organizations take staff meetings and have the staff boat is as a phisher is this real as part of their thing. And they may get a collaborative exercise, that's and make it fun, game-ify it. That's actually a really effective way to help build up that brain muscle memory of recognizing that something's not right in the email and that we should do something about it and with it. The other side of the training conundrum is many organizations are required by regulatory regimes to provide proof that they've had security training that's repeated and that training is often the driest and most boring stuff imaginable, that it's there to produce a paper trail for the compliance side, but is completely ineffective at the actual goal of helping users better protect themselves and the organization. So while that training to fill the checkbox is necessary, it may not be the best option for helping improve the security of the organization and the users. Different groups within your organization culturally may end up with needing different styles of training. Yeah, a lot of it's going to depend and there's going to be a lot of experimentation. And some of that may come back to doing AB testing on that.

3. Be Cognizant of Frequency 

Now, depending on how often you conduct your phishing campaigns and I think that phishing campaigns should probably be conducted more or less continuously with any organization. You don't necessarily want to target the same group over and over and over again but rotate through the organization so that the technical controls are constantly being exercised. So you can catch misconfigurations, but hit the users at least once a quarter with their training. That seems to be most effective in my experience. More often than not and you run the risk of getting testing fatigue from the users, particularly if you're not changing up the pretext that you're using and there's a lot of creativity that's involved in keeping these constantly updated which is why you are own junk mail folders, probably one of your best friends for keeping this good to go.

4. Reward Successful Users 

So, and then finally, again, I can't stress this enough, the users who actually do the right thing and they report along whatever reporting system guidelines you have, you want to praise them, call them out in your reporting. After if you do some kind of company-wide announcements or division announcements and you've got the ability to suggest content for that, that's a good place to give those users a gold star. You may not be able to reward them monetarily, but buying a pack of certificate paper and coming up with a certificate for shortest time to reporting a phish or fastest report is not a bad way to encourage that good behavior. Some people having a certificate coming from the security team for thanking them for being effective, that actually will brighten their day because security is usually the department of know in some organizations. We don't wanna be, but that's perception. And if you change that perception, you're helping, you're all working together, that brings huge dividends. Great. Well with that, I'm happy to give you back 15 minutes of your time from the scheduled a hour and have a good rest of your week, folks.