Detecting and blocking phishing attacks in the browser

All phishing eventually leads to the browser

The best attack detection methods are those that focus on detecting indicators that are difficult for attackers to change or obfuscate. 

For a credential phishing attack to succeed, the victim has to enter their password into a webpage. There’s no two-ways about it, attackers cannot change this. 

So it stands to reason that, if you can detect this user behavior, and block them from entering their password, then you can stop phishing. 

This is exactly what Push does.

Most anti-phishing tools are easily bypassed

Other anti-phishing tools rely on detecting elements of the attack that attackers can change and hide, such as domains or the webpage contents. Attackers use tricks to evade these detection, like:

• Using Cloudflare Workers to block automatic analysis of their phishing site

• Hacking a Wordpress blog to get a reputable domain that passes domain checks 

• Using redirects and rotating the URLs delivered to the victim to bypass link analysis

• Randomizing the HTML title for the web page to bypass blocklists 

• One-time phishing links that only work the first time they are clicked

Push is putting an end to this game of cat and mouse, by keeping it really simple; you can’t phish someone who can’t put their password into a phishing page. 

Domain-binding passwords

If you’re familiar with how passkeys are domain-bound, then think of what Push does as domain-binding passwords. We pin the password to its legitimate domain(s) and then don’t allow it to be entered into any webpage on any other domain. 

But just because you’ve stopped your users from being phished doesn’t mean you don’t want to know when attackers are attempting to phish your users and how. 

Push still inspects webpages to see if attackers are rendering cloned app login pages in the browser or if known AitM and BitM toolkits are being used. This way you don’t lose visibility of the unsuccessful attacks that are targeting your users. Think of it as a handy second and third layer of defense.

Lets run through a quick before and after example:

Scenario 1: An attacker attempts to phish an employee that doesn’t have Push deployed to their browser.

Here, an attacker hacks a Wordpress blog to get a reputable domain and then runs a phishing toolkit on the webpage. They email one of your employees a link to it. Your SWG / email scanning solution inspects it in a sandbox but the phish kit detects this and redirects to a benign site so that it passes the inspection. 

Your user gets the email with the link and is now free to interact with the phishing page. They enter their credentials plus MFA code into the page and voila! The attacker steals them and is able to compromise the user’s account.  

Scenario 2: An attacker attempts to phish an employee that does have Push deployed to their browser. 

This time, the attacker uses the same phishing toolkit and domain from the first example. But in reality, they don’t have to send it to your employee using email, instead, they could use LinkedIn messenger, Slack, Teams, or any application that allows employees to communicate with each other. 

Like before, the user receives the link, opens it and starts to enter their credentials into the webpage. This time though, the Push browser extension inspects the webpage running in the user's browser. Push observes that the webpage is a login page and the user is entering their password into the page.

The first detection Push makes is checking that the password the user is entering matches the domain that password is pinned to. Since it doesn't match, based on this detection alone the user is automatically redirected to a blocking page. An important point to make here is that the password never leaves the user’s browser and the check is made using a shortened salted hash of the password.   

The second detection Push makes is that the rendered web app is using a cloned app login page. The third detection is that a phishing toolkit is running in the web app code. 

In this particular scenario these second and third detections serve as useful context for understanding the nature of the phishing attack. But both will still redirect to a blocking page if they are triggered in isolation of the other phishing detections. 

It’s a great feature to test out for yourself

You can try some of our anti-phishing controls in our demo site. The Push demo site features modules for testing some of our anti-phishing controls, simulating real-world phishing attacks without needing to visit an actual malicious site.

Here’s what to do: 

• Create a free account with Push by clicking the Try it free button in the top right of the screen. Once in the Push platform, you’ll be prompted to install the Push browser extension - this is what will detect and block the phishing pages. 

• Once you have the browser extension installed, go to https://idp.pushdemos.com. Here you’ll be asked to login to a simulated SSO page with a username and password. Use the email you use on your Push account (with your corporate domain) and then make up a password for the simulation, remember what the password is though because you’ll need it for step 4.

• Hit Login, this allows the Push browser extension to observe the login and fingerprint the simulated SSO password locally within the browser. 

• You’ll now see three phishing simulation options. Click on each and you can see the blocking pages that users will get redirected to upon each phishing detection being made.

• Head to the Push platform, open the Events table and you can see the events and alerts generated from clicking on phishing links and trying to enter your demo password into them. 

We don’t just stop phishing attacks

We also detect other identity-related attack techniques used to compromise user accounts. That includes credential stuffing, password spraying and session hijacking using stolen session tokens. If you want to learn more about how Push helps you to detect and defeat common identity attack techniques, book some time with one of our team.