Device-bound MFA stops UNC6671 vishing AiTM

Help desk called the trader on a personal cell about an urgent passkey update. UNC6671 left with Microsoft 365 and Okta sessions.

According to BleepingComputer, citing Google Threat Intelligence Group, UNC6671 operators called hedge-fund and private-equity employees on personal mobiles, spoofed corporate IT numbers, claimed an urgent passkey or MFA update, and steered them to company-branded adversary-in-the-middle sites. Those sites harvested passwords, live MFA codes or push approvals, and session cookies for Microsoft 365 and Okta. More than $10.6 million in Bitcoin already sat in group wallets before the finance wave peaked.

Human judgment on a cold call is not a control. Remove the secrets a stranger can coach you to type or approve, and that call has nowhere to land.

Why coached AiTM logins beat OTP and push

Public reporting names Point72 Asset Management, Millennium Management, Two Sigma Investments, Citadel, Blackstone, KKR, and Apollo among firms in the Wall Street targeting shift. Impact was uneven. Point72 reported an attack and said it found no evidence client data was stolen. Two Sigma reported a blocked attempt with no indication systems or data were affected. Millennium and Citadel declined comment. Mandiant has assisted several dozen organizations compromised in the broader UNC6671 activity.

The failure starts before any cookie exists. Operators dialed personal mobiles while spoofing helpdesk caller IDs and sold an urgent identity task: enroll a passkey, update MFA, finish a required change before access broke. That voice channel sits outside secure email gateways, browser isolation, and managed-endpoint prompts. Trust is borrowed from real IT culture. The victim is already socially committed before the browser opens.

An adversary-in-the-middle attack is a reverse proxy between the user and the real identity provider that copies passwords and second factors as the legitimate login completes. On the branded reverse-proxy page, the user typed a password and satisfied a transferable second factor. App OTP codes, SMS codes, and push approvals all produce secrets or approvals a live proxy can capture or relay. The real Microsoft 365 or Okta ceremony can complete through the attacker's pipe. At that moment authentication is still the prize. The attacker is not yet replaying a finished session. They are finishing the login as the user.

Persistence came next. After live interception, attackers added authenticators they controlled. Later access no longer needed the victim on the call. That is still a credential and enrollment failure. Only after those wins did session cookies and SSO tokens become easy multi-app keys without a fresh challenge at each app.

According to Austin Larsen of Google Threat Intelligence Group (GTIG), between January and May 2026 the group's wallets received over $10.6 million USD in Bitcoin. Initial demands often reached about $3 million and routinely settled near $750,000. GTIG assesses a single core intrusion set behind helpdesk vishing and cloud theft across brands including Redact, Pink, Helix, and Falcon after earlier BlackFile operations, while Falcon publicly disputed shared-umbrella claims with Helix and Pink. GTIG tracks the infrastructure as UNC6671 and distinguishes it from Scattered Spider even while noting tactical similarity.

The problem with vishing is that it depends on the judgement of a human. We have the same problem with credential phishing. Humans make mistakes. Training does not close that. Detection does not close that. Prevention does.

For the attack-side walkthrough, see the related post on legacymfa.sucks: how UNC6671 used helpdesk vishing and AiTM to steal hedge fund MFA sessions.

How phishing-proof MFA 2.0 stops the call from mattering

Stop the kit at the login and enrollment it tried to complete. Device-bound credentials use public-key cryptography on enrolled hardware. The private key never leaves the device, never crosses the network, and never appears in a proxy transcript. Each authentication produces a fresh signature origin-bound to the real enterprise identity provider. A lookalike reverse-proxy origin cannot obtain a valid signature for the legitimate origin. There is no OTP to relay, no SMS code to read aloud, and no push prompt to approve for the wrong client.

Against UNC6671, that means the AiTM path dies before a Microsoft 365 or Okta session is minted for the attacker. No transferable factor for the employee to hand to a fake IT caller. No replayable cloud cookie from that path. That is prevention of the exact failure BleepingComputer and GTIG documented, not another detection rule on sessions that should never have been issued.

Enrollment is part of the same fix. UNC6671's pitch was often an urgent passkey or MFA update. If recovery or device onboarding still accepts email codes, SMS, or push that a fake IT caller can coach through, an attacker who already controls the live session path can add hardware they own. Phishing-proof MFA 2.0 means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning. Against this campaign, closing enrollment is as important as closing the live relay.

Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay device-bound and origin-bound with no OTP or push fallback. That hardens the ceremony the branded proxy tried to complete. It is not automatically full-lifecycle coverage if enrollment or recovery still uses softer factors. Callers framed the job as enrolling a passkey or updating MFA. That is the lifecycle gap. Phishing-resistant login cryptography still fails the organisation if a vishing-guided session can add an attacker device through email OTP, SMS, or push. MFA 2.0 is phishing-proof because those phishable steps are removed across the full identity lifecycle, not only at the password box.

