Bypassing OTP with Evilginx2 & Zphisher

evilginx -p ./phishlets/ -c config.yaml

Executive Summary: The Evolution of the Phish

For years, the cybersecurity industry held a fundamental belief: Multi-Factor Authentication (MFA) was the silver bullet against phishing. The logic was sound. If an attacker stole your password via a perfectly cloned login site, they still couldn't access your account without the six-digit code from your phone. This forced adversaries to shift tactics, moving away from simple credential harvesting toward complex malware delivery.

However, the offensive security community adapted. The modern threat landscape, heavily documented in repositories like GitHub, is now flooded with next-generation tools specifically engineered to neutralize MFA. The most devastating evolution in this space is the Adversary-in-the-Middle (AiTM) phishing proxy. At the vanguard of this new paradigm is Evilginx2, an open-source tool that serves as the apex predator of credential harvesting. This guide provides a deep technical analysis of how AiTM proxies fundamentally break traditional MFA, how tools like Evilginx2 are deployed, and the critical paradigm shift required to defend against them.

The Limitations of Traditional Cloning (Zphisher)

Before dissecting AiTM architectures, it is crucial to understand why traditional phishing tools are now considered legacy in the face of enterprise MFA. Tools like Zphisher represent the old guard of social engineering.

Zphisher is an automated bash script that provides dozens of pre-built, perfectly cloned login pages for platforms like Instagram, Facebook, Google, and Microsoft.

• The Execution: It uses tunneling services like Ngrok or Cloudflared to instantly generate a public URL that forwards external web traffic to the local cloned page hosted on the attacker's machine.
• The Flaw: Zphisher, SEToolkit, and Gophish are static credential harvesters. When a victim submits their password, the tool simply saves it to a text file. If the account requires a Time-Based One Time Password (TOTP) from Google Authenticator, or an SMS code, the static password is mathematically insufficient to gain access. The attacker hits a wall. While they could quickly build a second page asking for the 2FA code, they would then have to manually log in to the real site before the 30-second code expires—a highly impractical, unscalable approach.

The AiTM Paradigm: Demystifying Evilginx2

Created by Kuba Gretzky, Evilginx2 is fundamentally different from Zphisher. It is not a web server hosting fake HTML pages; it is a specialized, highly configurable reverse proxy framework written in Go.

Instead of showing the victim a fake copy of a website, Evilginx2 sits dynamically between the victim and the actual website. It forwards every HTTP request and response in real-time, acting as an invisible middleman.

The Architecture of the Proxy

To achieve this, the attacker must register a deceptive domain (e.g., login-microsoft-secure.com) and configure Evilginx2 to proxy traffic to the legitimate domain (login.microsoftonline.com).

1. The Victim: Clicks the phishing link and establishes a TLS connection with the Evilginx2 server.
2. Evilginx2 (The Proxy): Receives the request, establishes its own TLS connection to the real Microsoft server, and requests the login page.
3. The Real Server: Sends the actual, dynamically generated login page back to Evilginx2.
4. Evilginx2: Intercepts the HTML on-the-fly. It rewrites all URLs, domain names, and cookie domains within the HTML to ensure that any subsequent requests made by the victim's browser point back to the proxy, not the real server. This keeps the victim trapped within the proxy loop.
5. The Victim: Receives the modified, yet fully functional, legitimate login page.

Image Graph Description: AiTM Proxy vs Traditional Phishing

Bypassing the MFA Challenge: Stealing the Token

The true brilliance of Evilginx2 is how it handles the Multi-Factor Authentication challenge. Because the victim is interacting with the real server (just routed transparently through the proxy), the authentication flow proceeds normally.

1. The real server asks for the 2FA Code.
2. The victim receives an SMS, approves a push notification, or checks their Authenticator App, and enters the required verification.
3. Evilginx2 blindly forwards this valid code to the real server.
4. The Critical Moment: The real server validates the code and responds with an authenticated Session Cookie (e.g., an Okta session token, an Azure ESTSAUTH token, or a Google SID cookie).
5. Evilginx2 intercepts this Set-Cookie response header, logs the high-value session token to its internal database, and transparently forwards the victim to their legitimate inbox or dashboard.

The attacker does not bypass MFA; they render it irrelevant. They simply take the captured session cookie, inject it into their own browser using a plugin like "EditThisCookie", and instantly gain authenticated, post-MFA access to the account without ever needing the victim's password or an MFA code.

