Why it’s time for phishing prevention to move beyond email

Most organizations today have invested in an email security solution of some description. But even the most premium tools have significant limitations when it comes to modern phishing attacks.

The data speaks for itself — phishing remains as big a problem as it ever was (if not bigger!) despite enormous investment in security products and training. In 2024, identity-based attack vectors involving a human element (phishing and stolen credentials) accounted for 80% of the initial access observed by Verizon, while 69% of organizations experienced a phishing incident in 2024 according to IDSA.

So, why are phishing attacks still so effective for attackers?

Modern phishing attacks are evading established controls

Let’s start with the lay of the land: What controls and capabilities do organizations typically rely on when it comes to blocking credential phishing?  

If you’re using an email security solution, you’re relying on the following core capabilities when it comes to detecting malicious phishing pages:

• Known-bad blocklists: Block users from accessing known-bad or unapproved domains/URLs, and block traffic from known-bad malicious IPs, using Threat Intelligence (TI) feeds.

• Malicious webpage detection: Inspect webpages by loading them in a sandbox to detect malicious elements.

This also applies to other solutions that rely on these capabilities, such as web-based content filtering (e.g. Google Safe Browsing), CASB, SASE, SWG, etc.

But, attackers are now using specific tactics, techniques, procedures (TTPs) and tooling designed to defeat these solutions.

Let’s look at where these controls are falling short.

The vast majority of phishing attacks today are executed using AitM phishing kits — otherwise known as “MFA bypass” kits.

These kits use dedicated tooling to act as a proxy between the target and a legitimate login portal for an application. This allows the target to log in successfully with a legitimate service they use and even continue to interact with it.

As it’s a proxy to the real application, the page will appear exactly as the user expects, because they are logging into the legitimate site – just taking a detour via the attacker’s device.

However, because the attacker is sitting in the middle of this connection, they are able to observe all interactions, intercept authentication material like credentials, MFA codes, and session tokens to take control of the authenticated session and gain control of the user account.

MFA was once widely regarded as the silver bullet for phishing (we all remember the Microsoft stat “MFA prevents over 99% of identity-based attacks”) but this is no longer the case.

Not only are these kits incredibly effective at bypassing other anti-phishing controls like MFA, attackers are building them specifically to evade common detection tooling and techniques.

Known-bad blocklists can’t keep up

The fundamental limitation with known-bad blocklists is that they focus on indicators that are easy for attackers to change, in turn making detections based on them easy to bypass.

Attackers have gotten pretty good at disguising and rotating these elements. In modern phishing attacks, every target can receive a unique email and link. Even just using a URL shortener can bypass this. It’s equivalent to a malware hash – trivial to change, and therefore not a great thing to pin your detections on. The kind of detection that sits right at the bottom of the Pyramid of Pain.

You could look at which IP address the user connects to, but these days it’s very simple for attackers to add a new IP to their cloud-hosted server. If a domain is flagged as known-bad, the attacker only has to register a new domain, or compromise a WordPress server on an already trusted domain.

Both of these things are happening on a massive scale as attackers pre-plan for the fact that their domains will be burned at some point. Attackers are more than happy to spend $10-$20 per new domain in the grand scheme of the potential proceeds of crime.

For example, recent examples of Adversary-in-the-Middle phishing kits including Tycoon, Nakedpages, Evilginx were seen to rotate the URLs they resolve to (from a continually refreshed pool of URLs), mask the HTTP Referer header to disguise suspicious redirects, and redirect to benign (legitimate) domains if anyone but the intended victims attempted to visit the page.

And in many cases, attackers are leveraging legitimate SaaS services to conduct their campaigns (sometimes even using email protection services themselves!) making it even harder to filter genuine from harmful links.

But there’s a bigger issue here – for defenders to know that a URL, IP, or domain name is bad, it needs to be reported first. When are things reported? Typically after being used in an attack — so unfortunately, someone always gets hurt.

Malicious webpage detections are failing

Attackers are using various tricks to prevent security tools and bots from reaching their phishing pages to analyse them.

Using legitimate services to host their domains is increasingly common, with services like Cloudflare Workers used for the initial gateway, and Cloudflare Turnstile to prevent security bots from advancing to the page.

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.

By changing the DOM structure, attackers are loading functionally equivalent pages that look very different under the hood.

They’re also randomizing page titles, dynamically decoding text, changing the size and name of image elements, using different favicons, blurring backgrounds, substituting logos, and more… all to defeat common detections.

With all this, it’s no surprise that defenders can’t keep up.

Historically, the industry has seen email security solutions and anti-phishing as the same thing. But it’s clear that email-based phishing protection isn’t really cutting it when it comes to modern credential phishing attacks (the most common and impactful phishing variant today).

This isn’t to say that email-based solutions have no value — far from it. But relying on email scanners to detect phishing pages as a single line of defense isn’t enough anymore.

The key to solving this problem is, put simply, building better controls. But to do this, we need to move away from email as being the primary (or often the only) place where phishing attacks can be stopped.

While email is the main delivery vector for phishing attacks (at least, according to the data we have, which comes primarily from email security solutions) it’s not the only one. Phishing links are increasingly delivered to victims over IM platforms, social media — and generally over the internet.

A better solution to the problem would therefore be able to follow the user across the sites they use, and see the actual phishing pages as the user sees them, as opposed to a sandbox (which, as we’ve discussed, attackers are well prepared for).

Is browser-based phishing protection the solution?

While we’ve been conditioned to think about phishing as something that happens over email, it’s actually the browser where most of the action happens, regardless of the initial delivery channel.

And while it’s tempting to view the delivery of a phishing link as the attack itself, the phish can’t succeed unless the victim enters their genuine credentials on the malicious page.

Push Security provides a browser-based identity security solution that stops phishing attacks where 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, 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.

There’s a clear difference when you compare a phishing attack with and without Push.

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 or 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 the authenticated session and takes over the user’s account.  

But with Push, 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, detecting 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.

• The rendered web app is using a cloned app login page.

• 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! 

If we look at the Pyramid of Pain again, we can see that these are much harder detections for attackers to get around, enabling earlier detection and interception of account takeover when compared to static, TI-driven blocklists — stopping attacks before anyone gets hurt.  

Test it out for yourself

You can try some of our anti-phishing controls for free. Sign up by hitting the ‘login’ button and creating a free account. Just follow the instructions here to get started.

We don’t just stop phishing attacks

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.

Sponsored and written by Push Security.