Performing Initial Access With Evilginx3

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).

Prerequisites

• Familiarity with red teaming concepts and tools
• Access to a test or lab environment for safe execution
• Python 3.8+ with required dependencies installed
• Appropriate authorization for any testing activities

Objectives

• Deploy EvilGinx3 with custom phishlets targeting authorized scope
• Configure DNS and SSL certificates for the phishing domain
• Capture session tokens that bypass MFA protections
• Import stolen session cookies into a browser to hijack authenticated sessions
• Integrate with GoPhish or custom delivery mechanisms for phishing email campaigns
• Document the complete attack chain from phishing email to authenticated access

MITRE ATT&CK Mapping

• T1566.002 - Phishing: Spearphishing Link
• T1557 - Adversary-in-the-Middle
• T1539 - Steal Web Session Cookie
• T1078 - Valid Accounts
• T1556 - Modify Authentication Process
• T1550.004 - Use Alternate Authentication Material: Web Session Cookie

Workflow

Phase 1: Infrastructure Setup

1. Register a convincing lookalike domain (e.g., using homoglyphs or typosquatting)
2. Provision a VPS and point the domain's DNS A record to the server IP
3. Install EvilGinx3:

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

4. Configure the domain and IP in EvilGinx3:

   config domain example-phish.com
   config ipv4 <server-ip>
   

5. EvilGinx3 automatically provisions Let's Encrypt certificates for configured hostnames

Phase 2: Phishlet Configuration

1. Select or create a phishlet for the target service (e.g., Microsoft 365, Google Workspace):

   phishlets hostname o365 login.example-phish.com
   phishlets enable o365
   

2. Verify phishlet is active and SSL certificate is issued:

   phishlets
   

3. Create a lure URL for the phishing campaign:

   lures create o365
   lures get-url 0
   

4. Optionally configure a redirect URL for post-capture:

   lures edit 0 redirect_url https://legitimate-site.com
   

Phase 3: Phishing Delivery

1. Craft a pretext email with the lure URL embedded
2. Use GoPhish or manual SMTP for email delivery:

   # Integration with EvilGoPhish for combined campaigns
   # Provides GoPhish email tracking + EvilGinx3 credential capture
   

3. Implement URL masking or shortening if needed for link obfuscation
4. Deploy landing page with appropriate social engineering pretext

Phase 4: Session Hijacking

1. Monitor EvilGinx3 for captured sessions:

   sessions
   sessions <session-id>
   

2. Extract captured session cookies from the session:

   # Session output includes:
   # - Username and password
   # - Session cookies (authentication tokens)
   # - Custom captured parameters
   

3. Import session cookies into a browser using a cookie editor extension:
   • Export cookies in JSON format
   • Use Cookie-Editor or EditThisCookie browser extension
   • Navigate to the target service to validate session hijack
4. Establish persistent access by creating application passwords or OAuth tokens

Phase 5: Post-Access Activities

1. Enumerate mailbox contents, contacts, and shared drives
2. Identify additional targets for lateral phishing
3. Check for access to connected cloud applications (SharePoint, Teams, OneDrive)
4. Document all captured credentials and access achieved

Tools and Resources

Phishlet Targets

Detection Indicators

Validation Criteria

• EvilGinx3 deployed with valid SSL certificates
• Phishlet configured and enabled for target service
• Lure URL generated and accessible
• Test credentials captured successfully through phishing flow
• Session cookies captured and validated for MFA bypass
• Session hijack demonstrated in browser with stolen cookies
• Post-authentication access to target service confirmed
• Evidence documented with screenshots and session logs