Simulated phishing: How to design a suitable scam

If you haven't read them already, don't miss our first two posts in this series, about goals and methodology and communications strategy!

We all know that some phishing emails are really obvious, while others can be a lot harder for people to identify. Consider the following three categories of difficulty:

• Plain and obvious emails are e.g. presented with a nearly unbelievable story, and/or with noticeable errors in brand, presentation and grammar.
• Moderately probable emails have a more probable storyline, maybe look like a familiar brand users have a relationship with, but the sender address and links do not match up with the real brand’s identity.
• Advanced emails are seemingly sent from a compromised inbox or sender domain, contain parts of a plausible conversation or process, and have in general few technical indications of being a scam.

Content relevance could be to which extent an email mimics a workplace process or practice, whether the email has workplace relevance at all, or that it aligns with other relevant situations, including events external to the workplace.

A very obvious phishing email will naturally yield far lower click-rates on links and attachments than the more advanced ones. A higher number of available cues will make the scam more obvious, while more content and context familiar to the recipient will make it more difficult to detect.

For the most difficult phishing simulations, a trustworthy email designs could be combined (or replaced) with other delivery channels. These include SMS, Whatsapp, chat or even phone calls, social media interactions and traditional mail. It is however more difficult to control the possible outcomes of very advanced simulations. So maybe these are not channels to include in simulations which target everyone. Instead, maybe they could be used to add a little spice to the mix for a more targeted scenario for high-value targets. Also, instead of plain statistics, maybe a more useful outcome from advanced simulations is an intranet article, video or similar, where one such target is sharing their experience from being tricked.

But one thing should be said rather too often than too seldom: Do not humiliate your colleagues with a phishing simulation. It will not help your security program in the long run.

