Seventy-two spoofed sites, one phone call: which MFA factors survive a real-time proxy

The firms that were compromised had multi-factor authentication. That is the point of the incident, not an aside: the attack was designed against MFA, and the factors most commonly deployed are the ones it defeats.

Part of Private capital and fund identity

Prerequisites

• An inventory of authentication factors in use, by application, including the ones people forget: VPN, email, the CRM, the fund administration portal.
• Your incident response timeline from any prior credential compromise — specifically, time from credential capture to detection.
• A list of the actions that move money or data, and which authentication protects each.

Step 1 — Understand the attack as a relay

A real-time proxy sits between the user and the real service. The user believes they are on the login page. The proxy forwards everything to the genuine site and returns the genuine responses.

Whatever the user types, the proxy types. Whatever the service sends back, the user sees. The user's session cookie is issued to the proxy and the attacker inherits an authenticated session.

This is why enumerating factors by strength is the wrong exercise. The relevant question is not how strong a factor is; it is whether the user can transmit it.

Step 2 — Score your factors

The last row differs for a structural reason. An origin-bound credential signs an assertion tied to the domain requesting it. Presented with a proxy domain, it produces an assertion the real service will reject, or refuses to produce one at all. The user cannot transmit it wrongly because the credential will not cooperate.

Step 3 — Recognise what origin binding does not cover

This is where most deployments stop, and it is a mistake.

Origin binding protects the login. Once an attacker holds a session — through a stolen cookie, a compromised device, or a session issued before the upgrade — they act inside it. No further authentication is invoked, because the application does not ask.

For a firm whose applications can initiate transfers, that residual is the entire exposure.

Step 4 — Add the transaction layer

A per-transaction signature is session-independent by construction. The user signs a canonical statement of the specific action — amount, destination, date — and the assertion is meaningless for any other action.

Row three deserves a caveat. If the attacker controls the user's own device, they may be able to prompt for a signature the user approves believing it is theirs. That is a materially harder attack and it is not eliminated — rendering the transaction detail in the signing prompt is what gives the user a chance to notice.

Step 5 — Sequence the rollout

1. Start with the applications that can move money or expose LP data, not with email. Email is the largest surface and the least consequential single action.
2. Enrol two authenticators per user before enforcing anything. A single-authenticator rollout generates a help-desk surge that becomes its own social engineering surface.
3. Invalidate existing sessions at cutover. Sessions issued before the upgrade carry the old assurance.
4. Add transaction signing to transfer and instruction actions in the same programme, not as a later phase that never arrives.

Failure traps

• Leaving a fallback factor enabled for convenience. An attacker will select it, and the strongest factor in your stack becomes irrelevant.
• Exempting executives. They are the target set.
• Treating help-desk credential reset as out of scope. It is the path around everything above.
• Declaring victory after the login upgrade. The transaction layer is where the loss occurs.

Factor-by-factor survivability

Objections and honest limits

“Our staff are trained to spot spoofed domains.” Under a phone call from someone claiming authority, with a plausible reason and time pressure. Training is being asked to beat a professional who chose the moment.

“Origin binding solves it entirely.” It solves the ceremony. The session issued afterwards is an ordinary bearer token, and any fallback to a weaker factor is a path the attacker will steer toward.

Hardening against relay

1. Remove weaker factors once enrolment is complete. A fallback that exists will be induced.
2. Make recovery require an existing credential. Not a knowledge-based conversation.
3. Step up at consequential actions. So a relayed session yields browsing, not money movement.
4. Train on the call, not the page. The phone call is the part that actually works.

Terms used here

Real-time proxy

Phishing infrastructure that relays a live session between victim and genuine site, capturing tokens as they pass.

Origin binding

The property that an authenticator will only sign for the domain the credential was registered to.

Number matching

A push variant requiring the user to enter a number shown by the requesting site, which raises effort without closing relay.

Frequently asked questions

Is number matching not sufficient? No. The number is displayed by the proxy's session and relayed to the user, who matches it correctly. The mechanism assumes the user is looking at the legitimate site.

What about hardware OTP tokens? The code is a string the user types. A proxy relays strings. Possession of the token does not help if the code can be forwarded.

Does this mean we should remove all other factors? Eventually, for the applications in scope. Leaving a weaker fallback enabled means the attacker chooses it, which nullifies the upgrade.

How long does enrolment take per user? Minutes. The programme cost is coordination and help-desk readiness, not user time.

Do any shared-secret factors survive a relay? No. Anything the user can read out or type can be relayed within its validity window.

Does origin binding end the problem? It ends the ceremony attack. The session afterwards is a bearer token, and any weaker fallback is a path the attacker will steer toward.

What should training focus on? The phone call. That is the part that works, and the part staff can actually act on.

Sources and further reading

• FCC — protecting consumers from SIM swap and port-out fraud
• W3C Web Authentication Level 2
• CISA — Implementing phishing-resistant MFA
• Documented adversary-in-the-middle proxy phishing toolkits and techniques.
• W3C Web Authentication Level 3 — origin binding