Anti-Phishing Protection

Attack types

There are next types of attack:

Reverse Proxy (AiTM)

Phishing sites act as a proxy server between the user and the resource. Unlike static copies, their primary objective is not merely to replicate the site's appearance but to facilitate full, real-time interaction with the legitimate service.

• The attacker deploys a proxy (e.g., Evilginx) on a phishing domain.
• The user visits the phishing domain.
• The proxy server intercepts the request and gains full control over it, including the ability to read payloads.
• The proxy server modifies the request to make it appear as though it originated from the legitimate site (e.g., by rewriting the Origin header) and forwards it to the legitimate server.
• The legitimate server cannot distinguish that the request originated from a phishing server and responds as it would to a browser.

Since a phishing site of this type proxies and utilizes original client-side resources, it is possible to implement mechanisms that detect, restrict, or disrupt its proper functioning directly within the user's browser.

HTML Clone

Such attacks do not aim to fully replicate the functionality of the original resource. Their primary objective is to create a visually convincing copy of login pages or other key sections—sufficient to ensure the user fails to notice the deception and voluntarily enters their credentials.

• The attacker copies the HTML code of the original site, including all styles, typically stripping out the <script> tags.
• References to static resources (e.g., images, fonts, and stylesheets) are either left unchanged, causing the victim's browser to continue loading them from the legitimate site, or replaced with attacker-controlled URLs, allowing all resources to be hosted and served from the phishing infrastructure.
• Injects custom scripts to steal user data.
• Deploys this page on a phishing domain.

Since this type of phishing site is typically a static copy of the original site's HTML and CSS, opportunities to influence its behavior are significantly more limited. In most cases, the original client-side scripts are not used, meaning that changes made to the legitimate site's JavaScript code have little to no effect on the phishing copy.

Built From Scratch

Unlike HTML-cloning attacks, these phishing pages are built independently from the ground up and do not rely on code or assets taken directly from the legitimate site. Their objective is not to reproduce the original application accurately, but rather to create a convincing imitation that is sufficient to deceive users into submitting their credentials or other sensitive information.

Such sites are often the most difficult to detect and take down, as they do not rely on the infrastructure, code, or resources of the original site.

Detection

BotBye! employs two types of phishing site detection:

1. Active Detection

No integration is required for this.

As soon as you create a Project and specify your domain, BotBye! begins scanning existing and new domains to find ones similar to yours.

Once such a domain is found, BotBye! compares the content of your site with that of the potential phishing site and, if it finds them similar, marks the domain as phishing.

All the types of phishing sites listed above can be detected using this method.

2. Passive Detection

Client integration is required for this.

When a user visits a site with the client-side integration installed, BotBye! detects the origin from which it is currently running. In this way, phishing domains reveal themselves.

This is how reverse-proxy-based phishing sites are most frequently detected.

Catchers

Use Catchers to improve detection of attacks involving HTML-clone-based phishing sites.

Catchers are small, invisible HTML elements that you insert into your website's DOM. When a page loads a catcher, the browser attaches the page's Origin/Referer, so BotBye! learns which domain the page is actually running on. When attackers copy your HTML, there is a high probability that they capture the catchers as well — and the moment a catcher fires from a look-alike domain, that domain reveals itself.

There are two catcher variants, suited to the different ways attackers host a cloned page:

• PNG catcher. An invisible image loaded from your origin. It is the lightest option, but it only fires while the cloned page still references the image from your origin — that is, when the attacker leaves resource links pointing back at your site.
• SVG catcher. Embedded-resource. Built for the harder case: phishing sites that self-host every asset, so that no request would otherwise reach BotBye!. This catcher is delivered as an embedded resource that carries its own detection logic — even after the attacker downloads it and re-serves it from their own infrastructure, it still initiates the callback that reveals the hosting domain.

We recommend the SVG catcher: it covers both attackers who keep references to your origin and those who copy every resource onto their own infrastructure.

Beyond detection, catchers can optionally carry an active response. When a phishing environment is confirmed, this can warn visitors that they are on a fraudulent site and should leave immediately, and block outgoing requests from the page so that any credentials the user enters cannot be transmitted to the attacker.

Server Integration

To hide the BotBye domain in your Catchers, use a server integration. By default a Catcher loads its resource from the BotBye domain, which shows up in your page's source — an attacker cloning your HTML can spot it and strip the integration out. A server integration points the Catcher at your own domain and relays the request to BotBye, so the Catcher looks like just another same-origin asset of your site and is far harder to notice and remove.

To do this, you expose a few proxying endpoints on your own domain that forward the browser's Catcher requests to BotBye and return the response.

You can implement them on any stack. The exact endpoints depend on the Catcher you use, so follow the relevant server-side integration — it sets them up for you.

Phishing Site Takedown

Once a phishing site has been identified, several actions are taken to reduce its effectiveness and increase the likelihood of its removal:

• Report the domain to the registrar. Abuse reports can be submitted to the domain registrar responsible for the phishing domain. Registrars may suspend, lock, or revoke domains that are being used for phishing or other malicious activities.
• Report the site to the hosting provider and infrastructure services. Abuse reports can be sent to the hosting provider, CDN, reverse proxy provider, or other infrastructure operators involved in serving the phishing site. Depending on their policies and the evidence provided, these providers may suspend services or disable access to the phishing content.
• Report the site to browser reputation and security services. Submitting the phishing URL to services such as Google Safe Browsing, Microsoft Defender SmartScreen, and other threat intelligence platforms can result in browser warnings being displayed to users attempting to visit the site, significantly reducing the attack's effectiveness.
• Monitor and repeat the process as necessary. Attackers frequently migrate phishing sites between domains and hosting providers. Continuous monitoring and repeated reporting may therefore be required to maintain protection.

In addition to infrastructure-level takedown efforts, BotBye! client integration embedded within the application may take direct action when a phishing environment is detected:

• Notify the user that they are interacting with a suspected phishing site and advise them to leave the page immediately.
• Redirect the user to the legitimate website, reducing the likelihood of further interaction with the phishing page.
• Block network requests to prevent credentials, session tokens, or other user data from being transmitted to attacker-controlled infrastructure.

Bot&Fraud Detection Module Integration

In addition to preventive measures, we recommend protecting critical authentication endpoints with the Bot&Fraud Detection Module.

This provides both real-time protection against active phishing attacks and additional capabilities for identifying accounts potentially affected by phishing activity.

• Blocking requests originating from phishing sites. Requests submitted through known phishing infrastructure can be identified and blocked directly on the origin server, preventing attackers from completing authentication flows.
• Identifying potentially compromised accounts. When authentication activity originating from known phishing infrastructure is detected, the module can associate the event with the corresponding user account and record the relevant account identifiers. This information can then be used by your security team to identify potentially compromised accounts and perform appropriate remediation actions, such as enforcing password resets, temporarily restricting access, or requiring additional verification.

The module provides a Risk Scoring mechanism designed to mitigate Account Takeover (ATO) and Credential Stuffing attacks.

The system builds a behavioral profile for each user based on historical login patterns, including typical source locations, IP ranges, device characteristics, and other contextual signals. Each new authentication attempt is evaluated against this baseline to determine its risk level.

This is particularly effective in phishing-driven scenarios: once a user’s credentials have been exposed through a phishing site, attackers typically attempt to reuse them from different environments, devices, or networks. Such login attempts significantly deviate from the user’s normal behavior and are assigned a higher risk score.

When a high-risk authentication attempt is detected, the system can signal or block the login request, preventing unauthorized access even if valid credentials have been obtained through phishing.