Evilginx2: a Go reverse-proxy phishing framework for authorised red team engagements

What Evilginx2 actually does, and who the README says should run it

Evilginx2 is a man-in-the-middle attack framework, in the words of its own README, used for phishing login credentials along with session cookies, which in turn allows it to bypass 2-factor authentication protection. The mechanism is not a fake login page. The tool sits between the browser and the genuine site, forwards the real page, and keeps the session material that comes back. That distinction matters: a cloned page can steal a password, but a valid session cookie is what lets an attacker keep the authenticated session after the password is changed.

The predecessor, released in 2017, was a custom version of the nginx HTTP server configured as a proxy. The current version is fully rewritten in GO as a standalone application that implements its own HTTP and DNS server. That rewrite is the reason the project has no nginx dependency and no separate DNS daemon to configure.

The intended audience is narrow and the README is explicit about it. Evilginx should be used only in legitimate penetration testing assignments with written permission from to-be-phished parties. The author also states plainly that he is aware the tool can be used for nefarious purposes and treats it as a demonstration of what adept attackers can do, leaving defenders to account for the technique. There is no licence term or runtime check that enforces the written-permission condition. It is a stated expectation, not a control.

The reverse proxy, the bundled DNS server and the phishlet format

Three components do the work. The HTTP side terminates TLS and proxies requests to the genuine site, which is why the browser sees a valid certificate for the domain the victim typed. The DNS side is a server implemented inside the binary, so the operator does not run a separate resolver. Phishlets are the per-target configuration that tells the proxy which URLs to intercept, which fields to capture and how to rewrite responses; the repository ships a phishlets directory, and the README links to a separate Evilginx Pro offering with a maintained official phishlets database, which implies the open source set is not the maintained one.

The dependency list in go.mod shows the shape of the build. caddyserver/certmagic and go-acme/lego handle ACME certificate issuance, miekg/dns provides the DNS server, inconshreveable/go-vhost does the TLS SNI demultiplexing that lets one listener serve many hostnames, and tidwall/buntdb is the embedded store. gorilla/mux routes requests and elazarl/goproxy is present for proxying. Everything is vendored, so the build does not need network access to fetch modules.

The practical consequence of the SNI multiplexer plus ACME is that a single instance can front several domains on one address, with certificates obtained automatically. The practical cost is that the operator has to control DNS for every domain and let the ACME challenge complete before any of it works.

Building Evilginx2 from source and a first configuration

The README does not carry install steps; it directs readers to the online documentation at help.evilginx.com for installation and usage. What the repository does give is the build itself. The Makefile defines a single target that builds main.go with vendored modules into ./build/evilginx:

make build

Running that produces the binary at ./build/evilginx. The Makefile also defines make clean, which runs go clean and removes the built binary. The go.mod file declares go 1.22, so a Go toolchain at or above that version is what the module expects. The Makefile lists the packages it builds as core, database, log and parser, and the top-level repository layout matches: core/, database/, log/ and parser/ each exist as directories.

Once the binary is running it presents an interactive console. The console exposes commands for the two things every setup needs: a domain to serve and a phishlet to serve with it. The README does not print the console syntax, so check the online documentation at help.evilginx.com for the exact command names before enabling anything.

Certificate issuance happens as part of enabling a phishlet, which is why DNS has to resolve to the host's public address first. If the ACME challenge cannot complete, the phishlet will not come up, and the console is where that failure surfaces.

Where Evilginx2 breaks, and when it is the wrong tool

The first limitation is the one the author states himself: he does not offer support for providing or creating phishlets, and will not help with writing your own. A phishlet is not a generic template. It encodes the specific request and response patterns of one target, and when that target changes its login flow the phishlet stops capturing what it used to. There is no upstream maintenance commitment for the open source phishlet set, and the README points to a separate commercial product for a maintained database. Budget for that work or do not start.

The second limitation is operational. The built-in DNS server has to be reachable on port 53, and the ACME flow has to complete against a domain you control, which means the host needs a public address and the DNS records need to point at it before the first phishlet is enabled. That is a heavier prerequisite than a static HTML page, and it is the step where most first attempts stall.

The third is that this is the wrong tool for anything defensive. Evilginx2 generates no detection signatures, no telemetry and no reporting. It is also the wrong tool for a test where the client has not authorised impersonation of the specific brand involved, because the tool has no notion of scope. And it is the wrong tool for a quick credential-phishing simulation: if you do not need session cookies, a plain form is simpler and does not require DNS control or certificate issuance.

How Evilginx2 differs from Gophish and from a static phishing page

Gophish is the closest comparison in the README itself, and the project's own answer is integration rather than substitution. The README describes an official Gophish integration with Evilginx 3.3, hosted in a forked repository at github.com/kgretzky/gophish, with setup instructions in a linked blog post. The division of labour is that Gophish sends the campaign emails, tracks who clicked and reports on the results, while Evilginx2 handles the proxying and the session capture. Gophish on its own serves landing pages you supply; it does not reverse-proxy a live site, so it cannot produce a valid session cookie for the real target.

Against a hand-written phishing page the difference is the same one in a different form. A static page is a copy of the login form. It captures whatever the victim types into it and nothing else. Evilginx2 forwards the genuine response, so the victim interacts with the real application's behaviour, and the session token issued by the real server is what the operator ends up holding. The cost of that fidelity is the entire infrastructure: DNS, certificates, a public host, and a phishlet that stays current with the target.

A third comparison worth naming is the project's own successor. Evilginx Pro, described in the README as the result of over two years of development, lists out-of-the-box phishing detection evasion including Chrome's Enhanced Browser Protection, a tested and maintained official phishlets database, Botguard, external DNS providers with multi-domain support, website spoofing, JavaScript and HTML obfuscation, wildcard TLS certificates, automated server deployment and SQLite support. None of those appear in the open source feature list here. If any of them is a requirement, the open source project is not the one to evaluate.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-06-10. The most recent tagged release is v3.3.0, dated 2024-04-02 and titled Go & Phish; before it come v3.2.0 from 2023-08-24 and v3.1.0 from 2023-07-11. So commits have landed more recently than the newest tag, and anyone tracking releases rather than the default branch is roughly two years behind the branch head. The CHANGELOG file at the repository root is where the release notes live.

The build is vendored, which removes most upgrade friction: the Makefile passes -mod=vendor, so the dependency versions in go.mod are the ones compiled in, and a rebuild will not silently pull newer modules. That also means dependency updates arrive only when the vendor directory is refreshed upstream. The go 1.22 directive is the one version constraint to check before building.

The licence is BSD-3-Clause, as stated in the README and shipped in the LICENSE file. That is a permissive licence, and it does not carry any clause restricting use to authorised testing. The written-permission requirement in the README is an author's request, not a licence condition, so the legal exposure of running this against a party that has not consented sits entirely with the operator. Nothing here is legal advice; if the scope of an engagement is unclear, that is a question for whoever signs it.

Editorial conclusion

Evilginx2 fits red teams and penetration testers who have written authorisation from the parties being phished, and who are prepared to write or source their own phishlets, since the author states he does not provide or help create them. It does not fit defenders looking for a detection tool, and it does not fit anyone without a signed scope: the tool has no authorisation check of its own. Before deploying, verify three things: that your Go toolchain matches the go 1.22 directive in go.mod, that your DNS and TLS setup can satisfy the ACME flow and the port 53 binding the built-in server needs, and that your phishlet targets are ones you are permitted to impersonate.

Frequently asked questions

Official sources

1. Issues
2. kgretzky/evilginx2 on GitHub
3. License: BSD-3-Clause
4. README
5. Releases