It is not a claim about malware reading memory after a good login already happened. Closing the phishable login and the coachable enroll stops this path. An attacker who wants a session after that point needs malware on a signed-in device, which is a different and harder attack. Spoofing IT on a cell phone is easy. Getting malware onto a signed-in device is far harder.

Classic SSO made one stolen session a finance skeleton key

SSO multiplies damage when the first proof is stolen. Classic federation issues one session many integrated apps trust. SharePoint, OneDrive, Salesforce, mail, and admin surfaces ride the same earlier success. Zero-trust language says never trust, always verify at each access boundary. Classic SSO does the opposite. It auto-signs the user into many workloads from one earlier proof. When that proof was captured through a helpdesk-coached AiTM login, the blast radius is the federated surface, not a single mailbox.

Bolting more detection onto broken SSO is not the answer. Secure Explicit Sign-On keeps one-tap UX while authenticating each application independently with its own fresh, device-bound signature. No shared reusable federation cookie exists to steal once and replay everywhere. For a Microsoft 365 or Okta estate hit by UNC6671-style harvest, that shrinks blast radius even if some other path later appears.

Shortening token lifetime does not prevent the harvest. It only forces faster reuse, and it is irrelevant if the attacker already enrolled a lasting factor during the same window.

Residual risk after the login path is closed is different. Vishing kits then have no usable session to harvest. The remaining way to steal a live token is malware or an infostealer on an endpoint that already holds a legitimate session. Revoke of sessions and refresh tokens, and hunting deleted security alerts, remain hygiene for that harder path. They are not equivalent controls to stopping the kit at authentication.

The finance sector did not invent helpdesk fraud. BlackFile's earlier retail and hospitality wave, and adjacent brand names in the same GTIG multi-brand picture, show operators moving a working voice-plus-proxy pattern toward estates that hold deal rooms and portfolio data. The authentication lesson travels with them. Stop coaching transferable factors into reverse proxies, and the extortion business loses its easiest path into cloud SSO. Employees do not have to decide if the help desk caller is legitimate. There is no support call needed. Nothing to type. Nothing to approve. No fake enroll to coach. That is prevention.

If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.

FAQ

Would phishing-proof MFA 2.0 have stopped UNC6671 at hedge funds?

Yes, at initial access and enrollment. Private keys never leave enrolled hardware and signatures are origin-bound, so a branded reverse proxy cannot complete authentication or receive a replayable Microsoft 365 or Okta session. Full-lifecycle coverage also blocks attacker device registration when recovery cannot be coached through email OTP, SMS, or push. Cookie replay after a session is already stolen by malware is a separate residual problem. Prevention keeps that residual path from opening via a spoofed IT call.

Are phishing-resistant passkeys alone enough against UNC6671?

Passkeys are phishing-resistant at login if private keys stay device-bound and origin-bound with no OTP or push fallback. That would have blocked UNC6671's live relay of passwords plus OTP, SMS, or push. They would not automatically have stopped attacker device registration if enrollment or recovery still accepted phishable codes a fake IT caller could coach. MFA 2.0 is phishing-proof across the full identity lifecycle, which is the gap this campaign's passkey-update pitch exploited.

Can any MFA stop replay of stolen Microsoft 365 or Okta session cookies?

No. No MFA design stops replay of a Microsoft 365 or Okta session cookie that is already stolen after authentication succeeded. Device-bound phishing-proof login helps by preventing the helpdesk-coached AiTM path from minting that cookie and from enrolling attacker factors first. After a bearer token exists, defenders need revoke, short-lived access where appropriate, and endpoint controls against malware-grade theft.

How does Secure Explicit Sign-On differ from classic SSO here?

SES authenticates each application with its own fresh, device-bound signature instead of issuing one shared session many apps trust. In this campaign, a single stolen cloud identity session unlocked mail, files, CRM, and admin surfaces without another login. Classic SSO conflicts with zero-trust verify-at-each-boundary design. SES keeps one-tap UX while removing the reusable federation cookie that became a skeleton key after the vishing-guided AiTM harvest.

What should change first after this Wall Street vishing wave?

Retire transferable OTP, SMS, and push from interactive Microsoft 365 and Okta authentication so a proxy cannot finish MFA and receive the session. Bind new-device enrollment and recovery to already enrolled hardware so a coached browser session cannot mint attacker factors. Reduce reliance on a single cloud SSO cookie across mail, files, and CRM by moving toward per-app device-bound proof. Keep revoke and alert integrity as containment for residual malware-grade theft, not as the primary answer to a phishable front door.

Did every named firm lose client data to UNC6671 extortion?

No. Public reporting does not confirm client or firm-wide data loss at every named organization in the UNC6671 Wall Street wave. Point72 reported an attack without evidence of client data theft. Two Sigma reported a blocked attempt without indication systems or data were affected. Millennium and Citadel declined comment. Mandiant has assisted several dozen compromised organizations across the broader activity, but exact victim counts and per-firm loss totals remain unpublished.