Beyond the Hook: A Technical Deep Dive into Modern Phishing Methodologies

A technical exploration of modern phishing tactics, from basic HTML pages to advanced MFA-bypassing techniques, with analysis of infrastructure setup and delivery methods used by phishers in 2025.

Introduction

In 2025, phishing is still the most prevalent kind of cyber attack on the planet. Indeed, 1.2% of the global email traffic is phishing. That's 3.4 billion emails each day, but only a low number results in a compromise since "only" 3% of employees would click on a malicious link. However, when they do, it can be disastrous for their company. 91% of cyber attacks start with a malicious email to a target. Considering that, we easily understand why phishing is still one of the favorite initial access vectors of threat actors.

At Quarkslab, our Adversary Simulation Team often conducts advanced phishing campaigns as part of our penetration tests and realistic training sessions we provide to our customers.

The objective of this blog post is to review methods used nowadays in phishing attempts. We take an offensive approach to the attacks, analyzing the techniques used and how malicious emails are delivered to their victims. We'll also look at the backbone of any phishing campaign, also known as the infrastructure. This technical review will solely focus on email phishing, excluding smishing, vishing and other forms of social engineering attacks.

Advanced Phishing Techniques

Place yourself in the shoes of an attacker. You want to compromise an organization, what would you do? Well, phishing, of course, After all it is the path of less resistance, but how?

In this section, we will see different approaches used in phishing campaigns to retrieve victim's credentials or even sessions. All of these methods come with their pros and cons.

The classic method

HTML page

Mentioning the classic HTML phishing page in advanced phishing techniques might be odd, but this one is probably the most used. This method consists in crafting an HTML page that mimics the appearance of a legitimate website. For example, Microsoft being the most impersonated company in phishing campaigns, phishers often copy their login page in order to steal victim's credentials.


Microsoft login page

The phisher only needs a page that looks like the original one, which means he can remove or disable any unnecessary elements. In the above example, we can disable all buttons except the "Next" button. The same applies to links.

💡 Custom redirects
Another option would be to redirect the user to a fake error page when they click on an undesired button. Try to trigger errors on the legitimate website and copy their design. Don't forget to adapt the text to match the new error.

Since we only want to keep the appearance, it is necessary to remove all JavaScript scripts, mainly because it could send HTTP requests to the original website, giving them a chance to detect our phishing page. Be careful, however, because nowadays, websites are dynamically generated in your browser, so you should only "dump" the desired page when it's fully loaded. As the screenshot below shows, the page source (left) and the loaded page (right) have different bodies.


Difference in <body> before and after page loading

On multi-step pages, such as Microsoft's, it could be interesting to retain certain animation effects to make the page look more authentic for the victim. On the example below, we can see an animation with dots, then the page changes to ask for the user's password. Keeping these familiar effects can contribute to lowering users' vigilance, as they give them the impression that their email is really being checked.


Transition between email and password prompt

Once the victim has sent their credentials, redirect them to a legitimate website or display an error page.

💡 No stepback
Instead of sending the form using a POST request, do it with JavaScript using fetch() or ajax, then redirect the user using window.location.replace(url). This will prevent them from using the Back button to return to our phishing page.

The tricky method

Browser-in-the-Browser

In 2022, a security researcher named mr.d0x (@mrd0x) introduced a technique called "Browser In The Browser (BITB) Attack". He started with a simple question: how to make the “Check the URL” advice less reliable? Indeed, the URL is often an excellent indicator of a website's legitimacy, as it cannot be spoofed. Furthermore, many websites offer users the option of authenticating themselves using a trusted third party such as Microsoft, Apple, Google or even GitHub.


Multiple third-party authenticators on Canva's login page

Clicking on “Continue with Google”, for example, brings up a pop-up window asking you to sign in with your Google account.


Sign in with Google pop-up window (source: mr.d0x)

And that's where the trick lies. The phisher can reproduce this behavior using only HTML, CSS and JavaScript. We could enhance the classic HTML phishing page by moving the login process from our unusual domain to a fake browser page with an apparently legitimate URL. The fake browser window is an iframe that can be dragged and dropped like a real window, making it even more realistic. This allows you to create a pretext that is uncorrelated to the credentials you wish to retrieve, simply by adding a "Connect with X" button.


BITB demo (source: mr.d0x)

Windows and MacOS models are available from mr.d0x repository. He even made light and dark themes for both OS that could be displayed according to victim's preferences.

💡 More than a fake browser
The initial proof-of-concept by mr.d0x showcases a fake browser being opened, but we can expand on this idea. A phisher could trick a user to enter their credentials into a fake SSL VPN client like FortiClient, for example.

Fake CAPTCHA

A clever phishing trick has been used by an APT group called Blind Eagle (APT-C-36) trying to deploy malware. This phishing technique poses as a fake Google reCAPTCHA challenge for human verification. However, instead of simply ticking a checkbox or selecting squares where something appears, it asks the users to do a combination of key presses.


Fake reCAPTCHA challenge (source: JohnHammond)

