Phishing attacks remain a major challenge for organizations in 2025. In fact, phishing undoubtedly poses an unprecedented threat, as attackers are increasingly leveraging identity-based techniques over software exploits.
 |
| Attackers are increasingly using identity-based techniques than software exploits, with phishing and stolen qualifications (by-products of phishing) being the main source of violations. Source: Verizon DBIR |
Attackers are increasingly using identity-based techniques than software exploits, with phishing and stolen qualifications (by-products of phishing) being the main source of violations. Source: Verizon DBIR
Attackers are turning to identity attacks like phishing. Because they can simply log in to the victim’s account and achieve all of the same objectives with traditional endpoints or network attacks. And with organizations currently using hundreds of internet apps throughout the workforce, the range of accounts that can fall into fish or targets with stolen credentials is growing exponentially.
The new normal, normal detection controls that allow phishing accounts protected by SMS, OTP, and push-based methods are exposed to constant pressure as preventive controls become lacking.
Attackers are bypassing detection controls
The majority of phishing detection and control enforcement focuses on the email and network layers. Typically, the focus is on Secure Mail Gateways (SEG), Secure Web Gateways (SWG)/Proxies, or both.
However, attackers know this and are taking steps to avoid these controls.
- Routinely avoid IOC-driven block lists by dynamically rotating and updating commonly signed elements such as IP, domain, and URLs.
- Prevent phishing pages from analysis by implementing bot protections such as Captcha and Cloudflare Turnstile along with other detection circumventions.
- You can change the visual and DOM elements on the page to cause the detection signature to fail to trigger even if the page is loading.
 |
| Implementing bot checks like Clouflare Turnstile is an effective way to bypass sandbox analysis tools |
In fact, by launching multi-channel and cross-channel attacks, the attacker is completely evading email-based control. Check out this recent example of an attacker impersonating Onfido performing a phishing attack via malicious Google Ads (also known as Malvertising) to completely bypass email.
 |
| Attackers are bypassing email targeting victims by using IM, social media, malicious ads, and using trusted apps to send messages |
Again, it is worth pointing out the limitations of email-based solutions. The email has some additional checks on the sender’s reputation and things like DMARC/DKIM, but these are not actually malicious page. Similarly, some modern email solutions are content Email. But…it really doesn’t help identify the phishing site itself (indicating it may be linked to an email). This is much better suited to BEC-style attacks, which aim to socially engineer victims rather than linking to malicious pages. And this, as highlighted above, is not yet useful for attacks launched in various media.
How browser-based detection and responses can level the arena
Most phishing attacks involve the delivery of malicious links to users. Users click on the link to load the malicious page. In the majority of cases, malicious pages are login portals for specific websites, and the attacker’s goal is to steal the victim’s account.
These attacks are almost exclusively carried out in the victim’s browser. Therefore, there is a great opportunity to be presented by building phishing detection and response capabilities rather than building more email or network-based controls visible from the outside on phishing pages accessed by browsers internal browser.
Looking at the history of detection and response, this makes a lot of sense. When endpoint attacks surged in the late 2000s/early 2010s, they took advantage of the fact that defenders were primarily trying to detect network-based detection, signature-based analysis of files, and detect malware running files in sandboxes (which were certainly defeated by sandbox awareness malware, and used something as simple as code execution delays). However, this gave way to EDR. 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 to get inside the data stream so that the endpoint could observe the activity in real time.
I am in a similar position today. Modern phishing attacks take place on web pages accessed through browsers, and the tools we rely on (email, networks, and even endpoints) do not have the visibility needed. They look out from outside.
 |
