Three Reasons Why the Browser is Best for Stopping Phishing Attacks

Phishing attacks remain a huge challenge for organizations in 2025. In fact, with attackers increasingly leveraging identity-based techniques over software exploits, phishing arguably poses a bigger threat than ever before.

Attackers are increasingly leveraging identity-based techniques over software exploits, with phishing and stolen credentials (a byproduct of phishing) now the primary cause of breaches. Source: Verizon DBIR

Attackers are increasingly leveraging identity-based techniques over software exploits, with phishing and stolen credentials (a byproduct of phishing) now the primary cause of breaches. Source: Verizon DBIR

Attackers are turning to identity attacks like phishing because they can achieve all of the same objectives as they would in a traditional endpoint or network attack, simply by logging into a victim’s account. And with organizations now using hundreds of internet apps across their workforce, the scope of accounts that can be phished or targeted with stolen credentials has grown exponentially.

With MFA-bypassing phishing kits the new normal, capable of phishing accounts protected by SMS, OTP, and push-based methods, detection controls are being put under constant pressure as prevention controls fall short.

Attackers are bypassing detection controls

The majority of phishing detection and control enforcement is focused on the email and network layer — typically at the Secure Email Gateway (SEG), Secure Web Gateway (SWG)/proxy, or both.

But attackers know this, and are taking steps to avoid these controls, by:

• Routinely evading IoC driven blocklists by dynamically rotating and updating commonly signatured elements like IPs, domains, and URLs.
• Preventing analysis of their phishing pages by implementing bot protection like CAPTCHA or Cloudflare Turnstile alongside other detection evasion methods.
• Changing visual and DOM elements on the page so that even when the page is loaded, detection signatures may fail to trigger.

Implementing bot checks like Clouflare Turnstile is an effective way to bypass sandbox analysis tools

And in fact, by launching multi- and cross-channel attacks, attackers are evading email-based controls entirely. Just see this recent example, where attackers impersonating Onfido delivered their phishing attack via malicious Google ads (aka malvertising) — bypassing email altogether.

Attackers are bypassing email by targeting their victims across IM, social media, using malicious ads, and by sending messages using trusted apps

It’s worth pointing out the limitations of email-based solutions here too. Email has some additional checks around the sender’s reputation and things like DMARC/DKIM, but these don’t actually identify malicious pages. Similarly, some modern email solutions are doing much deeper analysis of the content of an email. But… that doesn’t really help with identifying the phishing sites themselves (just indicates that one might be linked in the email). This is much more appropriate for BEC-style attacks where the goal is to social engineer the victim, as opposed to linking them to a malicious page. And this still doesn’t help with attacks launched over different mediums as we’ve highlighted above.

How browser-based detection and response can level the playing field

Most phishing attacks involve the delivery of a malicious link to a user. The user clicks the link and loads a malicious page. In the vast majority of cases, the malicious page is a login portal for a specific website, where the goal for the attacker is to steal the victim’s account.

These attacks are happening pretty much exclusively in the victim’s browser. So rather than building more email or network-based controls looking from the outside-in at phishing pages accessed in the browser, there’s a huge opportunity presented by building phishing detection and response capabilities inside the browser.

When we look at the history of detection and response, this makes a lot of sense. When endpoint attacks skyrocketed in the late 2000s / early 2010s, they took advantage of the fact that defenders were trying to detect malware with primarily network-based detections, signature-based analysis of files, and running files in sandboxes (which was reliably defeated with sandbox-aware malware and using things as simple as putting an execution delay in the code). But this gave way to EDR, which presented a better way of observing and intercepting malicious software in real-time.

EDR enabled real-time detection and response at the OS level rather than relying on traffic to and from the endpoint.

The key here was getting inside the data stream to be able to observe activity in real-time on the endpoint.

We’re in a similar position today. Modern phishing attacks are happening on web pages accessed via the browser, and the tools we’re relying on — email, network, even endpoint — don’t have the required visibility. They’re looking from the outside-in.

Current phishing detection isn’t in the right place to observe and stop malicious activity in real time.

But what if we could do detection and response from inside the browser? Here are three reasons why the browser is best for stopping phishing attacks:

#1: Analyze pages, not links

Common phishing detections rely on the analysis of links or static HTML as opposed to malicious pages. Modern phishing pages are no longer static HTML — like most other modern web pages, these are dynamic web apps rendered in the browser, with JavaScript dynamically rewriting the page and launching the malicious content. This means that most basic, static checks fail to identify the malicious content running on the page.