It relies on the victim not being aware of the keyboard shortcuts they are using. Under the hood, a script will fill the victim's clipboard with a PowerShell one-liner. The victim will follow instructions and open a "Run" menu. Then they will paste the malicious code and execute it, thinking they completed the CAPTCHA challenge. John Hammond (@_JohnHammond) released a POC based on this phishing trick that can be found on his repository. His version seems more legitimate than the one made by Blind Eagle. Also, he added a decoy HTA file that will execute the malicious code and display a fake error message to look less suspicious.

💡 Execution method
JH uses mshta for execution, but since we are running an arbitrary command, we can decide to use whatever we want to execute our payload. You basically have Remote Command Execution, the only limit is your imagination (and some detections).

The lazy method

Attacker-in-The-Middle

Calling this technique “lazy” is probably misleading, but it's one that requires less coding skill. Let me introduce you to a technique called “Adversary-in-the-Middle” or AITM. The concept is much the same as that of Man-in-The-Middle (MITM) attacks. The aim is to position yourself between the victim (or client) and the server, acting as a reverse proxy. The phisher configures its server to send a request to the legitimate website when a client connects, and sends him back the response. This process is totally transparent to the victim.


Transparent phishing with a reverse proxy (source: mrgretzky)

We won't need to write any HTML or CSS, as the page will be returned by the legitimate website and loaded by the victim's browser. To do so, we need to replace each domain we want to proxy on the fly in the requests sent by the client. We could use Evilginx 3.0, developed by Kuba Gretzky (@mrgretzky), as an AITM phishing tool. The most interesting part of this technique, as mentioned in the Evilginx repository, is that it allows us to capture not only credentials but also sessions (cookies, tokens, ...), thus bypassing MFA authentications.


Evilginx 3.3 CLI

Using Evilginx is fairly straightforward, and the full documentation can be found here, but here's a quick rundown. We deploy the statically compiled Go binary on an exposed host on the Internet. We create DNS records to point our phishing domain to our Evilginx instance, which will act as web and DNS server. Finally, we configure Evilginx using a configuration file in which we specify domains, listening interfaces and more (also doable from the CLI). That was for the network part, now we need to create "phishlets", which are configuration files to target specific websites, in order to obtain phishing links to send to our victim.

Phishlets are written in YAML and define how the reverse proxy should act for a specific target. For example, we can specify what domains to proxy using the proxy_hosts directive. We can also do on the fly string replacements using the sub_filters. Credentials and sessions to capture are defined respectively in auth_tokens and credentials directives by specifying the regex pattern to look for. The phishlet format is fully described here.

💡 Curated response
With phishlets, we can use the js_inject directive that instructs the reverse proxy to add custom JavaScript to the returned response. Being able to execute JavaScript in the victim's browser is a superpower, you can do a lot, from style modification to keylogging and even more.

Another tool that serves the same purpose and works in the same way (reverse proxy) is Modlishka, a tool created by Piotr Duszyński (@drk1wi). However, this tool isn't maintained as often as Evilginx. It also doesn't provide an easy way of capturing sessions authenticated with something else than cookies, like a JWT for example. But this can be overcome by developing your own plugin for Modlishka in Go.


Modlishka starting info

The hybrid method

Frameless Browser-in-the-Browser

We have already seen a number of techniques that are effective but have their drawbacks. Combining these techniques into a "hybrid" technique can actually increase their effectiveness and even "bypass" some indicators of phishing (IoP). Let me introduce "Frameless BITB", a technique utilizing a fake browser window containing a real proxified authentication page. It was developed by Wael Masri (@waelmas01). The idea behind this tool is simple: use the BITB technique with the fake URL but at the same time embed a real authentication page.

BITB uses iframes to load the phishing page, however this is detected and blocked by Microsoft, Google or other big names. To solve this problem, the BITB effect is achieved by replacing the elements of the original authentication page with custom HTML code. This way, there's no need to insert the page in an iframe, just use the magic of CSS. In the end, the user interacts with our page, which appears to be in the “background” using an unrelated URL and displays the original authentication page proxied by Evilginx, with heavy styling modifications such as the fake URL in the window. These elements reinforce the user's trust in our phishing page, giving them the impression that the whole process is legitimate.


Frameless BITB in action (source: Wael Masri)

A complete video that demonstrates the attack and explains the functioning is available on YouTube. Also, all the steps to reproduce this POC can be found in Wael's repository.

💡 BITB everything
This POC showcases the ability to create BIBT with Microsoft's login page. However this can be done with any other company. Some work is needed to develop the adequate templates.

The heavy method

noVNC

In this section, we will see some of the heavy techniques that can be used for phishing. But why do I call them heavy? Simply because they require more resources on the attacker side. So far, we've seen techniques that load phishing pages in the victim's browser, letting them do the heavy lifting. Now we will see techniques that force us to load pages ourselves and display them to victims.

