Bypass Azure MFA with Evilginx

What this lab covers

You configure a reverse-proxy phishing environment, capture a session for a target identity after they authenticate normally, and use the resulting tokens to enumerate and act within the tenant.

The lab exists to make one point concrete: rolling out MFA and considering phishing solved is a mistake many organizations have made. Seeing the token survive the challenge changes how people think about their authentication roadmap.

It suits red teamers and identity engineers. If you are responsible for conditional access or an MFA rollout, this is the attack your design needs to survive.

How adversary-in-the-middle phishing works

A reverse-proxy phishing framework sits between the victim and the real service. It forwards every request to the genuine site and returns genuine responses, so the victim sees the real login page because it is the real login page, relayed.

Because the traffic is real, the multi-factor challenge is real and the victim completes it legitimately. What the proxy captures is the session cookie or token issued afterwards, which is the artifact that actually represents an authenticated session.

Replaying that token requires no password and triggers no new challenge, because as far as the identity provider is concerned the session is already authenticated. The attacker inherits the session and, depending on the token, may be able to refresh it and maintain access well beyond the original sign-in.

How to detect this in your own environment

Look for the same session or token characteristics appearing from two different network locations. A session established from one address and used from another is the clearest available signal, and it is visible in sign-in logs.

Watch for sign-ins where the domain the user reached is not one of yours. Phishing infrastructure often shows up as unusual referrer or application behavior, and newly registered lookalike domains are worth monitoring proactively.

Treat impossible travel and unfamiliar sign-in properties as higher severity than usual for accounts with privileged roles. These heuristics are noisy in general and much more meaningful when the account matters.

How to prevent it

Deploy phishing-resistant authentication. FIDO2 security keys, passkeys and certificate-based authentication bind the credential to the legitimate origin, so a proxied site cannot complete the ceremony at all. This defeats the technique outright rather than making it harder.

Use conditional access to require compliant or hybrid-joined devices for sensitive applications. A stolen token used from unmanaged infrastructure then fails the device condition even though the token itself is valid.

Enable token protection where available, which binds a token to the device it was issued to. Combined with continuous access evaluation, this shortens the window in which a stolen token remains useful.

Real-world context

Adversary-in-the-middle phishing kits are widely available as a service, and Microsoft and other vendors have reported large campaigns using them against organizations that had multi-factor authentication enabled. The technique became prevalent precisely because MFA adoption made simple credential phishing less effective.

The industry response has been to distinguish phishing-resistant factors from the rest. App-based approval and one-time codes protect against password reuse and simple credential theft, and do not protect against a proxy that relays the entire exchange.

The pattern maps to MITRE ATT&CK T1557 Adversary-in-the-Middle, T1539 Steal Web Session Cookie and T1078.004 Cloud Accounts.

Applying this at work

• Identify which of your users hold privileged roles and move them to phishing-resistant authentication first.
• Add a conditional access requirement for compliant devices on your most sensitive applications.
• Query sign-in logs for sessions used from more than one network location.
• Monitor for newly registered domains resembling your own, which is where this infrastructure is usually hosted.
• Review whether your MFA rollout plan distinguishes phishing-resistant factors from the rest. Many do not.

Frequently asked questions

Does Evilginx break multi-factor authentication?

No. It relays the genuine authentication, including the MFA challenge, and captures the session token issued afterwards. The token represents a completed challenge, so replaying it does not prompt for another factor.

Which MFA methods resist this attack?

Phishing-resistant methods that bind the credential to the origin: FIDO2 security keys, passkeys and certificate-based authentication. Push approvals and one-time codes do not, because they can be relayed like anything else.

How would I detect a stolen session token being used?

The strongest signal is a session established from one network location and subsequently used from another. Device compliance conditions also cause stolen tokens to fail when replayed from unmanaged infrastructure.

Do I need my own Azure account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.