How can security teams detect EvilProxy?

What EvilProxy detection is really looking for

EvilProxy is most visible when defenders treat it as adversary-in-the-middle phishing rather than ordinary credential theft. The key signal is that the attacker is relaying a live login flow, so telemetry often shows a normal-looking sign-in followed by unusual token use, session creation, or access from an endpoint that does not fit the user’s recent pattern.

A useful detection lens is whether the authentication journey looks “split” across two places at once. If a user receives a familiar MFA prompt, completes it, and then the account immediately behaves as if it was authenticated elsewhere, that is often more telling than any single event on its own.

For teams building hunting logic, the strongest clues usually sit around session behaviour, not just the login page. Track impossible travel, new device and location combinations, fresh browser fingerprints, and sudden access to mail, SaaS, or admin consoles after a legitimate-looking authentication event.

Signals that separate EvilProxy from generic phishing

Reverse-proxy kits tend to leave infrastructure and interaction clues that differ from a simple fake login page. Suspicious domains often imitate a real login portal closely enough to pass casual inspection, but they may be short-lived, newly registered, or show naming patterns that mirror brand and tenant identifiers.

The browser side can also betray the relay. Mismatched user agent strings, odd TLS or redirect behaviour, and authentication that succeeds only after a chain of redirects are all worth correlating with identity logs. The point is not to chase one artifact, but to confirm that the session was established through an intermediary rather than directly with the legitimate service.

When AiTM Phishing Guide is used as the playbook, the practical focus is on the same pattern: token theft, session cookie theft, device code abuse, and phishing-resistant authentication as the defensive countermeasure. That makes it a strong reference point for tuning detections around relay-based phishing rather than broad email spam indicators.

How to investigate and contain it

Start by confirming whether the suspicious sign-in created a durable session or simply delivered a one-time prompt. If the account immediately accessed sensitive apps, created new OAuth grants, or began performing actions from a fresh endpoint, treat the event as a likely compromise path rather than a failed login attempt.

Containment should focus on invalidating what the attacker likely gained: active sessions, refresh tokens, remembered devices, and any delegated access that may persist after password reset. If the attacker used a reverse proxy to harvest authentication material, changing the password alone may not be enough.

Use identity logs, browser and endpoint telemetry, and mail or SaaS audit trails together. The most valuable question is not “Was MFA used?” but “Did the authenticated session originate and behave like the user’s normal environment after MFA completed?”

Risk and Threat Considerations

EvilProxy matters because it converts a real user interaction into a reusable access path. That means the exposure is often broader than the initial mailbox or SaaS login: once the token or session is replayed, the attacker can move with the user’s standing permissions and may evade password-based controls until the session is revoked.

Failure mechanism: The reverse proxy sits between the victim and the legitimate service, captures the live authentication exchange, and reuses the resulting session material before the defender sees a traditional account takeover signal.

Impact: Security teams can miss the intrusion if they only look for password changes or failed logins, while the attacker may already be operating inside trusted SaaS, email, or admin workflows with valid session state.

Practitioner Guidance

What to verify: Correlate every suspected EvilProxy alert with session lifecycle data, device posture, and recent authentication events. If the sign-in is legitimate but the session origin, browser fingerprint, or endpoint history is not, treat it as a compromise investigation, not a nuisance alert.

Decision rule: If the account touched sensitive systems after a fresh MFA event, prioritise session revocation and token invalidation before password hygiene tasks. If the same user later signs in again from a familiar device and location, compare both sessions to understand whether the proxy was the only abnormal element.

Practitioner takeaway: The best EvilProxy detection strategy is correlation, not a single indicator, because the kit is designed to make one authentication event look normal while the resulting session behaves abnormally.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?