How it works
A reverse proxy sits between victim and service, forwarding every step of a genuine login and capturing the resulting session token. Alternatively, repeated approval prompts — sometimes with a supporting phone call — pressure the user into accepting a login they did not initiate.
The factor is not the target
Multi-factor authentication substantially reduced credential-based takeover, and attackers responded not by breaking the factor but by declining to attack it.
Both techniques here leave the factor intact and working correctly. In a relay attack the user completes a genuine challenge; in a fatigue attack the user approves a genuine prompt. In neither case is any cryptography defeated. What is defeated is the assumption that a satisfied factor implies an authorised login.
That distinction matters for remediation. Adding a second factor to a system already using one accomplishes nothing against either technique. The change that helps is a different kind of factor, or controls that continue evaluating after authentication succeeds.
Real-time relay
A relay attack places attacker infrastructure between the victim and the real service. The victim visits what appears to be the login page; every request is forwarded to the genuine site and every response returned, so the experience is authentic because it is authentic.
The victim enters their password, which is captured in transit. The real service issues a genuine MFA challenge, which is relayed and answered. The service, satisfied, issues a session token — to the proxy.
That token is the prize. It represents a fully authenticated session and carries no memory of how it was obtained. The attacker imports it and is logged in, with no further need for the password or the factor. This is why the technique defeats time-based codes and push approval equally: neither is bound to the site the browser is actually talking to.
It also explains why password resets are an inadequate response. If the session token remains valid, the attacker retains access through a credential the user cannot change. Revoking sessions is the necessary step and the one most often skipped.
Why origin binding is the answer
Passkeys and hardware security keys defeat relay structurally rather than probabilistically, and the reason is worth stating precisely.
The authenticator signs a challenge that includes the origin requesting it. When a proxy is in the path, the origin is the proxy's domain, not the real service's. The signature the authenticator produces is therefore valid for the wrong origin, and the real service rejects it. The user does not have to notice anything; the relay simply cannot produce a usable assertion.
This is a categorical difference from every other factor. A code can be read aloud, typed into the wrong page, or forwarded. A push approval can be granted for a login the user did not start. An origin-bound credential cannot be used anywhere except the site it was created for, which removes the human from the security decision entirely.
Push fatigue
Fatigue attacks require a valid password and a push-based factor. The attacker authenticates repeatedly, generating a stream of approval prompts, and waits for one to be accepted.
It is tempting to attribute success to carelessness. In practice the prompts arrive with no context — no indication of where the login originated or what application requested it — at inconvenient hours, and repeatedly. Approving to stop the interruption is a rational response to a notification that communicates nothing actionable.
Effectiveness increases sharply when paired with a phone call impersonating internal support, explaining the prompts as a system issue and asking the user to approve. The prompt is then not merely uninformative but actively explained by someone who sounds legitimate.
Number matching is the most effective inexpensive fix: requiring the user to enter a number displayed on the login screen means an approval cannot be granted by someone who cannot see it. Adding location, application and requesting address turns a reflex into a decision. Rate limiting repeated prompts and alerting on the pattern closes the remainder.
Detection and response
Both techniques end with a valid session, so detection has to look past the authentication event.
- Repeated denied or ignored prompts followed by an approval — the signature of a fatigue attack, and visible in authentication logs.
- A session whose network or device characteristics change abruptly after issuance, which is what token import looks like.
- Authentication succeeding from a location or device with no history, particularly shortly after a message was delivered.
- Impossible travel between sessions, still useful despite the noise it generates.
- Post-login sequences that indicate takeover: factor enrolment, recovery-address changes, mailbox rule creation.
- And in response: revoke sessions, not just credentials. A password reset that leaves a stolen token valid has not ended the intrusion.
Also known as
What defenders may observe
- A new session appears immediately after a phishing visit
- MFA succeeds but the legitimate user does not hold the session
- Token use shifts device, network or region abruptly
- Many denied or ignored push prompts precede an approval
- Login originates from an unfamiliar device or region
Prevention and mitigation
- Deploy passkeys or hardware keys — origin binding is what defeats relay
- Enable number matching and show location and application in prompts
- Rate-limit and alert on repeated push prompts to one user
- Bind session tokens to device characteristics where practical
- Evaluate session risk continuously rather than only at login
- Provide a one-tap route for users to report an unsolicited prompt
Initial response priorities
- Revoke sessions and reset the affected authentication factors.
- Review identity-provider and mailbox audit logs.
- Verify sensitive requests through a separate trusted channel.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.