Listen to this Post
Introduction:
The modern security stack’s crown jewel, Multi-Factor Authentication (MFA), has a critical blind spot: it secures the login, not the session. Adversary-in-the-Middle (AiTM) phishing frameworks like Evilginx exploit this by positioning a transparent proxy between the user and a legitimate service, capturing both credentials and the session cookie in real time. This allows attackers to bypass MFA entirely by replaying the stolen cookie, effectively “passing the cookie” into their own browser to gain authenticated access without ever needing the second factor.
Learning Objectives:
- Understand the operational architecture of Evilginx 3.0 and how its reverse proxy mechanics enable AiTM attacks.
- Identify the three-stage attack chain of an Evilginx campaign: phishing lure deployment, credential/session theft, and cookie replay for lateral movement.
- Acquire actionable knowledge of Linux and Windows commands for both executing simulated red-team exercises and implementing defensive countermeasures.
You Should Know:
- Anatomy of an Evilginx Attack: The Three-Stage Chain
Evilginx attacks operate in a stealthy, three-stage process that begins with a deceptive lure and ends with full account takeover. Understanding this flow is crucial for both offense and defense.
Step‑by‑step guide explaining the attack chain:
Stage 1: Deployment and Proxy Setup. The attacker deploys Evilginx on a VPS. They configure a “phishlet”—a Lua script defining how the proxy interacts with the target (e.g., Microsoft 365 or Okta). The attacker then sets up a lure, generating a unique phishing URL (often a subdomain mimicking the legitimate service).
Stage 2: Credential and Session Harvesting. The victim receives a convincing phishing email containing the lure link. Clicking it loads the Evilginx proxy, which transparently fetches the real login page. The victim logs in, completes MFA, and submits the form. Evilginx logs the credentials and, critically, captures the `session cookie` from the server’s response.
Stage 3: Cookie Replay and Lateral Movement. The attacker uses browser developer tools or an extension to inject the stolen cookie into their own browser session. The application now sees the attacker as the legitimate, authenticated user. From here, they can access email, set up inbox rules for data exfiltration, or pivot to connected cloud apps.
2. Deploying Evilginx 3.0: A Red-Team Simulation Guide
For authorized penetration testing, setting up Evilginx provides a realistic simulation of this advanced threat. The framework is written in Go and includes its own HTTP and DNS servers, simplifying deployment.
Step‑by‑step guide explaining what this does and how to use it:
1. Download and Install (Linux):
Clone the repository (using a known community fork for latest features) git clone https://github.com/EvilHoster/evilginx-3.4.0-telegram-modification cd evilginx-3.4.0-telegram-modification Build the binary sudo make install
This command retrieves the source code and compiles the Evilginx binary, making it executable on your system.
2. Launch Evilginx:
Run the binary with root privileges (needed to bind to ports 80 and 443) sudo ./evilginx -developer
The `-developer` flag enables local testing mode, which uses a self-signed TLS certificate. For production, you would configure it with a real domain and Let’s Encrypt certificates.
3. Configure a Phishlet and Lure:
Inside the Evilginx interactive console:
List available phishlets phishlets Configure a phishlet for a target (e.g., Outlook) phishlet get outlook phishlet enable outlook Create a lure that points to your server's domain lures create outlook
This sequence loads the configuration for the Outlook phishlet, enabling the proxy rules, and then generates a unique phishing link to distribute to targets.
4. Monitor Captured Data:
View all captured sessions sessions Get detailed info for a specific session, including credentials and cookies session <session_id>
After a victim interacts with the lure, the `sessions` command will list the harvested data. The `session` command displays the stolen username, password, and the raw session cookie value.
3. Defensive Mitigations: Detecting and Blocking Evilginx
Protecting an organization requires shifting from a MFA-first mindset to a session-centric security model. Several key controls can dramatically reduce the risk.
Step‑by‑step guide for defenders:
- Implement Phishing-Resistant MFA: Standard TOTP or SMS-based MFA is ineffective against AiTM attacks. Transition to WebAuthn-based credentials (e.g., FIDO2 security keys or platform authenticators like Windows Hello). These are bound to the origin’s domain name, making them unphishable by a proxy.
-
Enforce Continuous Access Evaluation (CAE): In Microsoft Entra ID, CAE can react to real-time events. If a user’s session cookie is replayed from an anomalous location, CAE can force a re-authentication or terminate the session. Configure Conditional Access policies to use “Require continuous access evaluation.”
-
Monitor for Impossible Travel and Anonymous IPs: Actively audit sign-in logs. Look for events where a user authenticates from New York and, minutes later, a session appears from a different continent. Flag any logins originating from known proxy or VPN exit nodes, as attackers often tunnel Evilginx traffic through such services to evade geolocation-based policies.
-
Shorten Session Lifetimes: Aggressively reduce the validity period of session tokens. Configure your identity provider (IdP) to issue sessions with short lifetimes (e.g., 1-8 hours for high-risk applications). This minimizes the window of opportunity for an attacker to use a stolen cookie.
-
Leverage DNS Threat Intelligence: Evilginx campaigns often use short-lived domains and subdomains that mimic legitimate brands. Use a security solution that performs passive DNS analysis to detect and block newly registered, look-alike domains (e.g.,
login.microsoftonline.com.secure.verify). Infoblox’s research into university attacks showed how DNS patterns can uncover malicious infrastructure that traditional URL filters miss.
4. Forensic Commands for Post-Compromise Analysis
When an Evilginx attack is suspected, incident responders need to hunt for evidence of cookie theft and proxy usage.
Step‑by‑step guide for investigators:
1. Check for Suspicious Browser Extensions (Windows):
List all installed Chrome extensions with their IDs Get-ChildItem -Path "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Extensions\" | Select-Object Name
Attackers may install malicious extensions that automate cookie extraction. This command enumerates all extensions, allowing an analyst to cross-reference IDs against known malicious ones.
- Audit Microsoft Entra ID Sign-in Logs (Azure Portal or CLI):
Using Azure CLI to pull recent sign-ins for a specific user az rest --method get --url "https://graph.microsoft.com/v1.0/auditLogs/signIns?`$filter=userPrincipalName eq '[email protected]'&<code>$top=10"
Examine theclientAppUsed
,ipAddress, and `isInteractive` fields. Look for non-interactive logins (isInteractive: false`) from unusual IPs immediately after a successful interactive login, as this could indicate cookie replay.
3. Scan for Evilginx Phishlet Artifacts (Linux):
Search web server logs for common phishlet user-agent strings or URI patterns
grep -E "Evilginx|evilginx" /var/log/nginx/access.log
grep -E "/[a-zA-Z0-9]{8}/" /var/log/nginx/access.log
Evilginx phishlets often generate URI paths with eight random alphanumeric characters. This command hunts for that pattern in access logs to identify potential proxy requests.
5. Hardening Your Cloud Identity Infrastructure
Beyond detection, proactive hardening of your identity configuration is essential to neutralize the effectiveness of stolen session cookies.
Step‑by‑step guide for cloud administrators:
- Enable Token Binding: In modern browsers and OSs, configure your IdP to request token binding. This cryptographically binds a session token to the specific device’s TLS context. If an attacker tries to replay the cookie on a different machine, the token binding will fail, and the session will be rejected.
-
Configure Conditional Access for Session Controls: Use Conditional Access policies to enforce session controls like “Sign-in frequency” and “Persistent browser session.” Set a short sign-in frequency (e.g., every 1-3 hours) for critical applications. This limits the usable lifespan of any stolen session cookie.
-
Deploy a Cloud Access Security Broker (CASB): A CASB can monitor user behavior post-authentication. It can detect anomalies such as a user downloading an unusual volume of data, setting up a new email forwarding rule, or accessing sensitive SharePoint sites from a new device—all common post-compromise activities following a pass-the-cookie attack.
-
Implement a Strict Content Security Policy (CSP): While not a primary defense, a robust CSP on your login pages can help mitigate the impact of any XSS vulnerabilities that could be chained with an AiTM attack to exfiltrate cookies.
What Undercode Say:
- Evilginx effectively weaponizes session cookies, the very artifact that enables seamless user experience, turning it into the attacker’s key to bypass MFA.
- Defending against AiTM attacks requires a paradigm shift from securing only the authentication event to continuously validating the entire session’s context and behavior.
- The most practical immediate defenses are phishing-resistant MFA (FIDO2), aggressive session timeouts, and continuous monitoring for impossible travel or anonymous IP logins.
Prediction:
As AiTM frameworks like Evilginx become commoditized, the effectiveness of legacy MFA will rapidly approach zero. This will force a widespread industry migration toward phishing-resistant credentials and real-time session intelligence, embedding security directly into the authentication protocol itself (e.g., Token Binding). In the near future, “session-aware” security models will replace the static perimeter, and identity-centric breaches will be detected and stopped in seconds, not months.
▶️ Related Video (88% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Syed Muneeb – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
