How should security teams detect man-in-the-middle proxy attacks on login flows before credentials are stolen?

Why Proxy Interception During Login Is a Detection Problem, Not Just an Authentication Problem

A man-in-the-middle proxy attack on a login flow sits in the gap between a valid user intent and a compromised delivery path. The user may still enter correct credentials, but the session can be relayed through an attacker-controlled proxy that captures secrets or tokens before the identity provider finishes authenticating. That is why the practical question is not only whether the login is successful, but whether the browser session originated from an expected domain and reached the right authentication surface.

Security teams should treat this as a trust-boundary issue across the browser, the login page, and the identity provider. The most useful detection logic is often lightweight but specific: identify whether the login flow is being rendered or relayed from an approved domain and whether the expected page context is intact. CISA’s current threat advisories are useful for understanding how initial access and credential theft are commonly operationalised, but the control here must be applied at the point where login traffic can be inspected, not after account takeover has already occurred.

In practice, many security teams only discover proxying after users report unusual MFA prompts, suspicious purchases, or session anomalies rather than through deliberate visibility into the login path.

How Login-Flow Proxy Detection Works in Practice

The core idea is to make the login flow attest to where it is being delivered. A detection token or comparable marker is placed in the website or identity provider login page and constrained to approved domains. If the page is fetched or relayed through an unexpected origin, the login flow can be flagged before a credential exchange completes. This does not stop every attack on its own, but it gives defenders a signal that the authentication transaction is being mediated through infrastructure they did not intend to trust.

That signal works best when it is paired with additional context from the browser session and the authentication transaction. Teams should correlate the page origin, the application being accessed, the user’s expected sign-in path, and any unusual redirects or embedded content. A proxy attack often depends on preserving the look and feel of the legitimate flow, so a control that only checks for successful login is too late. A control that checks whether the login context matches the approved delivery path can identify interception while the attacker is still between the user and the identity provider.

• Use a domain-bound marker or token on the login page so the page can verify it is being served from an approved origin.
• Correlate the login event with the expected application and redirect chain so unexpected relay paths are visible.
• Alert on mismatches between the observed domain, the intended identity provider, and the authenticated application.
• Preserve enough telemetry to distinguish a proxying attempt from a normal sign-in failure, because the response path is different.

MITRE ATT&CK is useful here because the behaviour maps closely to credential interception, adversary-in-the-middle activity, and subsequent account access patterns. Where login flows are central to business access, the detector should be tuned to the earliest trustworthy proof of domain integrity, because later checks may only show that the attacker already succeeded.

This guidance breaks down when the proxy preserves all visible web signals and the organisation has no reliable way to bind the login page to the intended delivery origin.

When the Standard Answer Needs Extra Care

Tighter login-flow inspection often increases engineering and operational overhead, so organisations must balance stronger origin checks against deployment complexity and false positives. That tradeoff is most visible in federated environments, embedded sign-in widgets, and multi-tenant identity setups where legitimate redirects can look unusual if the allowlist is too narrow.

One important edge case is that not every suspicious login relay is a full credential theft attempt. Some are phishing kits, some are session-hijack workflows, and some are simply broken integrations that alter the expected domain path. The useful distinction is whether the control can still prove that the login page was delivered through a domain the team intended to trust. Where the answer is no, the event deserves investigation even if the user ultimately authenticates.

Security teams should also be careful not to treat this as a replacement for phishing-resistant authentication. Domain-bound detection reduces exposure, but it does not eliminate the value of MFA fatigue protection, session binding, or stronger authentication methods. The most defensible posture is layered: detect suspicious proxying early, then ensure the credential or token that follows is not enough by itself to complete account takeover.

Practitioner takeaway: The control is most valuable when it proves delivery-path integrity early enough to change the response, not when it merely confirms that a login eventually completed.

Risk and Threat Considerations

Proxy attacks on login flows create a direct credential interception and session-abuse risk. The attacker’s objective is to sit between the user and the legitimate authentication service, capture secrets or tokens, and reuse them before the defender notices. That risk is especially material when the organisation relies on web sign-in as the first trust decision for customer accounts, workforce access, or privileged administrative sessions.

Failure mechanism: The attack works when the victim trusts a lookalike login surface or when the browser session is relayed through infrastructure that preserves the appearance of legitimacy. If the control only validates successful authentication, the organisation may miss the interception entirely because the credential exchange still appears normal from the back end.

Impact: Stolen credentials, replayable session artefacts, account takeover, and unauthorised transactions can follow before revocation or reset occurs. In higher-value environments, the same mechanism can expose sensitive applications, create downstream lateral access, and undermine confidence in the identity provider’s login path.

Practitioner Guidance

What to prioritise: Verify the login page origin first, then decide whether the observed flow matches the approved identity path. If the page cannot be tied to a trusted domain, treat the event as a pre-compromise warning rather than a routine authentication anomaly.

What to verify: Confirm that the detection token is actually bound to the intended login surface and cannot be reused across mirrored pages, embedded frames, or alternate hostnames. Teams often overestimate the value of a marker that is visible but not meaningfully constrained.

Common mistake: Relying on post-authentication account controls alone. By the time unusual purchases, MFA prompts, or session reuse appear, the proxy has usually already served its purpose.

What good looks like: The security team can rapidly distinguish an ordinary failed sign-in from a proxied sign-in attempt, identify the affected application, and escalate before the captured credential is reused.

Practitioner takeaway: The best detection logic does not try to guess intent from the password event itself; it proves whether the user reached the real login surface.

Related resources from NHI Mgmt Group

• How should security teams detect and respond to browser-based identity attacks before attackers turn stolen credentials into account takeover?
• How should security teams prevent man-in-the-middle attacks on remote access?
• How should security teams prevent man-in-the-middle attacks in modern applications?
• How should security teams detect AI-orchestrated attacks before exfiltration starts?