What breaks when a fake checkout page relays the victim’s own approval in real time?

Why the Victim’s Own Approval Stops Proving the Merchant Is Real

A live relay turns the approval step into a proof of participation, not a proof of merchant authenticity. The victim may complete the OTP or app approval in good faith, but the attacker is relaying that approval into a separate session. The security question changes from “was the user involved?” to “was the transaction bound to the real destination and context?”

That distinction matters because out-of-band approval is often treated as a second factor, when in this pattern it is only a second channel. If the channel can be proxied in real time, the attacker can preserve the user’s apparent legitimacy while substituting the beneficiary, session, or payment context underneath it.

What Actually Breaks in the Trust Model

The broken assumption is transaction binding. The approval no longer confirms that the user saw the genuine checkout page, the genuine merchant, or the genuine amount and recipient. A relayed approval can satisfy the authentication step while leaving the transaction itself unconstrained.

In practice, that means the control proves something narrower than teams often assume. It may still confirm possession of a device or interaction with an authenticator, but it does not necessarily confirm that the action is being authorised against the intended merchant session. Authentication assurance and transaction integrity have to be designed together, especially for high-value purchases, payments, and account recovery flows.

Where Defenders Need Stronger Binding and Context Checks

Controls should focus on whether the approval is cryptographically or procedurally tied to the exact transaction details the user is meant to approve. If the approval UI does not surface the merchant, amount, and destination clearly enough to resist relay, the step is vulnerable to consent laundering. The stronger the economic value of the action, the more important it becomes to bind approval to the specific transaction state rather than to a generic login or prompt.

For payment-related fraud patterns, this is the same practical issue that appears in authorised push payment scams, where the victim is manipulated into approving a transfer that benefits the attacker. NHIMG’s Authorised Push Payment (APP) Fraud Guide is useful here because it covers the controls around confirmation, mule detection, and scam friction that become relevant once a user’s approval can be socially or technically relayed.

When transaction context is weak, even otherwise legitimate approvals become ambiguous. A secure design should make it hard for the victim to approve one context while the attacker executes another, because that gap is exactly where the relay attack succeeds.

Risk and Threat Considerations

This pattern is dangerous because it preserves the appearance of a valid user action while severing the link between the user’s intent and the executed transaction. That makes it especially effective against workflows that rely on OTPs, push approvals, or “is this you?” prompts without binding those approvals to the exact merchant or payment details.

Failure mechanism: The attacker proxies the challenge in real time, captures the victim’s approval, and applies it to a different session or destination before the control can detect the substitution.

Impact: The organisation may treat an attacker-controlled transaction as user-authorised, which increases fraud loss, weakens step-up authentication value, and can bypass controls that were designed to detect a separate login rather than a relayed action.

Practitioner Guidance

What to verify: Check whether the approval screen or message binds to the exact merchant, amount, account, and action being authorised. If those details are absent, truncated, or easy to mirror, the control is not strong enough to rely on as transaction confirmation.

Decision rule: If the approval can be replayed, proxied, or relayed without the user seeing a uniquely bound transaction summary, treat it as a vulnerable step and add stronger binding, out-of-band risk checks, or secondary fraud controls before trusting it for high-risk actions.

Practitioner takeaway: The key design failure is assuming that user participation equals transaction legitimacy; in relay attacks, the control must prove both the user and the exact transaction context, or it only proves that someone approved something.

Related resources from NHI Mgmt Group

• What breaks when teams only manage agent permissions at approval time?
• What breaks when AI agent access is not re-evaluated in real time?
• What breaks when MCP approval is treated as a one-time consent step?
• What breaks when just-in-time access is used as a substitute for real privilege reduction?