Should you be interested in a more comprehensive guide for assessing the difficulty level of phishing emails, we recommend having a look at the NIST Phish Scale research (available from https://csrc.nist.gov).

Designing a threat scenario

In the next step, after end-users have received your message, possible outcomes may include:

• Login information is entered on an illegitimate website;
• Sensitive data are disclosed in writing through a reply;
• Malicious software is installed on the user’s machine;
• Money are transferred to a bank account.

The scenarios above represent a simplified summary of phishing techniques and objectives. Deciding on a theme for your simulation, would again depend on your main objective, in combination with how difficult it should be to identify the scam.

Looking at real phishing emails, there should be no lack of inspiration available for your simulation. Ripping off a well-known theme, such as file sharing services, social media or any other communication platform, is likely to elicit a few clicks anytime. Of course, this depends on how realistic their visual appearance is, but in the real world, scammers are using these so much simply because they work.

However, if your main objective is to exercise on reporting phishing emails, there is little need to make it too difficult, at least not in the beginning. Your objective is simply to include as many people as possible, and create as little noise as possible, while giving people an opportunity to exercise desired security behavior.

When your colleagues have gotten well into your routine, some of them are however likely to expect more difficult challenges. Yet this does not necessarily mean that everyone are ready for the same level of difficulty. It may therefore be a good idea to differentiate simulations for various difficulty levels, allowing people to receive more personalized challenges along the way, should they prove to be ready for it.

Preparing content

In order to deliver a phishing simulation, there are basically four components needed:

• An email (and/or SMS) message for the initial lure;
• An SMTP (and/or SMS) gateway for dispatching the message;
• A website (landing page) or attachment which contains the “malicious” payload;
• A debriefing page to educate users about the simulation, and how to proceed.

Setting up all of these may require some involvement with a few technical aspects, unless you are using consultants or turnkey phishing platform service to get the job done.

Technically speaking, for simple landing and debriefing pages, HTML and other standard web technologies are required. The attachments part may in addition require some in-depth knowledge of actual malware delivery to simulate the threat, yet of course without going “all the way” to infect the user’s device.

It is possible to run code embedded in many kinds of attachments, including Office documents and also HTML documents. Attaching HTML documents has actually become widely used in phishing campaigns because they appear harmless, and few spam filters will block them. Opening them will also happen without further warnings in the web browser, even if they contain scripts that forward the user to an arbitrary landing page on the Internet.

What should the phishing campaign look like?

You have now arrived to the point where it could help to know a little bit about web design and development, but this is not mandatory. Creating a phishing email is just as easy or difficult for you as it is for any “other” online scammer!

Common themes for simulations (and of course real phishing campaigns) include for example spoofing of service related emails from well-known brands and systems people already use:

• Productivity tools like Office 365, Dropbox, Google, etc.;
• Security notifications relating to people’s email accounts, expired passwords, storage limits reached, antivirus alerts, etc.;
• Payment and logistics updates with reference to e-commerce and physical delivery;
• Social media account activity or private messages with personal appeal.

Simulated phishing could naturally also resemble spoofed messages from customers, partners, managers, IT-support or other colleagues, i.e. business executive scams, relating to purchase of gift cards, device configuration, invoices and other business related communications.

The simplest way to design your email, is to simply look into your archives of actual phishing emails you or your colleagues have received in the past. In fact, this is also one of the better ways to design a scam, because stealing the design and content from the scammers will indeed make your simulation more realistic, too.

Even copying any spelling or grammar errors, or attempts at spoofing logos and URLs with a varying degree of success, could at this stage become valuable input to your exercise.

And the same goes for both emails and websites alike. Don’t be afraid to borrow a page from the handbook of cybercriminals, but be aware: If you decide to go with this approach, you may also accidentally include harmful content from the original scam, such as keyloggers, malicious redirects and form submission targets. Therefore, you should get someone with a technical understanding to review any such content before sending it to your colleagues.

An alternative approach is also to design your scam from scratch, and doing this in collaboration with a web designer and developer, if needed. The advantage here is naturally the creative freedom you will have, but again, stay committed to your goals for the exercise and do not carried away by the great powers at your current disposal.

If none of these alternatives are relevant to you, you can also get ready-made phishing simulation templates from a provider like Secure Practice. Use templates out of the box or as a boilerplate for any customized tweaks you may like to do.

Technical considerations

When sending simulated phishing email, you want to avoid using your company’s ordinary email servers. You simply do not want the risk of end-users flagging or blocking email from your own organization. Getting your day-to-day email flagged as spam could seriously hamper your business, but can luckily be avoided with using an external mail server.

Another advantage of using an external mail server, is that it will increase the realism of the simulation. For technically advanced end-users who know how to inspect the email’s metadata (headers), it is easy to tell whether the email was sent internally, and not from an internal source. Therefore, you may be more exposed to accusations of “cheating”.

The importance of realism will however – once again – depend on your goals for the simulation. Are you going to actually harvest usernames and passwords, so that you can verify whether they are in fact valid for the actual users? Are you are going to carry on with a full-blown penetration test, using the «stolen» credentials, afterwards? If not, it is probably better if the phishing website will not store any of the data input by users.

To avoid storing such sensitive data, it is straightforward to avoid any logic which will further process the received data after the user has submitted them. There may however always be a risk of data leakage when e.g. credentials are transmitted away from an end-user. Consider also that you may want to train users to avoid non-HTTPS websites in general, and put an unencrypted form.

Therefore you may want to consider not sending any data through your phishing page at all. Achieving this normally means breaking with how web forms are usually built, and hence the HTML standard, on purpose. It only has to look like a form, not actually work like one! If you are unsure, it is easy to test whether any data are actually sent through a phishing form by inspecting your own web traffic. This can be done through the networking section of the built-in web developer tool (F12), as provided in most web browsers, or with a dedicated web proxy application.

Whitelisting emails

A little bit of “cheating” can still be useful to reduce the workload involved with sending the simulation. Your email gateway and spam filter will naturally try to block incoming phishing attempts, which should also include simulated phishing. This is of course a good thing, since your phishing email will resemble that of an actually malicious attacker.

Unless your goal is to test your organization’s spam filters, you will however need to ensure that your phishing emails are not stopped by the spam filter. Again, this depends on your objective, and some may in their full right call this cheating, but it all boils down to what you are going to test. For a motivated attacker, it is only a question about time and effort (cost) to target their phishing campaign so that it will burst through your technical defenses.

In generic terms, a common approach to whitelisting the phishing email would be to reference the IP address of the sending server, if this is available to you. Otherwise, an allow rule based on sender email in combination with other attributes may do the trick. Just make sure to not create a vulnerable whitelisting rule, which could be exploited by actually malicious attackers afterwards.

Also, you should also check whether it could be necessary to whitelist any links in the phishing email, if your company uses a self-learning web filter.

And with this step, we wrap up this post. Look out for our fourth and final episode of this series, which will detail the following-up of your phishing simulation to ensure sustainable and lasting outcomes for everyone. Stay tuned!