One technique is to use noVNC. This has been detailed by mr.d0x (@mrd0x), the same security researcher that was behind the BITB technique. But according to him, the technique was mentioned even before in this article. Either way, the concept remains the same: host a web browser in kiosk mode and give access to it through web VNC. Since the victim is using our browser to authenticate, this effectively bypasses 2FA authentication as we can reuse its session by dumping the browser's profile. You have to keep in mind that you give VNC access to your instance, this means that the victim could try to escape the kiosk mode and access other parts of the remote machine. To prevent it, we need to harden as much as possible the VNC.

A great project named EvilnoVNC addresses the points mentioned above. Developed by Joel Gamez Molina (@JoelGMSec), a Red Team Cybersecurity Expert, it uses Docker containers to sandbox the browser and mitigates escape risks. This project has been presented at many conferences. Joel made it super easy to use, if you want to phish a Google account for example, run the command below.


EvilnoVNC running (source: JoelGMSec)

That's it. It will take care of spawning the container, opening the desired web page in a browser in kiosk mode and even setup the resolution according to victim's browser when setting dynamic instead of 1920x1080x24.


Victim's view when accessing the phishing page (source: JoelGMSec)

The victim's profile is saved under the "Downloads" folder, allowing to import it in your browser and navigate on the website with the freshly hijacked authenticated session.

💡 Keep me logged in
As Joel mentions in his blogpost, some session cookies can't be reused in another browser by importing them. This applies to Google and Microsoft for example. You'll need to keep the session "running" and not shutdown EvilnoVNC.

WebRTC

The heavy category includes phishing attacks, often referred to as "Browser-in-the-Middle" (BITM). Having placed a browser within a browser (BITB), then ourselves between the client and the website (AITM), we now place a browser between the client and the website (BITM) we're trying to phish. But how can we do this without giving the victim access to the remote machine? The answer is simple: by streaming the browser. The target doesn't need to interact directly with the browser - we can. In fact, the target's actions are replicated in the controlled browser, which means we have much more control over the user's input.

A stunning tool made by Forrest Kasler (@FKasler) and named CuddlePhish allows to perform this exact attack. He uses WebRTC, a technology specifically designed for features like screen sharing. The browser runs inside Xvfb (X virtual framebuffer), a X11 server often used for client testing, and is controlled using Puppeteer. This way, actions made by the target are proxified to the attacker browser, giving the illusion that what is displayed is the real web page.


CuddlePhish in action (source: FKasler)

CuddlePhish has an admin section that allows you to take multiple actions regarding the session. The phisher can redirect the user to a different page, take control over the browser, give back control to the victim and even grab cookies once the target is authenticated. The "Send payload" feature is convenient as it forces the download of an arbitrary file chose by the attacker in the victim's browser.


CuddlePhish admin panel

💡 STUNning fallback
As mentioned by Forrest in his blog post (and Troubleshooting section on the git repo), some networks might now allow STUN due to NAT restrictions. To overcome this issue, we can deploy or own TURN server, bind it to port 443 and add TLS using coTURN. By default it will accept STUN and TURN requests, so if STUN is blocked, CuddlePhish will fallback to TURN.

Comparison

We have seen many techniques that could be employed to phish targets. All of these techniques have their advantages but also some disadvantages. In this section we will review their pros and cons based on several criteria:

  • System Independent: The capability to work seamlessly across all major operating systems (Windows, MacOS, Linux), regardless of the target platform.
  • Scalable: The ability to simultaneously assess numerous targets while maintaining efficient resource utilization, preventing exponential increases in computational or infrastructure needs.
  • 2FA Bypass: The capability to bypass multi-factor authentication mechanisms including push notifications, SMS verification codes, and authenticator app-based tokens.
  • Realistic: The ability to mimic legitimate services and user interfaces, eliminating the familiar indicators often taught to targets.
  • Mobile Compatible: The capacity to maintain full functionality when accessed via mobile devices.

HTML page

  • Pros: HTML runs on all browsers and operating systems, while the backend can remain light on server resources, even for a massive number of targets. We retain total control over the visual elements, enabling perfect reproduction of the legitimate target application and, at the same time, great flexibility on any device. There are no direct connections between the phishing server and the legitimate application, reducing the risk of triggering a detection.

  • Cons: It is unable to handle 2FA mechanisms because it does not communicate with the legitimate service. Some clear indicators remain, such as the URL not corresponding to the real website, which is often an indicator looked for by targets. It's also worth remembering that it takes time to create and maintain a clean-looking page, as it is likely to evolve.

Browser-in-The-Browser

  • Pros: The realism is far superior to that of a simple HTML page, as we can spoof the entire URL bar. The user's attention is shifted from the main page to the simulated browser window. Resource and infrastructure requirements are low, with the same credentials logger as the HTML page, making it easy to manage a large number of targets at the same time.

  • Cons: This approach cannot handle 2FA mechanisms, as it does not communicate with the remote legitimate service. Window style can vary from one operating system to another, and even within the same operating system such as Linux, you can have different window styles depending on the desktop manager and its theme. As mobile devices do not use windows, this method is not supported on them.

