What happens when users enter credentials into a fake login page that proxies a real identity provider session?

The attacker can capture credentials and session material in real time, then reuse that trusted session to bypass traditional password and MFA checks. That turns a simple login theft into account takeover, with access that may persist until the session is revoked. The operational risk is not just compromise of one account, but possible lateral movement into connected business applications.

How Proxy Login Theft Works

A fake login page that proxies a real identity provider does more than collect a password. It relays the victim’s interaction to the legitimate service in real time, which can capture MFA codes, session cookies, and token-bearing responses as they are issued. That makes the attack especially effective against organisations that assume a successful password check means the user is genuine.

The security problem is the reuse of trusted session material. Once the attacker has the live session, the protected application often sees an authenticated browser, not a stolen credential, so traditional password policy and one-time MFA prompts lose most of their value. This is why phishing-resistant authentication and session-bound controls matter more than password complexity alone.

For practitioners, the key point is that the attack turns identity proofing into session theft, then converts that trust into downstream application access. OWASP Non-Human Identity Top 10 is useful here because the same credential and token handling mistakes that expose machine identities also weaken session security around user-facing authentication flows. In practice, many security teams discover the compromise only after a valid session has already been used inside a business application, not while the fake page is still collecting the login.

What Makes the Attack Hard to Stop

The attack works because it preserves the normal sequence of trust. The victim sees a familiar login experience, the identity provider still completes authentication, and the attacker simply interposes themselves between the user and the service. If the proxy is fast enough, it can relay MFA challenges, capture the resulting token or cookie, and immediately reuse it before the session ages out or the user notices anything unusual.

In practice, defenders need to think in terms of session binding, token replay resistance, and post-authentication monitoring rather than only front-door authentication. Controls that help include phishing-resistant MFA, conditional access based on device or context, short-lived sessions, and revocation workflows that can invalidate active tokens quickly when suspicious activity appears. Logging is also important because account takeover often becomes visible only through unusual access paths, impossible travel, or application-level actions that do not match the user’s typical pattern.

• Use authentication methods that resist real-time relay, not just methods that prove the user knows a secret.
• Treat active session tokens as sensitive credentials that can be stolen and reused.
• Look for rapid post-login access to mail, cloud apps, or admin consoles from a new context.
• Make revocation fast enough that stolen sessions do not remain useful for long.

Ultimate Guide to NHIs — Static vs Dynamic Secrets is relevant because the same short-lived versus long-lived trust trade-off applies to sessions: the shorter and more context-bound the trust artifact, the less time an attacker has to reuse it. These controls tend to break down in legacy single sign-on environments where sessions are long-lived, token revocation is inconsistent, and downstream applications trust the parent identity provider too blindly.

Where False Confidence Creeps In

Tighter login controls often increase user friction and operational overhead, so organisations have to balance convenience against the value of replay-resistant authentication. There is no universal standard for every environment, but current guidance suggests treating the login page as only one part of the control plane, not the whole defence.

One common mistake is to assume MFA alone solves phishing. It helps against simple credential theft, but not against adversary-in-the-middle proxying that captures the authenticated session. Another gap appears when teams protect the front door but leave high-value applications exposed to any valid session without additional checks. That is where the attacker turns a single successful login into broader access.

Ultimate Guide to NHIs is useful for the wider lifecycle lesson: if identity artifacts are not rotated, monitored, and revoked with discipline, compromise persists longer than most incident teams expect. The practical takeaway is to measure how quickly a suspicious session can be detected and killed, not just whether the initial authentication step was “strong.”

Risk and Threat Considerations

This attack creates account takeover risk because it bypasses the normal trust model after authentication has succeeded. The exposed asset is not only the password but the live session, which can grant continued access to email, SaaS tools, and administrative functions until the session is invalidated.

Failure mechanism: An adversary-in-the-middle proxy relays authentication between the user and the real identity provider, captures the issued token or cookie, and reuses it inside the legitimate service. The control weakness is that many applications trust a valid session too broadly and do not require a fresh proof of possession once the session exists.

Impact: The attacker can operate as the user, pivot into connected applications, and persist until detection or revocation. In environments with weak session monitoring, that can turn a single login theft into wider compromise across business systems.

Practitioner Guidance

What to verify: Confirm whether your strongest authentication method is actually phishing-resistant, or whether it still allows real-time relay through a proxy. If sessions can be replayed from a new device or location without additional checks, treat that as a material exposure.

What to prioritise: Focus first on the accounts and applications where a stolen session creates the largest blast radius, especially admin, finance, and email access. Those are the places where a short-lived compromise still has outsized consequences.

Decision rule: If the account can reach privileged business applications, session revocation speed matters more than whether the initial login looked legitimate. If revocation is slow or inconsistent, assume the attacker has a usable window even after detection.

Practitioner takeaway: The real control objective is not to block every login attempt, but to make stolen sessions difficult to replay, easy to spot, and fast to revoke.

Related resources from NHI Mgmt Group

• What happens when a user enters credentials into a phishing page hidden behind a reverse proxy?
• What happens when Snowflake credentials are compromised and attackers begin working from a legitimate session?
• What is the difference between a typosquatted login page and a legitimate identity provider?
• What happens when users can still interact with a cloned login page before detection kicks in?