Deep Dive: Phishlets and Proxy Configuration

Evilginx2 is a universal framework. It is not hardcoded to attack Microsoft or Google; it relies on configuration files known as Phishlets.

The Anatomy of a Phishlet

A Phishlet is a YAML configuration file that defines the precise rules for proxying a specific web application. It acts as the blueprint for the attack. A typical Phishlet contains:

• Proxy Hosts: Defines which subdomains of the target site need to be intercepted (e.g., login.microsoftonline.com, account.live.com).
• Sub Filters: Regular expressions that instruct Evilginx2 on how to dynamically rewrite the HTML and JavaScript passing through the proxy. This is crucial for fixing broken links or circumventing client-side anti-phishing scripts that check the domain name.
• Auth URLs: Specifies the exact API endpoints where the authentication POST requests occur.
• Credentials / Tokens: Defines exactly which HTTP POST parameters contain the username/password, and which specific cookies in the Set-Cookie response headers are the high-value session tokens that must be captured.

Because modern web applications frequently update their authentication flows (changing API endpoints or cookie names), maintaining Phishlets is an ongoing cat-and-mouse game within the offensive security community.

Deployment Strategy: Infrastructure and Operational Security

Deploying an AiTM proxy requires significantly more infrastructure and operational security than a standard phishing campaign.

1. The Virtual Private Server (VPS)

Evilginx2 must be hosted on a VPS with a clean IP reputation. Because it acts as a proxy, it generates significant outbound traffic to the target platform (e.g., Microsoft 365). If the IP address belongs to a known malicious subnet (like bulletproof hosting providers), the target platform may implement rate-limiting or conditional access policies that block the proxy entirely.

2. Domain Configuration and TLS

Evilginx2 requires a dedicated domain name. It handles its own Let's Encrypt TLS certificate generation to ensure the connection between the victim and the proxy shows the reassuring "padlock" icon in the browser.

• The operator must configure wildcard DNS A records (e.g., *.login-target-secure.com) pointing to the VPS, as Evilginx2 will dynamically create subdomains corresponding to the Proxy Hosts defined in the Phishlet.

3. Execution Commands

Operating the framework requires configuring the core parameters and enabling the specific lures:

# Start the Evilginx2 engine
sudo evilginx -p ./phishlets/ -c config.yaml

# Within the interactive Evilginx2 console:
config domain target-secure.com
config ip 192.168.1.100

# Setup the Microsoft 365 Phishlet
phishlets hostname o365 login.target-secure.com
phishlets enable o365

# Generate the specific Lures (The URLs to send in the phishing email)
lures create o365
lures get-url 0

Remediation: The FIDO2 Imperative

The proliferation of AiTM proxies like Evilginx2 has fundamentally shifted the defensive landscape. It is now a recognized reality within the cybersecurity industry: SMS codes, TOTP apps (Google Authenticator), and Push Notifications are obsolete against targeted social engineering attacks. If a human can type the code into a website, a proxy can steal the resulting session token.

The only effective, architectural defense against an Adversary-in-the-Middle proxy is the immediate implementation of FIDO2 / WebAuthn Hardware Security Keys (such as a YubiKey or Google Titan key).

Why FIDO2 Defeats AiTM

FIDO2 protocols rely on a cryptographic concept known as Origin Binding (or Domain Binding).

When a user is prompted to authenticate with a hardware security key, the browser does not simply ask the key for a generic code. Instead, the browser securely communicates the exact domain name currently in the address bar (e.g., login-microsoft-secure.com) to the hardware key. The key then cryptographically signs the authentication challenge using that specific domain name.

• If the victim is being phished and is interacting with the Evilginx2 proxy (login-microsoft-secure.com), the hardware key signs that domain.
• When Evilginx2 transparently forwards that cryptographic signature to the real Microsoft server (login.microsoftonline.com), the real server inspects the signature.
• The real server sees that the signature is bound to login-microsoft-secure.com, not login.microsoftonline.com. It immediately detects the discrepancy, recognizes the presence of an AiTM proxy, and rejects the authentication attempt.

The attack completely fails. Evilginx2 cannot manipulate the cryptographic signature, nor can it force the victim's browser to lie to the hardware key about the domain it is visiting.

Until organizations universally adopt FIDO2 and deprecate phishable factors like SMS and TOTP, sophisticated social engineering frameworks will continue to bypass perimeter defenses with devastating efficiency.`