Security teams detect evilginx2 by identifying reverse-proxy phishing activity that relays credentials and session cookies through a lookalike sign-in flow. Watch for unusual authentication patterns, impossible travel, session hijacking, and domains that mimic legitimate services. Enforce phishing-resistant MFA, validate new devices and token use, and review web and identity logs for proxy indicators.
What evilginx2 detection really looks for
Detection starts with the behaviour, not the brand name. Evilginx2 is an adversary-in-the-middle phishing pattern, so teams should look for a legitimate-looking sign-in page that proxies a real identity provider, then relays credentials and session cookies to the attacker in near real time. The strongest signals are a successful login followed by odd session reuse, token replay, or device context that does not fit the user’s normal pattern.
Because the lure often mirrors a real service closely, domain analysis still matters. Watch for lookalike hostnames, newly registered domains, certificate patterns that do not match the business, and web requests that show a reverse-proxy flow rather than a normal direct authentication journey. The most useful review combines web telemetry with identity telemetry, since the phishing page alone may look ordinary while the session behaviour exposes the compromise.
Telemetry that most often exposes the proxy layer
Identity logs usually provide the clearest proof that something abnormal happened. Impossible travel, unfamiliar device fingerprints, new user agents, or a fresh session that immediately starts using an existing cookie are all strong indicators. If the user authenticated with MFA but the attacker still obtained a valid session, the problem is often cookie theft or token replay rather than password guessing.
On the web side, teams should examine the path taken before and after the login event. A lookalike domain that forwards to a real identity provider, especially when the sign-in page loads scripts, assets, or redirects in an unusual sequence, can reveal adversary-in-the-middle tooling. Correlating those web events with sign-in success, conditional access logs, and session creation often makes the pattern obvious even when the phishing page disappears quickly.
For a practical detection playbook, the AiTM Phishing Guide is the most direct internal reference because it covers Evilginx, session cookie theft, and the defensive signals that matter in this attack class.
How to turn detection into prevention and response
Detection is strongest when it is paired with phishing-resistant authentication and token validation. MFA that still allows easy relay of a session is not enough on its own, so teams should prefer authenticators that bind the login to the genuine browser or device, and they should verify whether new sessions are created from a context that matches enrollment and prior use. The aim is to make cookie theft and replay much harder to turn into a durable foothold.
When suspicious activity appears, treat the session as compromised even if the initial username and password were correct. Revoke active sessions, invalidate refresh tokens where possible, review recently issued tokens and device registrations, and check whether the attacker used the session to access mail, documents, or admin portals. If the user account has higher privilege or access to sensitive systems, credential and session rotation should follow quickly, because the attacker’s value is usually in the preserved session rather than the password itself.
Risk and Threat Considerations
Evilginx2 is dangerous because it can defeat a weak MFA rollout without needing malware on the endpoint. The threat is not just credential theft, it is trusted session capture, which means the attacker may inherit an already authenticated context and bypass the normal sign-in challenge path.
Failure mechanism: The phishing proxy relays the victim’s login in real time, captures the session cookie or token, and then reuses that artefact from an attacker-controlled environment that may not trigger the same user-facing prompts.
Impact: Security teams can miss the compromise if they only alert on failed logins or password resets. The result can be mailbox access, SaaS takeover, lateral movement through trusted applications, and persistence until the session or token is explicitly revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Evilginx2 detection hinges on phishing-resistant authentication and session integrity. |
| Recommendation — Prefer phishing-resistant authenticators and validate session context before trusting a successful login. | ||
| MITRE ATT&CK | T1586 — Compromise Accounts | Evilginx2 is used to steal usable accounts and sessions through phishing relays. |
| Recommendation — Map observed login replay and session theft to account-compromise detection in your hunt process. | ||
| NIST CSF 2.0 | DE.CM-03 — Detection of Anomalies and Events | The question is about detecting abnormal authentication and session behaviour. |
| Recommendation — Monitor sign-in anomalies, impossible travel, and token replay as detection signals. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Evilginx2 abuses authentication flows by relaying credentials and sessions. |
| NHI-02 — Secret Leakage | Session cookies and tokens are the artefacts Evilginx2 steals and reuses. | |
| Recommendation — Use phishing-resistant authentication and bind sessions to reduce relay abuse. Rotate or revoke exposed session artefacts immediately after suspected relay theft. | ||
Practitioner Guidance
What to verify: Confirm that your identity logs retain enough device, token, and session detail to distinguish a normal login from a relayed one. If you cannot correlate user agent, IP geography, device registration, and token issuance, detection will stay noisy and late.
Decision rule: If a user successfully passes MFA but the resulting session shows unfamiliar context or immediate high-risk activity, treat it as session compromise first and as a user-error event second. That order matters because waiting for stronger proof can leave the attacker active inside a valid session.
Practitioner takeaway: The key judgement is to investigate the session, not just the login. Evilginx2 is often visible only when web telemetry and identity telemetry are analysed together, and the response should assume that a valid session can still be hostile.