Simulating phishing attacks

Phishing is by no means a new phenomenon - for years now, organizations of all sizes have been falling victim to attacks ranging from the laughably obvious to the frightfully sophisticated.

A successful phishing attempt is often the first link in a chain of events that lead to a high severity information security incident, like the disclosure of sensitive information or the theft and destruction of intellectual property. As a result of this, measures aimed at detecting and stopping phishing attacks are now a vital element in any organization’s information security strategy.

A false sense of security

Technical measures are usually the first that come to mind, and these have advanced considerably since the early days of the Internet. We have filters (and they are getting better and better at recognizing fraudulent messages), our browsers maintain lists of known attacker sites and the impact of a successful attack is lessened by security features such as two-factor authentication and modern intrusion detection systems.

The bad news is that, while technical measures may stop the majority of attacks before any damage can be done, they might actually help the more sophisticated attackers who are able to circumvent them. Since obvious phishing messages of the more common variety rarely reach our inbox (while e-mail is not the only vector attackers can use, it is the focus of this post), we begin to build a kind of confidence in the algorithms that protect us, implicitly trusting messages that get through them. Without visible danger on the horizon, organizations tend to let our guard down.

From an organizational security perspective, this presents us with a new problem: while people can be trained to better recognize fraudulent messages and websites, they rarely have the opportunity to do so in practice. One might spend the entire time between two yearly information security training courses never putting any of their content to use - quizzes and the like do little to help with this.

Whilst we cannot risk letting real attacks through on purpose, we can construct our own phishing messages based on known attacker patterns and let them loose inside the organization. Not only does this provide a safe environment for employees to apply the techniques that are essential in recognizing fraudulent messages, it also lets us track the efficacy of our training program, measuring progress over time with repeated tests (counting clicks, compromised credentials, e-mails reported as phishing, and so on).

Since early 2019, the Security team at Tresorit have aimed to deliver one of these simulated attacks to our employees inboxes every quarter. While more and more organizations choose to perform such tests (for example, GitLab chose to publish a write-up on theirs, and news of a test performed by GoDaddy has been featured in several online publications), Tresorit sets the bar for these tests high - by simulating a variety of attack types, ranging from simple to highly sophisticated.

Designing the tests

From the very start, we decided to focus on simulating attacks that try to obtain user credentials for various external and internal services. While attackers are known to have other targets (credit card numbers, personal information to be later used for identity theft, etc.), the impact of leaked credentials on overall organizational security is by far the most severe.

We already had different preventative measures in place for this kind of attack:

• Single sign-on through Azure Active Directory is preferred where supported
• LastPass is used as a password manager and to prevent password reuse
• Two-factor authentication is turned on wherever possible

And, in our information security training materials, we emphasize two main points:

• You should never be prompted to log in to Azure Active Directory while on a company owned device (since Seamless Single Sign-On is turned on)
• After clicking on a link in an e-mail, treat the page as suspicious, and do not enter credentials when prompted. Log in on a safe, known page instead, then try again. If the link still prompts for credentials, contact the Security Team.

While our training material also includes information on how to recognize phishing e-mails by content, it is important to understand that a well executed attack is extremely hard to distinguish from the real thing.

While in practice many phishing e-mails and landing pages look off somehow, there is nothing preventing an attacker from making a carbon copy of a real e-mail and landing page. The sender’s e-mail address and the URL of the landing page might be suspicious, or it might be perfectly reasonable - at times, the e-mail might be getting sent from a real (albeit compromised) account that belongs to a service or partner company.

Based on these premises, we decided to simulate attacks against the highest value credentials (including Azure Active Directory and LastPass), and craft e-mails and landing pages that could not be identified as suspicious based on their content.

To make this all work, we built a custom solution based on open-source tools such as Modlishka, a seamless reverse proxy that allows us to serve a slightly modified version of the real service as our landing page. This page is indistinguishable from the real service to the naked eye, allowing us to capture credentials protected by two-factor authentication (as it can be used to capture the full user session instead of just the credentials themselves). While this might sound like an advanced attack, note that this is an open-source tool available to attackers as well.