| Current phishing detections are not in the right place to observe and stop malicious activity in real time. |
But what if we could do detection and response from In the browser? Here are three best reasons why browsers can stop phishing attacks:
#1: Analyze the page, not the link
Common phishing detection relies on links or static HTML analysis, as opposed to malicious pages. The latest phishing pages are no longer static HTML. Like most other modern web pages, these are dynamic web apps rendered in the browser, and JavaScript dynamically rewrites the pages to launch malicious content. This means that most basic static checks cannot identify the malicious content being performed on the page.
Without a deeper analysis, it relies on analyses such as domains, URLs, IP addresses, and more for known bad block lists. But all of these are very disposable. Attackers buy them in bulk, always take over legitimate domains, and generally plan the fact that they will overcome many of them. Modern phishing architectures can also dynamically rotate and update visitors from a continuous refreshed pool (everyone clicking a link is provided with a different URL), and even use things like one-time magic links (this means that security team members trying to investigate the page can’t do it later).
Ultimately, this means that block listings aren’t that effective. This is because it is trivial for an attacker to modify the indicators used to create detections. When you think about the pyramids of pain, these indicators sit at the bottom. This is like I’ve been away for years in the world of endpoint security.
However, in a browser you can observe web pages rendered in all its glory. As the page (and its malicious elements) has much deeper visibility…
#2: Detect TTP instead of IOC
Even when TTP-based detection works, it usually relies on stitching together network requests or loading pages into a sandbox.
However, attackers are very good at avoiding sandbox analysis by simply implementing bot protection by requesting user interaction with Captcha or CloudFlare Turnstile.
|
| Implementing bot checks like Clouflare Turnstile is an effective way to bypass sandbox analysis tools |
Even if you can go through turnstyle, you will still need to provide the correct URL parameters and headers, and run javaScript to provide the malicious page. This means that a defender who knows the domain name cannot discover malicious behavior simply by creating a simple HTTP request on the domain.
And if all this isn’t enough, they obfuscate both the visual and DOM elements to prevent signature-based detection from picking up them. Therefore, even if you can land on a page, there is a high chance that the detection will not be triggered.
When using a proxy, there is visibility into the network traffic generated by users accessing and interacting with pages. However, when dealing with the vast amount of confused network traffic data, it is difficult to correlate important actions, such as whether a user has entered a password on a particular tab.
However, in the browser, all of these are much better visibility, and you can access:
- Fully decrypted HTTP traffic – not just DNS and TCP/IP metadata
- Complete User Interaction Trace – Traces with every click, keystroke or DOM change
- Not only is the first HTML provided, but it also provides a complete inspection at all layers of execution
- Full access to browser APIs that correlate with browser history, local storage, attached cookies, and more.
This gives you everything you need to build high fidelity detection focused on page behavior and user interaction. This is much more difficult for attackers to dodge when compared to IOC-based detection.
 |
| Being in a browser allows you to build much more effective controls based on TTPS |
And with this new visibility, you are in the browser and you are looking at the page at the same time that the user is interacting with it, so you can…
#3: Intercept in real time, not after death
For non-browser solutions, Real-time phishing detection is essentially not present.
At best, a proxy-based solution could be able to detect malicious behavior through network traffic generated by users interacting with pages. However, since rebuilding network requests is complicated, after TLS post encryption, this usually occurs with time delays and is not entirely reliable.
If a page is flagged, it usually requires further investigation by the security team, and begins the investigation by excluding false positive exclusions. This can take time At best, perhaps day. Then, once the page is identified as malicious and the IOC is created, it can be taken day Or even week The TI feed will be updated and taken into the block list before the information is distributed.
However, browsers observe pages in real time from within the browser, as users see them. This is a game changer in terms of not only detecting it, but intercepting and shutting down an attack before the user is phished and causing damage. This changes the focus from post-mortem containment and cleanup to real-time pre-interception adoption.
The future of phishing detection and response is browser-based
Push Security offers a browser-based identity security solution that intercepts phishing attacks in your employee’s browser. Being in a browser offers many advantages when it comes to detecting and intercepting phishing attacks. The live web page that the user is watching will be displayed. This means that there is much better visibility for 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 a push, regardless of the delivery channel, the browser extension inspects the web pages running in the user’s browser. Push observes that the web page is a login page and that the user has entered the password on the page and detects:
- The passwords that users enter on a phishing site have previously been used to log in to another site. This means that the password is being reused (bad) or that the user is being phished (even worse).
- The web page is cloned from a legitimate login page that has been fingerprinted by a push.
- The phishing toolkit is running on a web page.
As a result, users will be blocked and interacted with phishing sites prevents them from continuing.
These are good examples of detections that attackers find difficult (or impossible) to avoid. If they can’t enter qualifications on your phishing site, you won’t be able to fish the victim. Learn more about how push detects and blocks phishing attacks here.
 |
| Push prevents users from accessing the phishing page when it is detected in the browser. |
learn more
It won’t stop – Push provides comprehensive identity attack detection and response capabilities for techniques such as entitlement packing, password spraying, and session hijacking using stolen session tokens. You can also use Push to find and fix identity vulnerabilities in all apps that employees use: SSO coverage gap. MFA gap; passwords are weak, compromised and reused. Dangerous OAuth integration; More.
If you want to learn more about how Push can help you, try to help detect and defeat common identity attack techniques, book Live Demo time with one of your teams, or register an account to try it for free. See the quick start guide here.
