Think Twice Before Whitelisting for Attack Simulations

It is widely recognized that running realistic attack simulations is a vital part of preparing employees to defend against cybersecurity attacks. Hackers are regularly trying to trick people into leaking credentials or exposing other sensitive information, and it is important that your employees are exposed to these attacks in a safe environment prior to encountering such techniques in the wild.

However, running attack simulations can be a huge pain. It is easy enough for a hacker to get a social engineering attack into the inbox of a single employee, but delivering the same attack to everyone in an organization is much more difficult. There are various systems in place that might catch and block these attacks. Your email server might block the emails, the email might get sorted into spam, a third party cybersecurity product might block the email or warn the recipient, and the domain the email links to might get flagged as dangerous.

In order to avoid these problems, most IT professionals turn to “whitelisting”. Whitelisting, also known as allowlisting, is the practice of marking a domain or email sender as “safe” in the various systems that might otherwise block an attack simulation. While this practice is widespread among IT professionals, the cybersecurity risks associated with whitelisting are rarely discussed (or often overlooked), and the overall concept is outdated.

What Can Go Wrong?

When a domain or email sender gets “whitelisted”, it effectively is given a backdoor into your organization. Emails will go through without security checks, spam filters won’t trigger, and domain blockers will be inactive. That is the whole point of whitelisting, after all. You want malicious-looking content to get through to your organization unguarded.

To see how this can create a problem, imagine you buy an attack simulation product from CoolCybersecurityStartup that sends out attacks from microsoft@totallynotascam.com. The attacks contain links to pages hosted on www.thisisnotfakeatall.com. These are both domains owned by CoolCybersecurityStartup, so you trust the domains to be safe and whitelist them. All good so far.

Now it is five years later. CoolCybersecurityStartup has gone out of business, your IT team has moved on to a new attack simulation product, but the whitelisting of totallynotascam.com and thisisnotfakeatall.com lives on in various internal systems (like your email server). Unfortunately, you have no idea who owns those domains today. In all likelihood, the domain registration has expired, and any attacker is free to pick those domains up and use them for their own purpose. That means you just gave an actual attacker a backdoor into your organization.

Maybe this specific scenario feels like some far-fetched attack that only security researchers might care about, but there are plenty of real-world cases of whitelisted domains being used to execute attacks. When you look at the long list of domains that some phishing simulation products request that you whitelist, how confident can you be that those domains will never fall into the wrong hands?

If you absolutely must whitelist a domain for the purposes of running a phishing simulation, the best advice is to ensure that the whitelisting has a limited duration, or at least that you remove the whitelisting as soon as the simulation is over. In other words, make sure you keep your whitelist up to date.

An Outdated Concept

The advice above might have been good enough in an era when attack simulations meant sending an attack to the entire organization manually every six months or so, but times have changed. Attack simulations need to always be running, sending out attacks at different intervals and adjusting to each user individually. With that being the case, you can’t just remove a domain from the whitelist once an attack simulation has run, as the simulation is always running.

On top of that, your simulations need to be using a wide variety of domains, as otherwise your employees will just learn to spot the few domains your attacks are using. If you go to your IT team and ask them to whitelist 50+ domains for a phishing simulation, they are not going to be happy. And when they receive a new list each month, they will start looking for somewhere else to work.

The better approach is to avoid whitelisting altogether, which is what we have done at Pistachio. We never ask you to whitelist anything, as we know that is not a good long-term solution. It is bad for your company’s security, and it creates a lot of manual work for your team. Having built an automated product, the last thing we want you to have to do is maintain an ever-changing list of whitelisted domains.

A Call For Better Tooling

Whitelisting is merely one example of a deeper problem in the cybersecurity world, which is that the major tech companies are extremely outdated in their support of attack simulations. The assumption is that organizations are still running old-school “one and done” attack tests that were common a decade ago.

Microsoft Defender 365, for example, allows customers to add attack simulation domains and URLs, which helps ensure delivery (so, effectively whitelisting) but also to ensure the simulation does not trigger security alerts. However, Microsoft does not provide API support for this functionality, meaning it is up to each company to manually create such rules one by one. As explained above, that is not a viable solution.

As another example, Google makes it difficult to test anything other than an employee clicking on a link. If you want to test whether employees leak credentials on a fake page, Google is likely going to flag that page as dangerous in its Safe Browsing list. This makes the site totally inaccessible, as virtually every browser utilizes Google’s list. And, as it turns out, Google will not mark the site as safe even after proving the site does absolutely nothing malicious.

None of these problems are insurmountable, and we have developed plenty of workarounds to make Pistachio work, but these issues highlight that major tech companies are stuck in the past when it comes to attack simulations. Given that Google and Microsoft are developing AI tools that will almost certainly enable more sophisticated phishing attacks, the need for modern attack simulations is greater than ever. It is time that these companies update their tooling to provide better support for the type of simulations that companies are running in the modern era.