Without deeper analysis, you’re reliant on analyzing things like domains, URLs, and IP addresses against known-bad blocklists. But these are all highly disposable. Attackers are buying them in bulk, constantly taking over legitimate domains, and generally planning for the fact that they’ll get through a lot of them. Modern phishing architecture is also able to dynamically rotate and update the links served to visitors from a continually refreshed pool (so every person that clicks the link gets served a different URL) and even going as far as using things like one-time magic links (which also means that any security team members trying to investigate the page later won’t be able to do so).

Ultimately, this means that blocklists just aren’t that effective — because it’s trivial for attackers to change the indicators being used to create detections. If you think about the Pyramid of Pain, these indicators sit right at the bottom — the kind of thing we’ve been moving away from for years in the endpoint security world.

But in the browser, you can observe the rendered web page in all its glory. With much deeper visibility of the page (and its malicious elements) you can…

#2: Detect TTPs, not IoCs

Even where TTP-based detections are in play, they’re typically reliant on either piecing together network requests, or loading the page in a sandbox.

However, attackers are getting pretty good at evading sandbox analysis — simply by implementing bot protection by requiring user interaction with a CAPTCHA or Cloudflare Turnstile.

Implementing bot checks like Clouflare Turnstile is an effective way to bypass sandbox analysis tools

Even if you can get past Turnstile, then you’ll need to supply the correct URL parameters and headers, and execute JavaScript, to be served the malicious page. This means that a defender who knows the domain name can’t discover the malicious behavior just by making a simple HTTP(S) request to the domain.

And if all this wasn’t enough, they’re also obfuscating both visual and DOM elements to prevent signature-based detections from picking them up — so even if you can land on the page, there’s a high chance that your detections won’t trigger.

When using a proxy, you’ll have some visibility of the network traffic generated by a user accessing and interacting with a page. However, you’ll struggle to correlate key actions like whether the user entered their password with the specific tab when dealing with the sheer volume of disorganized network traffic data.

But you get much better visibility of all this in the browser, with access to:

• Full decrypted HTTP traffic — not just DNS and TCP/IP metadata
• Full user interaction tracing — every click, keystroke, or DOM change can be traced
• Full inspection at every layer of execution, not just initial HTML served
• Full access to browser APIs, to correlate with browser history, local storage, attached cookies, etc.

This gives you everything you need to build high-fidelity detections focused on page behavior and user interaction – that is much harder for attackers to get around when compared to IoC-based detections.

Being in the browser enables you to build much more effective controls based on TTPs

And with this new visibility, because you’re in the browser and seeing the page at the same time as the user is interacting with it, you can…

#3: Intercept in real time, not post mortem

For non-browser solutions, real-time phishing detection is basically nonexistent.

At best, your proxy-based solution might be able to detect malicious behavior via the network traffic generated by your user interacting with the page. But because of the complexity of reconstructing network requests post-TLS-encryption, this typically happens on a time delay and is not entirely reliable.

If a page is flagged, it usually requires further investigation by a security team to rule out any false positives and kick off an investigation. This can take hours at best, probably days. Then, once a page is identified as malicious and IoCs are created, it can take days or even weeks before the information is distributed, TI feeds are updated, and ingested into blocklists.

But in the browser, you’re observing the page in real-time, as the user sees it, from inside the browser. This is a game changer when it comes to not just detecting, but intercepting and shutting down attacks before a user is phished and the damage is done. This changes the focus from post-mortem containment and cleanup, to pre-compromise interception in real-time.

The future of phishing detection and response is browser-based

Push Security provides a browser-based identity security solution that intercepts phishing attacks as they happen — in employee browsers. Being in the browser delivers a lot of advantages when it comes to detecting and intercepting phishing attacks. You see the live webpage that the user sees, as they see it, meaning you have much better visibility of malicious elements running on the page. It also means that you can implement real-time controls that kick in when a malicious element is detected.

When a phishing attack hits a user with Push, regardless of the delivery channel, our 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, detecting that:

• The password the user is entering into the phishing site has been used to log into another site previously. This means that the password is being reused (bad) or the user is being phished (even worse).
• The web page is cloned from a legitimate login page that has been fingerprinted by Push.
• A phishing toolkit is running on the web page.

As a result, the user is blocked from interacting with the phishing site and prevented from continuing.

These are good examples of detections that are difficult (or impossible) for an attacker to evade — you can’t phish a victim if they can’t enter their credentials into your phishing site! Find out more about how Push detects and blocks phishing attacks here.

Push prevents users from accessing phishing pages when detected in the browser.

Learn more

It doesn’t stop there — Push provides comprehensive identity attack detection and response capabilities against techniques like credential stuffing, password spraying and session hijacking using stolen session tokens. You can also use Push to find and fix identity vulnerabilities across every app that your employees use like: ghost logins; SSO coverage gaps; MFA gaps; weak, breached and reused passwords; risky OAuth integrations; and more.

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 for a live demo — or register an account to try it for free. Check out our quick-start guide here.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.