4 min read

Evilginx Phishing Proxy

Learn about the threat of free Adversary-in-the-Middle (AiTM) phishing proxy Evilginx and how to mitigate it.
A puffin is flying with a small fish in its b
Photo by Sharon Watters / Unsplash

Evilginx is a free and open source phishing proxy popular with red teams and real threats such as Star Blizzard, as MSTIC recently noted. The server-side software, written in Go, facilitates Adversary-in-the-Middle (AiTM) phishing [T1557] by intercepting requests and responses between victims and the websites where they think they're authenticating.

Because victim browsers connect to a site with a different domain name than the legitimate one, WebAuthn MFA stops AiTM attacks. WebAuthn is scoped to a specific origin, so a login initiated through an attacker-controlled site will fail.

Evilginx (or Evilginx2, as the project is now known) intercepts credentials, 2FA codes [T1111], and session cookies [T1539]. It is flexible enough to target most web login flows using configuration files called "phishlets" available on GitHub.

Its developer provides hours of training in a course called Evilginx Mastery—with specific instructions on targeting Okta and Office 365 logins—for €399 at the time of writing. The tool is actively developed and was recently updated to improve targeting of modern single-page web apps.


For a free phishing tool, Evilginx has a very impressive feature set. I know from experience this is why red teams choose it—apparently it's serving APTs well, also. As of December 2023, Evilginx can:

  • Capture email address or username and password, 2FA codes, session cookies
  • Modify victims' POST request parameters, such as "stay signed in" or "remember me" checkbox values (force_post in phishlet config)
  • Inject custom JavaScript [T1659] into proxied pages (js_inject) for pre-filling fields or clicking buttons
  • Proxy requests [T1090] between Evilginx and targted sites via HTTP or SOCKS5 proxies
  • Pause phishing campaigns for a specific period of time, during which visitors would be redirected away
  • Filter out requests based on HTTP User Agent
  • Automatically generate and update TLS certificates using LetsEncrypt
  • Run headless browser sessions with Evilpuppet to generate valid secret tokens that are meant to thwart proxy phishing (paying Evilginx Pro customers, only)
GitHub - kgretzky/evilginx2: Standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication
Standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication - GitHub - kgretzky/evilginx2: Stand…

How it works

To use Evilginx in a phishing campaign, threats obtain a domain name that is a convincing fake of the actual site [T1590] being proxied. For example, when targeting Nakatomi Corp logins at sso.nakatomi.com, attackers might use domains such as sso-nakatomi.com in hopes that employees will hurriedly access this fake site and send their credentials through it.

Unlike other phishing kits, Evilginx does not require its users to clone the markup of targeted websites as it sits in the middle of HTTP traffic between victims and targeted websites, collecting the useful bits like email addresses or usernames, passwords, time-based one-time password (TOTP) codes, and session cookies. Evilginx knows which web form parameters and cookies to capture based on the configuration file used for the targeted site or app.

Once a victim submits valid credentials to their intended website through an Evilginx proxy, threats have the cookies [T1539] to take over that valid session as well as credentials to log in again, or try against other sites. When a victim starts a session through Evilginx, the proxy's public IP address will appear in audit logs instead of the victim's. This is because the victim connects to Evilginx and it connects to the target service.


  • Use and enforce use of WebAuthn-based methods of multi-factor authentication, including Passkeys, to stop AiTM [M1032, M1036]
  • Discourage password re-use by providing and using a password manager to create and store unique passwords [M1027], limiting the impact of a single stolen passphrase
  • Educate yourself and others at your organization on AiTM phishing, taking care to check website domains, visiting sites directly if unsure [M1017]
  • Use features that specifically alert you to AiTM phishing attempts if your single sign-on provider offers them, as Okta does with FastPass
  • Discover [M1019], block [M1021, M1037], and report lookalike domains that may be used to impersonate your websites or key vendors such as email and single sign-on services
  • Review login audit logs [M1047] and note attempts or successes from unfamiliar IP addresses, particularly on cloud platforms. Phishing servers may be geographically proximal to victims
  • When responding to a phishing incident, assume the session involved was compromised in addition to credentials; invalidate all sessions, reset credentials, and review activity by the affected user

Further reading