Fake CAPTCHA

  • Pros: A simple HTTP server and an HTML page are all that's needed to implement this technique. The result of this method is the execution of a remote command on the target.

  • Cons: This method currently only works on Windows due to the key combination, making it platform-specific. Although there is no direct bypass of 2FA authentication, an attacker could use remote code execution to perform a session steal. The CAPTCHA shown to the target is unusual; no such challenge exists, which increases the chances of detection if the user is aware of it.

Attacker-in-The-Middle

  • Pros: No development is required to implement this technique effectively, as it acts as a reverse proxy between the victim and the remote application. Resource and infrastructure requirements are also low, as a single server can handle a large number of targets. It works on any device, making it totally platform-independent. By being positioned in the middle, all traffic passes through the attacker, who can relay the 2FA authentication phases and capture sessions, thus bypassing this security measure.

  • Cons: Advanced users can tell the difference between a legitimate domain and one used by a phisher.

Frameless BITB

  • Pros: This technique is an improvement on the classic BITB method, of which it retains all the advantages. The additional advantage over the original method is the ability to bypass 2FA.

  • Cons: This technique keeps the same disadvantages as the original one. The window style can mismatch the target environment, thus being an indicator of phishing. This technique is reserved to desktop devices because mobile devices don't use windows.

noVNC

  • Pros: The victim authenticates directly into the phisher's browser via their own browser, storing the session on the attacker's side. This method works on any device, as it can adapt the browser resolution before rendering the page. This also applies to mobile devices.

  • Cons: This technique allows the user to access not only the browser, but also the entire machine if it is not sufficiently hardened, increasing the risk of compromise if the user finds a breakthrough. As it requires full access to the machine, only one target can be phished per instance, meaning that resource requirements increase rapidly as the number of targets grows. The URL will be different from the original, leaving a known phishing indicator for aware victims.

WebRTC

  • Pros: The victim authenticates directly into the phisher's browser via a video stream. This effectively bypasses 2FA, since the session is stored in the attacker's browser. All devices can be supported, including mobile devices.

  • Cons: There may be display problems for slow connections, making the web page look suspicious due to its blurred appearance. The URL does not match the original domain. Although this method is scalable, resource requirements will increase rapidly as it generates one dockerized browser instance per victim.

Summary

Method System Independent Scalable 2FA Bypass Realistic Mobile Compatible
HTML page ✅ ✅ ❌ ⚠️ (URL mismatch) ✅
Browser-in-The-Browser ⚠️ (Window style mismatch) ✅ ❌ ✅ ❌
Fake CAPTCHA ❌ ✅ ⚠️ (Command execution) ❌ ❌
Attacker-in-The-Middle ✅ ✅ ✅ ⚠️ (URL mismatch) ✅
Frameless BITB ⚠️ (Window style mismatch) ✅ ✅ ✅ ❌
noVNC ✅ ❌ ✅ ⚠️ (URL mismatch) ✅
WebRTC ✅ ⚠️ (Virtual framebuffer) ✅ ⚠️ (URL mismatch) ✅


✅ : Fully | ⚠️ : Partially | ❌ : Not

Phishing Infrastructure

When a fisher goes out to sea to fish, he needs a reliable, resistant boat in which he can trust to carry out his mission. The same goes for a phisher going out on an operation: he needs a robust infrastructure that meets his needs. In this section, we'll take a look at what these needs are, and how they can be met.

Hosting

The minimum required to run a phishing campaign may be a simple VPS in the cloud, with very low technical specifications such as 1 vCPU and 2 GB of RAM. We'll also need a public IP address to which the targets can connect. That's almost all it takes to execute any of the above techniques. However, for a cleaner approach, where we want to divide up each service and handle sensitive data properly, the infrastructure schema may look different.

First, as mentioned, we will handle sensitive data such as valid sessions cookies or cleartext credentials. To reduce the risk of this data being compromised by someone other than yourself, it's important to store it not on the VPS, but on a machine to which you have full access. Even if this server is hardened, it is still exposed on the Internet and can potentially be compromised via vulnerabilities that are not publicly known, leading to severe information leaks. The good practice would be to setup an exposed reverse proxy that will forward requests to internal on-prem services. These local services are often composed of the phishing tool, an SMTP server and other useful applications which we will detail later.


Reverse proxy exposed only

Secondly, we must chose one or multiple domain names that will match the pretext. For this part, several options are available to you: register a new domain, register an expired domain, use trusted domains.

Registering a new domain, that matches perfectly the pretext, luring victims to take the bait without any doubt, sounds tempting. But beware, the "age" of a domain is a key aspect regarding phishing detection. New domains, recently registered, that haven't been seen already on the Internet can make your phishing more suspicious. Domains need some time and requests to be categorized. Indeed, a good categorization of your domains will decrease the chances of falling the the spams or being blocked by company's proxies. Here is a list to check your domain's categorization:

