performing-initial-access-with-evilginx3

name	performing-initial-access-with-evilginx3
description	Perform authorized initial access using EvilGinx3 adversary-in-the-middle phishing framework to capture session tokens and bypass multi-factor authentication during red team engagements.
domain	cybersecurity
subdomain	red-teaming
tags	["red-team","initial-access","phishing","evilginx","mfa-bypass","adversary-in-the-middle","credential-theft"]
version	1.0
author	mahipal
license	Apache-2.0
d3fend_techniques	["File Metadata Consistency Validation","Application Protocol Command Analysis","Identifier Analysis","Content Format Conversion","Message Analysis"]
nist_csf	["ID.RA-01","GV.OV-02","DE.AE-07"]

Performing Initial Access with EvilGinx3

Overview

EvilGinx3 is a man-in-the-middle attack framework used for phishing login credentials along with session cookies, enabling bypass of multi-factor authentication (MFA). Unlike traditional credential phishing that only captures usernames and passwords, EvilGinx3 operates as a transparent reverse proxy between the victim and the legitimate authentication service, intercepting the full authentication flow including MFA tokens and session cookies. This makes it the primary tool for red teams demonstrating the risk of adversary-in-the-middle (AiTM) attacks against organizations relying solely on MFA for protection.

When to Use

• When conducting security assessments that involve performing initial access with evilginx3
• When following incident response procedures for related security events
• When performing scheduled security testing or auditing activities
• When validating security controls through hands-on testing

Most Often Missed & How to Confirm

• Phishlet tuning is the #1 miss: stock phishlets break when the target updates JS/login domains. Confirm every auth_urls, sub_filter, and js_inject host resolves through the proxy — a blank or styling-broken login page means the phishlet needs proxy_hosts/sub_filter fixes, not a "tool doesn't work" conclusion.
• Domain reputation and TLS are routinely skipped — age the domain, set categorization, and verify Let's Encrypt issued (phishlets shows cert OK). A fresh look-alike domain gets blocked by SmartScreen/Safe Browsing before the victim ever submits.
• The real prize is the captured session cookie, not the password: MFA bypass only works if you import the full token set (e.g., o365 ESTSAUTH/ESTSAUTHPERSISTENT, Okta sid/idx) and reach the app without re-prompt.
• Use lures edit 0 redirect_url to bounce victims to the real site post-capture so the AiTM stays unnoticed; missing this often tips off the target.
• Blacklist scanners (blacklist unauth) so bots/sandboxes don't burn the domain before delivery.
• Positive signal: sessions <id> shows non-empty captured cookies/tokens AND those cookies imported via Cookie-Editor load the authenticated app (mailbox/SharePoint) without an MFA prompt.
• Don't conclude the AiTM failed until: (1) the proxied login page renders and accepts creds, (2) tokens/cookies were actually captured (not just username/password), (3) the cookie set imported and bypassed MFA in a clean browser profile, and (4) the domain wasn't blocked at delivery (check it loads from an external network).