More than $10.6 million in Bitcoin already sat in group wallets before the finance wave peaked. 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 that harvested passwords, live MFA codes or push approvals, and session cookies for Microsoft 365 and Okta. Device-bound phishing-proof authentication would have blocked the transferable secrets and coached enrollment those sites needed. It would not have erased a cookie already issued after a successful login.
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 into mail, files, CRM, and admin surfaces without a fresh challenge at each app.
| Phase | What was abused | Does device-bound proof stop it? |
|---|---|---|
| Helpdesk vishing on personal phones | IT trust, urgent MFA story | Shrinks coachable secrets and re-enrollment |
| AiTM reverse-proxy login | Password plus OTP, SMS, or push | Yes: no transferable factor to relay |
| Attacker MFA device registration | Weak enrollment after interception | Yes if enrollment cannot use phishable recovery |
| Replay of M365 or Okta session cookies | Bearer SSO tokens already issued | No: authentication already succeeded |
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.
If you want the full attack-chain narrative, read the related post on legacymfa.sucks: how UNC6671 used helpdesk vishing and AiTM to steal hedge fund MFA sessions.
How phishing-proof device-bound login closes the path
Prevention has to kill the kit’s ability to finish authentication remotely. Device-bound credentials use public-key cryptography on hardware the user already holds. The private key never leaves that device. The server stores only a public key. There is no shared OTP seed database and no approval prompt an attacker can spam or read aloud over a phone.
During a real login, the legitimate origin challenges the authenticator. The device signs that challenge. A lookalike reverse-proxy origin does not receive a signature the real identity provider will accept as a completed ceremony the attacker can finish from their infrastructure. There is nothing useful to type into a fake page, and nothing useful to relay in real time. That is why a phishing-proof design stops this campaign at the credential phase instead of hoping someone notices a bad cookie later.
Prevention, not detection is the point. Revoking sessions, killing refresh tokens, and hunting deleted security alerts are necessary after a phishable login already succeeded. They are harder, later, and incomplete if the attacker enrolled their own factor first. Remove the transferable password-plus-OTP surface and the AiTM path that minted those sessions collapses.
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 helpdesk-driven resets that a caller can coach, an attacker who already controls the live session path can add hardware they own. Phishing-proof coverage means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning.
Passkeys and FIDO2 create a device-held key pair and sign origin-bound challenges so a reverse proxy cannot simply replay a typed secret. Industry language correctly calls that phishing-resistant at the login act. On a generic enterprise IdP that only accepts hardware-bound signatures, the UNC6671 branded page would not obtain a private key or a portable OTP to finish authentication for the attacker. That hardens the ceremony the 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, push, or helpdesk reset. MFA 2.0 is phishing-proof because those phishable steps are removed across the full identity lifecycle, not only at the password box. Against UNC6671, closing enrollment is as important as closing the live relay.
Key takeaways for defenders
- Treat personal-mobile helpdesk calls that demand MFA or passkey changes as high-risk social engineering, not routine IT hygiene.
- Require phishing-proof, device-bound authenticators for Microsoft 365 and Okta workforce access so AiTM proxies have no OTP, SMS, or push material to relay.
- Bind new-device enrollment and recovery to already enrolled hardware under strict policy; do not let a coached browser session mint attacker factors.
- Prefer per-app device-bound proof over long-lived shared SSO cookies that fan out into SharePoint, OneDrive, and Salesforce after one good login.
- Keep session revoke and alert integrity as backup for malware-grade theft, not as the primary answer to vishing-guided AiTM.
What still fails after SSO session cookies exist
Classic SSO multiplies the damage. One good cloud identity session fans out across integrated applications such as SharePoint, OneDrive, and Salesforce. Zero-trust language says never trust, always verify at each boundary. Auto-login from a single federation cookie does the opposite once that cookie is copied. 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.
SSO architecture still matters after login is fixed. Prefer Secure Explicit Sign-On over classic shared federation cookies: the user keeps a one-tap experience, but each application receives its own fresh, device-bound signature. No single replayable SSO token becomes a skeleton key across SharePoint, CRM, and mail. That shrinks blast radius even if malware later steals a local session, which is a different and harder problem than fooling someone on a phone call.
Once a legitimate session cookie is already in attacker hands, no MFA design un-issues it. In this campaign those cookies were the output of a phishable, coached login. Block that login and the remote kit never holds the cookie. True endpoint malware theft of an already-good session remains a residual risk. Planting malware is not the same job as spoofing IT on a cell phone.
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. Enrolment controls that fail closed keep a coached browser session from quietly attaching attacker-owned factors after interception.
FAQ
Would phishing-resistant passkeys alone have stopped UNC6671 at hedge funds?
Phishing-resistant passkeys would have blocked UNC6671’s AiTM relay of passwords plus OTP, SMS, or push during Microsoft 365 or Okta login if those passkeys were required and no softer factor remained in the path. They would not automatically have stopped attacker device registration if enrollment or recovery still accepted phishable codes or helpdesk-driven resets the caller could coach. Full-lifecycle phishing-proof coverage is what closes both the live proxy and the fraudulent authenticator add.
Can any MFA stop replay of stolen Microsoft 365 or Okta session cookies in the UNC6671 campaign?
No MFA design stops replay of a Microsoft 365 or Okta session cookie that is already stolen after authentication succeeded in the UNC6671 campaign. 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.
Why does MFA 2.0 avoid classic SSO for this kind of blast radius?
MFA 2.0 avoids classic SSO because one stolen federation cookie unlocked linked cloud apps after UNC6671 finished a proxied login, which conflicts with zero-trust verify-every-access goals. Secure Explicit Sign-On keeps a simple one-tap user experience while each application gets its own fresh, device-bound signature instead of sharing one replayable token across mail, files, and CRM.
How should firms harden enrollment after UNC6671-style passkey update calls?
Firms should harden enrollment after UNC6671-style passkey update calls by requiring an already enrolled device for new authenticator binding and by removing email OTP, SMS, push, and freely social-engineered helpdesk resets from recovery. Enrolment policy that fails closed stops a coached browser session from quietly attaching attacker-controlled factors after an AiTM interception.
Did every named firm lose client data to UNC6671 extortion?
No public reporting confirms 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.