If you want to skip the categorization part, you can instead register an expired domain that has already acquired a categorization. The best way to find such a domain is using ExpiredDomains.net. This website lists all expired domains and lets you search for them using advanced filters. You can even create a watch list with specific criteria and receive e-mail alerts when a domain drops. Be sure to check the domain reputation because some might already be categorized as "phishing domain".


ExpiredDomains.net main page


Advanced filter search on ExpiredDomains.net

Can't find a good expired domain or having issues categorizing your new domain ? Let's borrow a trusted domain. The idea is quite simple: use cloud services to get a domain name. Indeed, when creating a VM on Azure for example, it will also affect a public IP address. Azure lets you set a custom sub-domain name to one of their domains. Below, we decided to add "auth" as a subdomain, eventually to be used to lure a victim into giving their Azure credentials for a scenario where it's the target.


DNS name configuration for a public IP address in Azure

The end result is you having a subdomain auth.francecentral.cloudapp.azure.com that resolves to your VM.


DNS resolution to phisher's VM

At the same time, this subdomain benefits from the reputation of the Microsoft Azure domain name. It passes all the checks we've performed using the list provided above. Of course, other major cloud providers such as Amazon Web Services (AWS) and Google Cloud Platform (GCP) can be used to achieve the same results.


Good categorization and reputation across multiple checks

💡 Bad punycode
Punycode is a technique long used to fool humans by presenting them with a URL that looks very similar to the original. For example, a phisher might register the domain аррӏе.com that looks just like apple.com. If you haven't noticed, all the letters forming apple have been replaced by unicode characters that look similar. However, your browser will instead display xn--80ak6aa92e.com in the URL bar. Nowadays, this technique is also detected by e-mail providers, and incoming e-mails are almost always marked as spam.

Orchestration

Orchestration is defined here as the coordination between different elements to produce a desired effect. We can see the orchestration as the brain of the infrastructure, the central point. While there are no perfect tools to fulfill this role, I found Gophish being the best candidate. Gophish describes itself as "an open-source phishing toolkit designed for businesses and penetration testers". Indeed, it has several nice features and is easy to deploy, making it the phisher's dashboard.

Gophish allows you to manage multiple campaigns at the same time. Each campaign is a set of configurations that contains the launch data, the phishing URL, the group of people to target and more. Basically, you can create "Groups" of people described by their first name, last name, email and position and then affect those groups to campaigns.

You can also set up “Sending Profiles”, which are in fact identities used as senders in campaigns. The From field can be personalized to match your pretext. Sending Profiles allow you to connect to an SMTP relay or server using given credentials (or anonymously) and use it to send emails. A cool feature is the ability to check if the campaign will properly land by sending a test email.

Gophish allows user to create Email and Landing page templates directly in the browser and then import them. Some placeholders can be used in templates like the name or the email address of the person, making customized emails more convincing for the target. The Landing page can be empty and specify a different URL when creating the email template. This way Gophish can be used to send and track campaign results while still employing other phishing techniques


Gophish campaign tracking page

The typical flow to create a phishing campaign is the following: 1. Add or import groups of targets 2. Create or import an email template 3. Create a landing page (applies only for the classic HTML page) 4. Create a sending profile and test to send an email 5. Create and schedule a campaign 6. Profit

💡 Seamless integration
Kuba Gretzky has created a Gophish fork that integrates with his Evilginx tool. This allows phishers to benefit from the 2FA bypass offered by Evilginx, while retaining the campaign management and tracking features offered by Gophish. You can even use the placeholders present in the Gophish template with Evilginx's js_inject functionality, which lets you inject custom JavaScript into proxied responses.

Protection

Setting up an infrastructure behind a reverse proxy redirector is a good starting point, but it's not sufficient. We need to harden it more. The aim is to control as much as possible who is visiting your phishing pages because the link will be in the email you send to your target. Before it reaches the intended recipient, it will be analyzed several times by various detection mechanisms such as sandboxes, which try to catch unwanted emails before they reach the inbox. Phisher can employ same methods as legitimate website to protect his page against bots and undesired accesses.

A basic protection that can be implemented at the reverse proxy level is a whitelist of visitors based on their user agent and IP address. This can be achieved using the Nginx configuration.

You can make a (case-insensitive) match on the user-agent using the ~* operator as in the example below. This will block any visitor containing "googlebot", "curl" or "python" in their user-agent. We can also do the opposite and authorize only certain user-agents identified as those used by the target. In the example below, if the target doesn't use Firefox, Chrome or Safari, it will be blocked.

location / {
    # if contains one of the following, block
    if ($http_user_agent ~* "googlebot|curl|python") { 
        return 403; 
    }

    # if doesn't contain one of the following, block
    if ($http_user_agent !~* "gecko|chrome|applewebkit") {
        return 403;
    }
}

To allow or block requests coming from specific IP addresses, we can use the ngx_http_access_module from Nginx. For example, if you only want to allow connections made from France, you can add this list to your Nginx configuration as shown below.