While we intentionally bypassed automated filters for these tests, during development we noticed that most of the messages got through them either way. This is probably due to the fact that their content was unique and the domains/IP addresses they were sent from had no prior reputation as being attacker controlled. While this is usually not the case for most attacks, it shows that a determined attacker has a good chance of bypassing this initial filter.

Attack showcase

So how does such a simulated attack look like from the user’s perspective? Whilst we’ve executed over 15 campaigns to date, we’ve selected to walk through at this point - each designed with a different level of difficulty in mind.

Security alerts

On the lower end of the difficulty spectrum are fake automated service messages. Most information security training materials warn us about them and users are significantly more likely to recognize them as suspicious. We took the security alert sent by Microsoft after failed login attempts, and changed some of the details to fit:

Messages such as these represent a common attack type. A keen observer might notice that this message is intended for Microsoft accounts - not Azure Active Directory accounts - and the domain from which the e-mail was sent from (hidden in the image above) is not one that is controlled by Microsoft. Otherwise, the message looks and feels just like the real one – and that’s because the underlying HTML is actually the same, with the links swapped out to drive traffic to our special landing site.

If the user does not notice that something is amiss, and clicks on the Review recent activity button, or the click here link below, a proxied clone of the Microsoft login page will be shown, which will capture credentials given the chance. Here’s what it looks like:

The login prompt requires users to enter their e-mail address as well as their password, triggering two-factor authentication and an approval request on the user’s device. This is indistinguishable from how the real login prompt works.

After a successful login, the user is redirected to a generic account management page housed on the real Microsoft portal. The portal has little to do with the promised recent activity page, so users who have gotten to this point have another chance to recognize the attack and make a report.

The vaccination campaign

A more sophisticated attacker might research and target a single company. The Vaccination campaign we ran was intended to simulate such an attack, though one disguised as an internal announcement sent by a trusted colleague.

We chose the sender by looking at the top results for Tresorit on LinkedIn, and selecting an employee that looked most likely to send the email based on indicated position. We then faked a firstname.lastname style e-mail address using a domain that at first glance might be mistaken for Tresorit, and signed the message as firstname. The content of the e-mail was based on current events, and was not company specific in any way. The e-mail was in English, but we added the Hungarian translation for general practitioner to the e-mail as an additional method of building trust in its content. All of this could have been done by a determined attacker with a few minutes of research.

The e-mail was text-only, without formatting or other HTML content. The only link was the one that led to our landing page - which would present a fake Microsoft login page. Take a look at how it played out:

Note the short loading animation before redirection that indicates this is a Microsoft Forms site. The user’s e-mail address is pre-filled, and the user is prompted to enter the password immediately. After a successful login, the user is redirected to a real form without an additional authentication login prompt. Most users who get to this point go on about their day and have no idea that their credentials have been compromised.

After the test

Despite some initial complaints, these tests eventually became a regular part of our company routine and even a source of amusement for some employees. Communication was key to achieving this effect. We made announcements after each test acknowledging the phishing test, and pointing out the different ways an e-mail could have been recognized as a phishing attempt. We never berated or made example of individual employees who failed the test, although at times we have required them to undergo additional training or to change passwords.

Test results were not made public and the data did not affect employee compensation and performance reviews. We believe it’s our duty to help prepare our employees to recognize these attacks, and to introduce technical countermeasures that protect us - a failed test is a collective failure, and a reminder of the need for constant vigilance.

Takeaways

In terms of results, we could draw the following conclusions from the data available to us:

• Over time, our company results improved. In one quarter, when we missed the company wide test (opting for a targeted test of high value targets instead), there was a measurable bounce-back in the failure rate, further reinforcing the conclusion that regular reminders have a positive effect.
• Easier campaigns (such as the security alert template demonstrated previously) had very low failure rates, which improved to near zero over time.
• Different departments had widely different failure rates. Software developers and other technical personnel did significantly better, but were not immune.

Of course, there is still a long way to go, and we are continuously looking to improve our scores. Nonetheless, we found these tests valuable tools for raising awareness of phishing attacks and a great complement to our existing technical training materials and measures.