Adversary-in-the-middle and real-time OTP relay

Series 2 explained why real-time phishing defeats every code a human can type. This chapter takes the same attack and treats it as a threat-model entry: who runs it, what it needs, what it leaves behind, and which controls move its severity. The goal is to give Pinecrest a defensible plan for the years during which most of its patients will still sign in with a password and a code.

The relay as an actor

An adversary-in-the-middle (AiTM) kit is a reverse proxy configured for your site. Its operator registers a lookalike domain, obtains a TLS certificate automatically, and sends lures by email or text. When a victim arrives, the proxy fetches your real pages and rewrites links so that all traffic flows through it. Credentials and codes pass through untouched; the session cookie your server issues is captured and replayed from the operator’s infrastructure. Modern kits automate the post-login steps, so the attacker can act within seconds.

Signals at login

Most proxies run on cloud or hosting infrastructure. Requests that complete a login from a data-centre autonomous system, rather than a residential or mobile network, are a useful risk signal — not a block, because some legitimate users sit behind corporate proxies and privacy relays. Client fingerprinting at the TLS and HTTP layer can also reveal that the client is an automated proxy rather than the browser it claims to be. Both signals degrade as kits improve, so treat them as score inputs with decay, not as rules.

A more durable signal is the origin. Some proxies fail to rewrite every header or every script, and your pages can include a small check that compares the current location with the expected host and reports a mismatch to your servers. This is an arms race, but it is cheap, and the reports give you the lookalike domain names to submit for takedown.

Signals after login

Phase two is where the attacker is weakest. The captured cookie is typically used from a different IP, sometimes in a different country, with a different client fingerprint than the one that completed the login. Binding sessions to properties of the client that authenticated — a device-bound key, or at minimum a coarse fingerprint and network — lets you detect this and force re-authentication. Device-bound session credentials, where the browser holds a private key and proves possession on refresh, make stolen cookies far less useful and are worth adopting where supported.

// Pseudocode: flag sessions reused from a new context shortly after login
on request(session, ctx):
  if now - session.issuedAt < 15 min
     and ctx.asn != session.loginAsn
     and ctx.clientFp != session.loginClientFp:
       session.require("step-up", reason = "context_shift_after_login")

Controls that change the outcome

The controls above change the odds. They catch some proxies some of the time. The controls that change the outcome are the ones from series 2: origin-bound authenticators for the actions that matter. At Pinecrest, viewing lab results is allowed after password and OTP, but changing contact details, adding a payment method or downloading the full record requires a passkey step-up. A relayed session can see one result and nothing more; the threat moves from critical to medium without forcing every patient to adopt passkeys on day one.

• Step-up with a passkey for contact, payment and credential changes.
• Short-lived sessions after OTP-only login, with silent refresh tied to the original client.
• Context-shift detection that forces re-authentication, not just logging.
• Takedown process for lookalike domains reported by your origin check.

An illustrative example from Pinecrest’s first month with these controls: the origin check reported nine lookalike hosts; four were taken down within a day. Context-shift detection challenged 212 sessions, of which a manual sample suggested roughly a third were relays and the rest mobile users switching networks. Those numbers are invented for teaching, but the shape is typical: detection is noisy, and the step-up requirement is what actually protects the asset.

Recording it in the model

In the threat register, AiTM relay against OTP-only login is inherently critical for any account that can change its own recovery details. With passkey step-up for those changes, residual risk is medium: attackers can still read whatever OTP-level sessions can read. With detection alone and no step-up, residual stays high. Write all three down. Leadership needs to see that detection buys time while step-up buys safety.

Consider also what the relay cannot easily fake. It cannot produce a passkey assertion for your origin, it cannot read cookies scoped to your real domain from the victim's browser, and it cannot prevent your server from sending a sign-in notification to the email address already on file. Each of those is a lever. Sign-in notifications in particular are underrated: they cost almost nothing, they arrive while the attacker is still inside the session, and a clear report link turns the victim into your fastest detector.

Keep a short runbook for confirmed relay campaigns: kill sessions created from the reported infrastructure, force password resets for affected accounts, submit takedown requests, and add the kit's fingerprints to detection. Speed matters more than completeness in the first hour.