location / {
    allow 1.179.112.0/20;
    allow 2.3.0.0/16;
    allow 2.4.0.0/14;
    [...]
    deny all;
}

These protections are very basic, as they can be easily bypassed by modifying the user agent and using a proxy for requests. To improve upon this, we can use external providers to help us fight against bots. For instance, the phisher can front his page with Cloudflare. A free tier is available with great features such as an SSL certificate (more trusted than LetsEncrypt which is often abused), Web Application Firewall and simple bots mitigation. By activating the "Under Attack Mode", Cloudflare displays an interstitial page with its alternative CAPTCHA Turnstile solution, forcing the user to resolve it before continuing.


Web page protected with "Under Attack Mode"

Another option is to use Google reCAPTCHA and set up your own page that will redirect the user to the final page if they pass the challenge. A good approach is to mimic Google's famous “Unusual Traffic” page. Users may be familiar with this simple page which sometimes appears, increasing confidence in the lure.


Fake Google unusual traffic page

If, as a phisher, we follow this path and start building our own redirection mechanism to allow specific users to access the page, we'll have no limits in terms of granularity. For example, we could allow the target to access the phishing page only once, with any further attempts blocked. Or, without being so restrictive, allow access to the page only to identified visitors who are not bots. One solution is to use Fingerprint, a script that collects indicators and evaluates them using “Smart Signals”. In this way, we could authorize access to the page to the first human visitor, while associating the identifier generated by Fingerprint with a unique identifier inserted in the URL. Another visitor attempting to access the same URL would be blocked, as the two identifiers would not match.


Unique identifier generated by Fingerprint

💡 Smart Signals
Fingerprint not only assigns a unique identifier or detects bots, but also analyze browser data to obtain a precise profile of the visitor. In this way, Fingerprint can detect several interesting pieces of information that can help determine whether or not a visitor is a valid target:

  • Virtual Machine
  • Emulated Android device
  • Incognito mode
  • User-Agent spoofing

Delivery Methods

Now that we've seen how a phisher can set up and secure his infrastructure, let's take a closer look at how he manages to sneak in malicious email to the target's inbox. This section will look at the different ways a phisher can send phishing emails that look convincing, leading the target to click on the link and be deceived.

Sender

Of course, as a phisher, we could spend time setting up an SMTP server, hardening its configuration and make it gain in trust on the Internet. However, this approach requires time and can still be unsuccessful sometimes. To bypass reputation filters and achieve high deliverability, attackers often decide to turn to well-known solutions already in place and ready to use.

Why spend time setting up an SMTP relay server when there are so many that could be used on the Internet? One reason could be to actually spoof target's domain. It is a strategy that consists of usurping the target's domain if it missing some DNS records. A great tool to detect this kind of misconfiguration is Spoofy. It checks DNS records and tells you whether a domain is spoofable based on the responses. You can also refer to this table to know if a domain is spoofable or not. If it is, there's a good chance that your malicious email will land in the victim's inbox, if you send it pretending to come from the same domain.


Spoofable domain identified by Spoofy

Otherwise, we could exploit some open or misconfigured STMP servers available on the Internet. This is exactly what phishers do. They exploit the fact that servers can be misconfigured, without proper authentication for example, to send their campaign using them. It is worth mentioning that these servers could have already been utilized during previous campaigns and so their reputation could be affected.

To overcome this problem, we can turn to third-party marketing and mailing services such as Mailchimp, Mailjet or SendGrid. These platforms are often abused because they provide trusted sending infrastructure that phishers can pair with their own carefully chosen domains. Additionally, these services provide useful features to attackers such as the ability to track if the email has been correctly delivered. Most of third-party mailing services offer a free tier that allows you to send around thousands of emails per month, below is a free tier comparison table:

Platform Emails per day Emails per month Number of contacts
SendGrid 100 3000 ∞
Mailjet 200 6000 1500
Mailchimp 500 1000 500
Brevo ∞ 9000 2000
Sender ∞ 15000 2500

Cloud service providers have become another attractive vector for phishers, as they offer e-mail services with trusted infrastructures. For example, Microsoft Entra ID (Azure) provides domains in the format <tenant>.onmicrosoft.com, which can be particularly effective for social engineering. Because these emails originate from Microsoft's infrastructure, they automatically appear more trustworthy and are more likely to land in the inbox. When people see a Microsoft domain in the sender's address, they are more inclined to let their guard down and trust the content of the e-mail. We could, for example, impersonate the Microsoft support team by creating the tenant "helpcenter" and naming our user "support", which would lead our target to believe that this is an authoritative e-mail.


Fake Microsoft Support account

Want even more confidence? Business Email Compromise (BEC) takes phishing to a whole new level. Instead of creating fake accounts or spoofing identities, phishers use access to legitimate corporate email accounts they've already compromised through phishing or brute force attacks. When used for internal phishing, these emails are guaranteed to reach your final inbox with an extremely high level of trust. Even when targeting external users, these compromised accounts benefit from the company's established reputation, existing relationships and legitimate domain name, guaranteeing that their emails will reach the target's inbox.

