What is a Phishing Simulation?

Many cybersecurity or IT managers look for phishing simulation platforms to analyze the likelihood that their organization’s users will fall for social engineering traps. However, we often need to remember how they work or what they specifically entail.

A simulation replicates the behavior of a real cyberattack in the following aspects:

• Duration of the campaign, usually a few hours
• Medium used to deliver the attack, generally via email
• Presence of social engineering techniques in the headers and body of the message
• Use of links or attachments
• Use of fake websites that mimic real ones
• Measurement of user actions, such as opening the email, clicking on a link, etc.

But there is an important difference: a simulation does not capture sensitive information and is harmless to the end user or organization.

Real phishing attacks typically end when the cybercriminal captures, for example, the user’s credentials. In contrast, a simulation might display an educational message after the user performs a risky action, like submitting private information in a form.

Phishing Simulations Simulate… Phishing

The main function of a phishing simulation is to behave like real phishing.

However, many people expect something different. For instance, that the campaigns last a month, that they trick as many users as possible, or that the simulation emails are not detected by security technologies.

This expectation is not consistent with reality. If we want to simulate a phishing trap, it must behave like real phishing.

What Do We Want to Measure?

The ultimate goal of a phishing simulation is to measure user behavior to understand the organization’s risk level.

Why do we emphasize this point? Mainly because if we want to know how our users would behave in a real attack, we must ensure that the user group we want to evaluate receives the phishing email.

Frequently, security or IT managers expect simulations to reach the user’s inbox bypassing all the organization’s technological barriers without any whitelist process. Sometimes this happens, sometimes it doesn’t (just like real phishing), but the only thing we achieve with this approach is obtaining an incorrect result about our users’ risk level.

A phishing simulation is not used to measure whether the organization’s security tools work. It is used to measure the behavior, conduct, and actions of people. Therefore, we highlight the importance of configuring the appropriate whitelists so that we can measure what needs to be measured.

Whitelist and SPAM

The whitelist process is among the steps to consider when creating the first phishing simulation campaigns.

One of the goals of the whitelist is that the phishing email reaches the user’s inbox directly and does not fall into SPAM.

It is also used to prevent security tools from interacting with the simulation emails, generating statistics on behalf of the users, a very common situation.

Specifically, what happens is that phishing simulation emails contain unique links that uniquely identify a user within a campaign and serve to detect the interactions that the user makes, and therefore, measure their behavior.

Without an adequate whitelist process, security tools query these links one or more times, thus generating false interactions on behalf of the user to whom the simulation was directed.

Ultimately, they prevent the measurement of user behavior, which is the goal of the simulation.

A correct whitelist process for the domains and IPs used in phishing simulations will allow us to obtain a clean and useful result from our simulations.

Test Campaigns

To know if our whitelist process is working correctly and we have considered all relevant tools, we must conduct test phishing simulation campaigns. These campaigns should not affect our awareness program’s statistics, and they allow us to ensure everything is in order before launching our real campaign.

Test campaigns are a good practice to consider before launching each phishing simulation campaign. It is not enough to do it only once after implementing the whitelists, as it is very common for security tools to update, change, add, or remove. This situation has the potential to ruin an entire campaign. And it does.

Therefore, we recommend conducting test campaigns when evaluating which phishing simulation scenario to send and the day before the simulation.

Other Security Warnings

After implementing the whitelist in all relevant systems and the email client, users receive the simulations in their inbox in most cases.

At this point, the following situation may occur: upon opening the simulated phishing email, they find a security warning indicating that the message is suspicious.

These types of warnings are independent of the simulation tool used. Their presence is conditioned by:

• The email client
• The whitelist configuration options it provides
• The configurations of each user regarding the email client and the actions the user particularly takes on emails, such as marking a sender as SPAM.
• The result of the analysis that security tools perform on the email, including:
  • The content of the FROM, CC, BCC, Reply To fields, and other email headers like Return-Path
  • The result of validating the email against security protocols like SPF, DKIM, and DMARC
  • The words or phrases used in the subject or body of the email
  • The presence or absence of links, their reputation, and characteristics, such as whether they are shortened or not
  • The presence or absence of attachments, their name, extension, and content
  • The presence or absence of images in the email, their relation to recognized organizations, the URLs they reference, etc.

How to Remove These Warnings?

These types of security warnings are not a bug, malfunction, or error of the phishing simulation solutions, but the result of their interaction with other social engineering protection technologies. They cannot be avoided 100% as this depends on the evolution and specific adjustments of the attack and defense tools.

It is most common that the email client does not provide a direct method to remove them, and for this reason, the recommendation is to keep them because we cannot control when or how they are shown to some users. Their presence depends on the analysis of a very broad and constantly changing set of factors. In practice, it can be observed that even within an organization, the same user on the same email sometimes sees a security warning and sometimes does not.

Ultimately, these warnings are present because we are simulating a real phishing, and therefore it is correct to measure our users’ behavior in this scenario.

Final Considerations

Phishing simulations are an essential tool in today’s reality, where phishing holds the main place in all cybersecurity reports over the past decade.

Measuring our users’ behavior and taking actions to foster a secure culture is the right path to addressing this risk and reducing both its likelihood and impact.

Understanding how this measurement technique interacts with other technologies is key to maintaining focus on what is relevant: the evolution of user habits.