{
 "slug": "factor-survivability-finance",
 "topic_id": "TOPIC-177",
 "cluster": "Private Capital, Funds & Wealth Management Identity",
 "tier": "Tier A",
 "title": "Seventy-two spoofed sites, one phone call: which MFA factors survive a real-time proxy",
 "summary": "In 2026 attackers telephoned staff at large private equity firms and funnelled them into dozens of spoofed authentication sites where codes were captured in real time. Every shared-secret and push-based factor fell.",
 "lede": "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.",
 "date": "2025-12-20",
 "category": "Comparison",
 "author_id": "nadia-ferreira-strand",
 "tags": [
  "phishing resistant MFA",
  "vishing",
  "adversary in the middle",
  "private equity",
  "passkeys",
  "origin binding"
 ],
 "image_title": "Factor Survivability Finance",
 "schema": "Article",
 "key_takeaways": [
  "A real-time proxy relays whatever the user provides. Any factor the user can transmit is a factor the attacker can forward.",
  "Origin binding solves the login. It does not solve the transaction, because a compromised session does not require another login.",
  "Two layers are needed: origin-bound credentials for authentication, and per-transaction signing for the money."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Prerequisites"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "A phone call, a spoofed site and a relayed code",
   "caption": "The victim authenticates correctly. The proxy relays it.",
   "nodes": [
    {
     "label": "Phone call primes the target",
     "note": "authority and urgency",
     "bad": true
    },
    {
     "label": "Directed to a spoofed site",
     "note": "one of dozens",
     "bad": true
    },
    {
     "label": "Code entered",
     "note": "relayed in real time",
     "bad": true
    },
    {
     "label": "Session established",
     "note": "attacker holds it",
     "bad": true
    }
   ]
  },
  {
   "type": "ul",
   "items": [
    "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."
   ]
  },
  {
   "type": "h2",
   "text": "Step 1 — Understand the attack as a relay"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Step 2 — Score your factors"
  },
  {
   "type": "table",
   "caption": "Survives = the attacker still cannot complete authentication. The middle column is the deciding property.",
   "head": [
    "Factor",
    "Can the user transmit it?",
    "Survives real-time proxy"
   ],
   "rows": [
    [
     "Password",
     "Yes",
     "No"
    ],
    [
     "SMS one-time code",
     "Yes",
     "No"
    ],
    [
     "Authenticator app code",
     "Yes",
     "No"
    ],
    [
     "Push approval",
     "Effectively — they tap for a prompt the proxy triggered",
     "No"
    ],
    [
     "Push with number matching",
     "Effectively — the number comes from the proxy's session",
     "No"
    ],
    [
     "Hardware OTP token",
     "Yes",
     "No"
    ],
    [
     "Origin-bound credential (passkey / FIDO2)",
     "<strong style=\"font-weight:600\">No</strong>",
     "<strong style=\"font-weight:600\">Yes</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Step 3 — Recognise what origin binding does not cover"
  },
  {
   "type": "p",
   "html": "This is where most deployments stop, and it is a mistake."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "For a firm whose applications can initiate transfers, that residual is the entire exposure."
  },
  {
   "type": "h2",
   "text": "Step 4 — Add the transaction layer"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "table",
   "head": [
    "Attack",
    "Origin-bound login",
    "Per-transaction signing"
   ],
   "rows": [
    [
     "Credential phishing via proxy",
     "Blocks",
     "n/a"
    ],
    [
     "Stolen session cookie replay",
     "Does not block",
     "Blocks"
    ],
    [
     "Compromised endpoint with active session",
     "Does not block",
     "Blocks unless the device itself signs"
    ],
    [
     "Insider with legitimate access",
     "Does not block",
     "Attributes the action to them"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Step 5 — Sequence the rollout"
  },
  {
   "type": "ol",
   "items": [
    "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.",
    "Enrol two authenticators per user before enforcing anything. A single-authenticator rollout generates a help-desk surge that becomes its own social engineering surface.",
    "Invalidate existing sessions at cutover. Sessions issued before the upgrade carry the old assurance.",
    "Add transaction signing to transfer and instruction actions in the same programme, not as a later phase that never arrives."
   ]
  },
  {
   "type": "h2",
   "text": "Failure traps"
  },
  {
   "type": "ul",
   "items": [
    "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."
   ]
  },
  {
   "type": "h2",
   "text": "Factor-by-factor survivability"
  },
  {
   "type": "table",
   "caption": "Against a real-time proxy",
   "head": [
    "Factor",
    "Survives?",
    "Why"
   ],
   "rows": [
    [
     "SMS or voice code",
     "No",
     "A bearer secret with no context"
    ],
    [
     "TOTP application",
     "No",
     "Relayable within the window"
    ],
    [
     "Push approval",
     "No",
     "The user approves the proxy's login"
    ],
    [
     "Push with number matching",
     "Partly",
     "Raises effort; the number is displayed on the proxy page"
    ],
    [
     "<strong style=\"font-weight:600\">Origin-bound assertion</strong>",
     "<strong style=\"font-weight:600\">Yes</strong>",
     "<strong style=\"font-weight:600\">The browser will not sign for the wrong domain</strong>"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Our staff are trained to spot spoofed domains.”</strong> 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."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Origin binding solves it entirely.”</strong> 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."
  }
 ],
 "faq": [
  {
   "q": "Is number matching not sufficient?",
   "a": "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."
  },
  {
   "q": "What about hardware OTP tokens?",
   "a": "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."
  },
  {
   "q": "Does this mean we should remove all other factors?",
   "a": "Eventually, for the applications in scope. Leaving a weaker fallback enabled means the attacker chooses it, which nullifies the upgrade."
  },
  {
   "q": "How long does enrolment take per user?",
   "a": "Minutes. The programme cost is coordination and help-desk readiness, not user time."
  },
  {
   "q": "Do any shared-secret factors survive a relay?",
   "a": "No. Anything the user can read out or type can be relayed within its validity window."
  },
  {
   "q": "Does origin binding end the problem?",
   "a": "It ends the ceremony attack. The session afterwards is a bearer token, and any weaker fallback is a path the attacker will steer toward."
  },
  {
   "q": "What should training focus on?",
   "a": "The phone call. That is the part that works, and the part staff can actually act on."
  }
 ],
 "sources": [
  {
   "t": "FCC — protecting consumers from SIM swap and port-out fraud",
   "u": "https://www.fcc.gov/sim-swap-port-out-fraud"
  },
  {
   "t": "W3C Web Authentication Level 2",
   "u": "https://www.w3.org/TR/webauthn-2/"
  },
  {
   "t": "CISA — Implementing phishing-resistant MFA",
   "u": "https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa"
  },
  {
   "t": "Documented adversary-in-the-middle proxy phishing toolkits and techniques."
  },
  {
   "t": "W3C Web Authentication Level 3 — origin binding",
   "u": "https://www.w3.org/TR/webauthn-3/"
  }
 ],
 "related": [
  {
   "slug": "red-flag-survivability",
   "title": "Regulation S-ID is a detection rule",
   "category": "Vertical"
  },
  {
   "slug": "clinical-action-gate-infostealers",
   "title": "Assume the credentials are already stolen",
   "category": "Comparison"
  },
  {
   "slug": "capital-call-receipt",
   "title": "The capital call nobody can verify",
   "category": "Vertical"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Factor%20Survivability%20Finance/1200_630/blog.jpg",
 "wordcount": 969,
 "url": "/blog/factor-survivability-finance.html",
 "reading_time": "4 min read",
 "seo_title": "Which MFA factors survive a real-time phishing proxy",
 "meta_description": "Attackers telephoned staff at private equity firms and funnelled them into dozens of spoofed sites where codes were captured in real time.",
 "hub": {
  "slug": "topics/private-capital-identity",
  "title": "Private capital and fund identity"
 },
 "answer": "Only origin-bound ones. In 2026 attackers telephoned staff at large private equity firms and funnelled them into dozens of spoofed authentication sites where codes were captured in real time. Every shared-secret and push-based factor fell; a factor the browser scopes to the real domain did not.",
 "answer_q": "Which MFA factors survive a real-time phishing proxy?",
 "glossary": [
  {
   "term": "Real-time proxy",
   "def": "Phishing infrastructure that relays a live session between victim and genuine site, capturing tokens as they pass."
  },
  {
   "term": "Origin binding",
   "def": "The property that an authenticator will only sign for the domain the credential was registered to."
  },
  {
   "term": "Number matching",
   "def": "A push variant requiring the user to enter a number shown by the requesting site, which raises effort without closing relay."
  }
 ],
 "checklist": {
  "title": "Hardening against relay",
  "id": "harden",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Remove weaker factors once enrolment is complete.",
    "text": "A fallback that exists will be induced."
   },
   {
    "name": "Make recovery require an existing credential.",
    "text": "Not a knowledge-based conversation."
   },
   {
    "name": "Step up at consequential actions.",
    "text": "So a relayed session yields browsing, not money movement."
   },
   {
    "name": "Train on the call, not the page.",
    "text": "The phone call is the part that actually works."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav binds the authorising individual to the exact record change or instruction, and produces a receipt a custodian, a transfer agent or a regulator can verify without calling the issuer.",
  "href": "../docs.html",
  "label": "See instruction receipts"
 }
}