💡 Phish to phish
A stealth approach for a phisher wishing to achieve an objective would be to first phish a more vulnerable, less aware target. Then, using the victim's account, he can reach targets who are more conscious of external attacks but are not suspicious of emails from their internal collaborators. What makes this technique particularly dangerous is the quantity of phishing indicators suppressed, as long as the pretext doesn't betray you.

Although not new, the abuse of contact forms has resurfaced and is trendier than ever. Phishers use these forms in two ways: either when the contact form is submitted, the specified e-mail address receives a copy of the message, or the message is received only by the company that is the phishing target. In both cases, the attacker abuses a legitimate service to send malicious links to his targets. Interestingly, the chances of the message being delivered are very high, and there is probably no limit to the number of messages the phisher wishes to send.

Email appearance

We've seen how to deliver the e-mail to the target and how to maximize the chances of it arriving in the inbox rather than in the spam folder. In the scenario where the target hasn't noticed or has been convinced that the sender is legitimate, they now need to be convinced by the appearance of the e-mail. We'll have to exploit several biases to encourage the victim to continue thinking that everything is authentic.

A phisher will copy the e-mail layout to start exploiting “visual familiarity”. As humans, we're susceptible to the "mere-exposure effect", a bias described by the fact that we develop natural preferences for things we've seen before. Attackers naturally rely on this effect when designing their e-mails, as it automatically triggers a positive first response from the target. The layout can consist of a logo, title, subtitle, text, images and footer. These are common elements found in most automated e-mails, such as those sent by Microsoft or DocuSign. Recently, the latter has been used in many themed phishing campaigns, reproducing the same e-mail when someone shares a document with you.


DocuSign-themed phishing email (source: Kaspersky)

Brand impersonation works by trying to reproduce certain patterns and details often seen and recognized by the potential victim. Phishers exploit this consistency bias by meeting certain expectations that the target has developed over time. For example, the screenshot above of a phishing email repeats certain key elements of the email below, which is a legitimate email received from DocuSign (graphical elements have been updated recently). The structure is the same: an icon centered in a colored banner with an action to be taken and a button, then below it the document sender and his message, and finally a classic footer with information and instructions.


Original DocuSign email

💡 HTML logo
Images, and especially company logos, are used to impersonate brands and enhance the credibility of emails. However, most email clients block remote content or base64-encoded images. One way of getting around this restriction and keeping the benefits of images is to recreate the logo using HTML and CSS only. For example, this gist can be used to create a Microsoft logo. Keep in mind CSS compatibility between different email providers and clients, It is therefore always advisable to check rendering in an environment identical to that of the target.

Our perception of the legitimacy of an e-mail can also be altered by authority bias, as we tend to question authority figures less. As a general rule, an e-mail from a manager or equivalent, bearing the same signature as the original e-mail, will be more convincing and leave less room for the target to reflect on the legitimacy of the action. The same behavior can occur in the case of a pseudo-IT administrator asking you to “change your password in accordance with the new policy”, since it is presented as being for your "security" and that you will comply.

Finally, phishers will try to exert pressure to obtain a quicker response, again reducing your thinking time and possibly leading to an action you initially didn't intend. This is referred to as the "urgency bias". Even tho this bias is often expressed in written form through the pretext, visual aspects can help reinforce the effect. For instance, if we take the previous example of the pseudo-IT administrator, the email contains some directive instructions, a due date and consequences if the action isn't performed. All these elements will be highlighted in bold or colored text. Font can also be precisely chosen to draw attention. Below is a simple example of pretext with highlighted elements to abuse the urgency bias:


Phishing email that employs several bias

Link

The link is the final element that needs to be carefully crafted. In this section, we'll explore different techniques used by phishers to make their malicious links appear more trustworthy and bypass security measures like email filters.

URL shorteners are services that take a long URL and create a shorter version. While these services were initially created to make sharing links easier, especially on platforms with character limits, they are now frequently abused in phishing campaigns. Popular URL shorteners with a free plan include Bitly, T.ly, Rebrandly (or free version), Short.io, Cutt.ly.

These services provide several key advantages for phishing campaigns. The primary benefit is the ability to use trusted domains with high reputation scores (tested with the categorization tools mentioned earlier) while maintaining short, clean-looking URLs. Many services also offer custom subdomain and path features, allowing phishers to create links that perfectly align with their pretext, such as:

The combination of a reputable domain and a carefully crafted path makes these shortened URLs particularly effective in phishing campaigns. When a target sees a familiar shortener domain followed by relevant keywords, they may be more inclined to trust the link.

Cross-Site Scripting (XSS) and Open Redirect vulnerabilities represent a significant opportunity for phishers. These vulnerabilities occur when a website accepts user-controlled input that specifies a URL to which the user will be redirected without proper validation. Attackers exploit these vulnerabilities to make their malicious links appear legitimate by leveraging trusted domains.

