EvilGoPhish is a project that combines concepts from Evilginx2 and GoPhish to support phishing simulation campaigns and centralized campaign reporting. It aims to connect email engagement metrics with activity recorded by a reverse-proxy-based authentication test environment.

For authorized penetration tests and red-team engagements, phishing simulations can help organizations evaluate employee awareness, authentication controls, and incident-response procedures. However, tools that proxy authentication sessions can also expose passwords, session cookies, and other sensitive authentication data. They should only be used within a clearly approved scope and with appropriate safeguards.

What Is EvilGoPhish?

EvilGoPhish combines the campaign-management and email-tracking capabilities associated with GoPhish with the reverse-proxy concepts used by Evilginx2. The goal is to correlate campaign activity with events observed during an authorized authentication-security assessment.

Traditional phishing simulation platforms commonly report events such as email delivery, message opens, link clicks, and landing-page interactions. Reverse-proxy-based authentication testing introduces additional security considerations because it may expose authentication data beyond the events normally collected by an awareness campaign.

For a closer look at its email campaign component, read our guide to Gophish, the open-source phishing toolkit, which covers its role in authorized phishing engagements and security-awareness training.

The project described in this article addresses two reporting and session-management challenges:

• Campaign tracking: Correlating email engagement with subsequent activity so that authorized assessors can evaluate campaign outcomes.
• Shared IP addresses and session attribution: Accounting for environments where several users access a test site through the same public IP address or where requests pass through a local proxy.

Why Campaign Tracking Matters

Security teams need reliable metrics to understand how users respond to simulated phishing messages. Without consistent event tracking, a campaign may not provide enough information to evaluate awareness training or compare results across test groups.

Useful metrics for an authorized awareness exercise can include:

• Email delivery and delivery failures.
• Email opens, where the tracking method and its limitations are documented.
• Link clicks and visits to the simulation landing page.
• Reports submitted by employees through approved reporting channels.
• Aggregate outcomes by department, test group, or campaign.

Email-open tracking is not a perfect measure of engagement. Privacy features, image proxies, and automated scanners can affect whether an open is recorded. Similarly, automated security tools may visit links without a person interacting with the message. Campaign reports should therefore be interpreted alongside other evidence rather than treated as definitive proof of user behavior.

Understanding Shared-IP and Session-Attribution Problems

In corporate networks, multiple users may share one public IP address because of network address translation (NAT), secure web gateways, or forward proxies. Local reverse proxies can also make requests appear to originate from the same address.

If a testing application relies too heavily on IP addresses to distinguish sessions, activity from different users can be incorrectly associated with the same session. This can reduce the reliability of campaign reporting and complicate investigation of test results.

For assessment environments, session attribution should be designed around privacy-conscious, campaign-specific identifiers and validated event records rather than assuming that an IP address uniquely identifies a person. Any identifiers collected should be protected and retained only as long as the engagement requires.

Background and General Architecture

The project brings together components with different responsibilities. In a typical conceptual deployment, the email campaign platform manages messages and reporting, a reverse proxy may be used to assess authentication flows in a controlled test, and a web server routes incoming requests to the appropriate application.

In the original design, the public-facing web server acts as an entry point and routes requests to different local services according to the requested hostname. The applications can maintain separate logs, helping administrators investigate routing behavior and diagnose reporting discrepancies.

Exact ports, hostname mappings, certificate paths, and application behavior depend on the deployment and software versions. They should be documented and validated against the configuration used in the authorized test environment.

Configuration and Deployment Considerations

The original project describes helper scripts for configuring domains, routing, redirects, and campaign identifiers. Before using any third-party automation, review the source code and understand every change it makes to the server, web server, certificates, and application configuration.

For a controlled security assessment, the deployment plan should address the following areas:

• Authorization and scope: Record the approved domains, recipient groups, test window, techniques, and exclusions.
• DNS and TLS: Confirm that domain ownership is verified and that certificates are valid for the approved test hosts.
• Reverse-proxy configuration: Document which services receive traffic and ensure administrative interfaces are not exposed publicly.
• Logging: Record sufficient metadata to troubleshoot delivery and routing without unnecessarily collecting sensitive information.
• Access control: Restrict access to campaign dashboards, server logs, and assessment infrastructure to authorized personnel.
• Data handling: Avoid retaining real passwords, session cookies, or reusable authentication tokens. Use safe test accounts and non-sensitive test data wherever possible.
• Cleanup: Define how temporary DNS records, certificates, accounts, logs, and infrastructure will be removed after the engagement.

Campaign Preparation and Validation

Before launching a phishing-awareness exercise, validate the campaign in a dedicated test environment. Start by confirming that approved test messages are delivered as expected and that reporting events are recorded consistently.

A responsible validation checklist includes:

• Confirm that all recipients and domains are within the written scope.
• Verify that campaign links resolve only to approved test infrastructure.
• Test event reporting with designated test accounts.
• Check that shared-IP traffic does not cause reporting to associate events with the wrong test account.
• Confirm that security monitoring and incident-response teams know how the exercise will be coordinated.
• Verify that the test does not retain real authentication secrets or allow unauthorized reuse of captured sessions.
• Prepare a rollback plan and a process for promptly stopping the exercise if unexpected activity occurs.

Security Risks and Limitations

Combining email campaign tracking with authentication-proxy testing creates risks that do not arise in every conventional awareness campaign. A reverse proxy capable of observing an authentication flow may handle highly sensitive information, including session material that can be used to impersonate an authenticated user.

Additional concerns include:

• Sensitive-data exposure: Logs, databases, and operator terminals may contain authentication information that must not be distributed or retained unnecessarily.
• Misleading campaign statistics: Email scanners, link inspection systems, and privacy features can distort tracking results.
• Infrastructure exposure: Incorrect proxy or firewall settings can expose administrative services or test systems to the public internet.
• Operational disruption: Aggressive testing may trigger account lockouts, security alerts, or service protections.
• Project maintenance: Older or archived projects may not receive security updates or remain compatible with current dependencies.

Use phishing simulations to evaluate defensive controls without collecting real user credentials or retaining reusable session tokens. Where an engagement specifically requires testing resistance to adversary-in-the-middle attacks, agree on a controlled method with the system owner and use designated test accounts, strict data-handling rules, and an explicit stop procedure.

Safer Alternatives for Awareness Reporting

Many organizations can measure the effectiveness of phishing-awareness training without deploying an authentication proxy that captures live session material. A conventional GoPhish campaign can track message engagement and direct participants to a controlled landing page that records the intended training outcome.

For authentication-resilience assessments, teams can separately evaluate phishing-resistant multifactor authentication, such as passkeys or FIDO2 security keys, and review identity-provider logs for suspicious sign-ins. This approach can provide useful defensive evidence while reducing the risk of collecting reusable authentication secrets.

Official project documentation is a good starting point for understanding the supported capabilities and security considerations of the individual components:

• GoPhish source repository
• Evilginx2 source repository

Conclusion

EvilGoPhish illustrates how phishing-campaign reporting can be connected with more advanced authentication-security testing. Its central concepts include campaign-event correlation, reverse-proxy architecture, and the challenge of distinguishing users whose traffic shares an IP address.

For security teams, the most important considerations are reliable metrics, carefully scoped testing, protection of sensitive authentication data, and secure infrastructure configuration. Choose the least intrusive method that answers the assessment question, document the limitations of the results, and ensure that all testing remains authorized and controlled.