This technique is particularly effective because the initial domain is legitimate and trusted, creating an immediate sense of security for the victim. The redirect happens automatically, giving users little time to notice the change in domain as they're seamlessly transferred to the malicious site. Most users have been conditioned to check only the beginning of a URL for legitimacy, making open redirects an especially deceptive method.

Let's take a concrete example. Security researcher Jip (@jipisback) shared recently on X a way to abuse YouTube's redirect functionality. Here are the steps described in its post:

  1. Find any YouTube video with external links in its description
  2. Copy the redirect URL, which should look like: https://www.youtube.com/redirect?event=video_description&redir_token=TOKEN&q=URL&v=VIDEO_ID
  3. Modify the q parameter to point to your site
  4. Profit

We made an example that redirects to Quarkslab's website: link

https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbmhkMTluUmZ4VVhPMk84TXdjTDN1NEFaVFhnZ3xBQ3Jtc0tsRkdrdlR5djhhSk1Uc3JxcFUzcXpETzkxT2dUWnFIOGpsYmExR3lDWHB6Q0ZMNFVhbllLYnM2WERDbFpOSDNmZmdkTkVBa0VFQnhsM2taWDZSMVlaUEJyZTZaY1JxaGpDMk1kdTk2X2IzNllIcHZ2Yw&q=https%253A%252F%252Fwww%252Equarkslab%252Ecom%252Fpentest%252Dproactive%252Dthreat%252Dmitigation%252F

💡 Redirection chain
When exploiting open redirect vulnerabilities, use a URL shortener as the redirect destination rather than your actual phishing domain. This technique provides two key benefits: it prevents the vulnerable application from logging your actual phishing domain and it adds another layer of obfuscation that makes it harder for users to detect the phish.

Cloud providers offer attackers a powerful way of creating legitimate-looking URLs that can bypass security solutions and fool even phishing-aware users. These platforms provide trusted domains that inherit the reputation of major technology companies. Below is a table containing a non-exhaustive list of services that can be used for malicious purposes, such as phishing.

Provider Service Domain Format Use Case
Microsoft Azure Virtual Machines [custom].[region].cloudapp.azure.com Host phishing infrastructure with custom subdomain
App Service [appname].azurewebsites.net Deploy full web applications with Microsoft domain
Blob Storage [accountname].blob.core.windows.net Host static phishing pages
Azure Front Door [name].azurefd.net CDN with SSL for phishing content
Azure Functions [appname].azurewebsites.net/api/[function] Serverless redirectors or API endpoints
Microsoft 365 [tenant].onmicrosoft.com Send phishing emails from Microsoft domains
Amazon AWS EC2 ec2-[IP-with-dashes].compute-1.amazonaws.com Host phishing infrastructure
S3 Buckets [bucketname].s3.amazonaws.com Host static phishing content
CloudFront [distribution-id].cloudfront.net CDN with SSL certificates
Lambda URL [id].lambda-url.[region].on.aws Serverless functions as redirectors
Google Cloud App Engine [project-id].appspot.com Deploy full web applications
Cloud Storage storage.googleapis.com/[bucket] Host static phishing content
Cloudflare Pages [project].pages.dev Host static phishing sites
Workers [subdomain].[worker-name].workers.dev Serverless functions for redirects

Cloud-provided domains have become perfect phishing tools, featuring trusted brand names like Microsoft, Amazon, and Google that easily pass security checks. These domains come with trusted SSL certificates and security solutions rarely block them because they host legitimate business traffic. They're typically categorized as "Business/Technology" rather than "Suspicious". While cloud providers do attempt to prevent abuse by shutting down suspicious sites, attackers can often operate undetected long enough to execute their campaigns.

For example, a domain like auth.francecentral.cloudapp.azure.com (mentioned earlier in the Hosting section) should pass all security checks while appearing legitimate to users who recognize "Azure" as a Microsoft product.

Conclusion

The landscape of phishing has transformed significantly, moving beyond simple HTML pages to advanced techniques like Browser-in-The-Browser (BITB), Attacker-in-The-Middle (AITM), and WebRTC-based approaches. Some methods are even combined to create more powerful ones like Frameless BITB. These methods demonstrate increasing sophistication in bypassing multi-factor authentication and creating convincing user experiences.

Meanwhile, infrastructure improvements leveraging cloud provider domains and sophisticated delivery methods make malicious emails increasingly difficult to detect. In 2024, according to Fortra, there was a 104% increase in Cloudflare Workers abuse and a 198% increase in Cloudflare Pages abuse. But they are aware of these abuses and are trying to respond as quickly as possible.

With the emergence of AI, attackers have ever more powerful tools at their disposal to create ever more convincing campaigns. However, this technology can also be employed by defenders to detect phishing attempts by identifying subtle indicators of phishing that humans might miss.

Effective defense against phishing requires a multi-layered approach combining technical controls and human awareness. Organizations need to implement advanced email filtering, endpoint protection and network monitoring, while keeping security teams and employees informed of new phishing techniques.

Bibliography

If you would like to learn more about our security audits and explore how we can help you, get in touch with us!