Ten to fifteen minutes on a voice call was enough to move from a helpdesk-styled Teams chat to remote control of a corporate PC. According to Palo Alto Networks Unit 42, the Spring Ring campaign (January to April 2026, disclosed 31 August 2026) used more than 26 external .onmicrosoft.com identities to target over 150 employees across at least 10 organizations. Attackers did not harvest passwords, OTP values, push approvals, or recovery codes at a workforce login prompt. They coached victims to launch Quick Assist or other RMM tools, or to run personalized S3-hosted executables. Phishing-resistant passkeys and phishing-proof device-bound MFA both sit on authentication ceremonies. Spring Ring's opening move never presented one, so neither design blocks that first hop. Closing a phishable login stops a different path. Malware or RMM after a human hands over the desktop is a harder, separate problem.
Why Spring Ring never presented a login MFA challenge
Unit 42 described attackers standing up external Microsoft 365 tenants and Teams personas with helpdesk-flavored names, including identities under domains such as ITProtectionDepartment.onmicrosoft.com. Those accounts opened chats, then shifted victims onto live voice calls that felt like ordinary IT support. The write-up's core line is blunt: what seems like a benign chat is in fact a voice phishing call meant to coerce remote monitoring and management tools or custom malware.
Platform trust did the heavy lifting. Email still carries external-sender banners and years of user drills. A Teams identity labeled like corporate IT rides on the product employees already use for real tickets. Unit 42 noted that voice interaction is often less monitored than email and file activity, which is an operational gap operators noticed. Successful calls commonly ran 10 to 15 minutes: long enough to walk someone through Quick Assist, another RMM flow, or a required installer hosted on Amazon S3.
After that click, Unit 42 split follow-on work into two shapes. Campaign A used legitimate-looking remote management, then an obfuscated PowerShell remote access tool tied to infrastructure associated with san-sid.com. Campaign B used custom droppers. On a controlled workstation, operators could enumerate hosts and domains and lift whatever sessions, tokens, or local credential material the box already held. Campaign B also showed NTLM authentication traffic and a PetitPotam-style NTLM relay attempt aimed at domain controllers. Observed domain-takeover and malware attempts in that Unit 42 set were reported as blocked. Public reporting does not establish named victim companies, confirmed large-scale record theft totals, or ransom demands.
Trend context matters for defenders who still treat chat as soft ground. In the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% in the prior four months. The same post cites KnowBe4 figures that Teams-based attacks rose 41% between October 2025 and March 2026. Unit 42 contrasted earlier Microsoft Teams abuse by Cloaked Ursa (APT29), which leaned harder on credential harvesting, malicious links, and fake Entra ID tenant social engineering. Spring Ring's observed signature was real-time vishing plus RMM or dropper execution, then hands-on endpoint work.
Security reviews still ask whether a stronger second factor would have saved the day. For Spring Ring, that question aims at a ceremony that never ran. Initial access was live social engineering on a trusted collaboration channel. The transferable prize was not a code read aloud or typed into a fake portal. It was the victim's willingness to start remote control or run a binary while a convincing helpdesk stayed on the line. Workforce password checks and classic OTP or push factors only fire when an identity provider challenges a login. Spring Ring skipped that boundary. Trust in a helpdesk-styled Teams voice call replaced it.
That is not the same documented path as helpdesk recovery that issues a Temporary Access Pass, or a coached adversary-in-the-middle page that captures a password plus a live OTP. Public reporting does not name TAP issuance, a spoofed corporate login page, AiTM cookie capture at authentication time, or any specific MFA product failing a prompt the user never saw. Calling the path an MFA failure at login misstates the mechanics. Nothing at the login boundary was asked to pass or fail.
| Stage | What attackers did | Did workforce login MFA apply? |
|---|---|---|
| Teams chat and voice | External .onmicrosoft.com IT personas | No challenge presented |
| Coercion window | Quick Assist, RMM, or S3 executable | No password or OTP capture |
| On-box follow-on | Enumerate, RAT, session or secret lift | Post-control harvest |
| Domain pressure | NTLM traffic, PetitPotam relay attempt | Protocol path after foothold |
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how Spring Ring fake Teams IT helpdesks pushed RMM without stealing login MFA codes.
What phishing-proof MFA changes, and what it does not
Device-bound, origin-bound authentication removes transferable secrets from registration through decommissioning when that is how the identity system is built. There is no password to relay, no OTP to read out, no push to approve on a proxied page, and no recovery code that IT can dictate to an attacker. Private keys stay on hardware. Signatures bind to the real origin. That is phishing-proof coverage across the identity lifecycle, not merely phishing-resistant hardening of a single login act. The product story is still prevention, not detection: stop the remote kit from completing a fake authentication so a replayable session is never issued in the first place.
On initial access, MFA 2.0 does not stop an employee from being talked into starting Quick Assist, another RMM client, or a helpdesk-supplied executable. That path never presents an authentication or MFA challenge. The control plane is collaboration policy, external federation rules, application control, and user resistance to live remote-tool coaching, not a stronger signature at a prompt that is absent.
On data access after remote control or malware execution, no MFA design undoes session cookie, OAuth token, or local credential harvest from a workstation the attacker already drives. Fooling a user into a proxied login is easy when factors are transferable. Planting or coaching malware and RMM is a different grade of problem. Once interactive control exists, revoke, isolation, and endpoint response are containment. They are not the same claim as the login could not complete.
On lateral movement via NTLM relay or pass-the-hash style reuse of material already obtained inside the network, user-login MFA 2.0 does not block PetitPotam-class protocol abuse aimed at domain controllers. Directory hardening, relay-resistant configuration, and least privilege sit on that stage.
Passkeys and FIDO2-style WebAuthn are phishing-resistant at the login act: a device-held key pair signs a challenge for a specific origin, and the private key never leaves hardware to be typed or pasted. On a generic enterprise identity provider that only accepts those hardware-bound signatures for app sign-in, a remote proxy cannot complete the ceremony the way it can with passwords and OTP. That property is powerful when the attacker's goal is a fake login page. Spring Ring's goal was a live operator or dropper on the PC after a helpdesk-styled Teams call. Origin-bound login signatures never entered the conversation, so passkeys would not have adjudicated the RMM click.
Phishing-resistant passkeys still leave an enrollment and recovery gap if email OTP, SMS, or push can register a new authenticator. Phishing-proof MFA 2.0 closes that lifecycle hole by refusing phishable factors at registration, device onboarding, authorization, authentication, and decommissioning. Spring Ring's public reporting does not show attackers abusing TAP issuance, helpdesk re-enrollment, or recovery secrets to add their own device. The social engineering targeted remote tools and binaries, not a second-factor enrollment flow. Full-lifecycle phishing-proof design still would not have blocked coached Quick Assist. It would have removed a different industrial path that Unit 42 did not document here. Treat enrolment policy as mandatory hygiene for the attacks that do steal transferable factors, not as the control that would have rewritten Spring Ring's opening move.
Neighboring attacks still matter. When the prize is a readable TAP, SMS code, recovery secret, or typed password on a spoofed page, eliminating phishable factors across enrollment, recovery, and authentication closes that class. Spring Ring's documented prize was remote hands or malware on the endpoint. Different stage, different control plane. Login cryptography is not a cure for coached screen sharing.
Classic SSO blast radius is not the center of this campaign's public record. Public reporting does not establish federation token replay across a multi-app cloud estate as the opening move. The skeleton-key problem of one stolen SSO session still exists in other breaches. It is not the Spring Ring lesson Unit 42 wrote down.
Key takeaways for defenders
- Treat external Teams and .onmicrosoft.com helpdesk personas as untrusted until federation and naming policy say otherwise, not as internal IT by display name alone.
- Alert and block unexpected Quick Assist, commodity RMM, and odd S3-borne executables when they coincide with helpdesk-themed chats or calls.
- Assume voice on collaboration platforms needs the same scrutiny email already gets; Unit 42's 42% collaboration-phishing share in early Cortex data is the trend line.
- Plan containment for post-control token and secret harvest: isolation and revoke after RMM compromise, not a second thought about OTP length.
- Keep NTLM relay and PetitPotam defenses in the domain tier; login MFA will not cast a vote on that traffic.
Authentication redesign still earns its keep against AiTM kits, push fatigue, and helpdesk read-outs of transferable secrets. Spring Ring shows that identity pressure also arrives as a human voice on a trusted chat surface. Build controls for the stage you are actually in.
FAQ
Would phishing-resistant MFA or MFA 2.0 have stopped Spring Ring?
No. Phishing-resistant MFA and phishing-proof MFA 2.0 would not have stopped Spring Ring's documented opening move, because that move never presented a workforce login or MFA challenge. According to Unit 42, attackers used external Microsoft Teams helpdesk personas and live voice calls to coerce Quick Assist, other RMM, or personalized malware execution. Once the endpoint was controlled, session and credential material on the box, plus later NTLM relay attempts, sat past interactive authentication entirely.
Did Spring Ring bypass MFA at a login prompt?
No. Public reporting on Spring Ring does not show passwords, OTP values, push approvals, or recovery codes captured at a login prompt, and it does not name TAP issuance or AiTM reverse-proxy phishing. Unit 42's Spring Ring write-up describes live vishing on Teams that coached remote tools or droppers instead. Nothing at the login boundary was asked to pass or fail, so bypass is the wrong word for the mechanics.
What can authentication redesign still prevent after Spring Ring?
Authentication redesign that eliminates phishable factors across the identity lifecycle still prevents the neighboring class of attacks that steal transferable login secrets through coached fake pages or helpdesk read-outs of codes and recovery material. For Spring Ring specifically, that redesign does not stop coached RMM or S3 executables, does not undo token harvest on an already-controlled PC, and does not block PetitPotam-style NTLM relay after foothold. Closing the phishable login stops that other path. Malware after a human grants remote control is a separate problem.
What should security teams prioritize against Teams helpdesk vishing?
Security teams facing Spring Ring-style Teams helpdesk vishing should prioritize external Teams federation policy, scrutiny of .onmicrosoft.com strangers with IT display names, controls on unexpected Quick Assist and commodity RMM, application control for unusual S3-hosted executables, and rapid isolation when helpdesk-themed calls coincide with remote-tool launches. Unit 42 also framed collaboration-platform phishing as a rising share of alerts, so monitoring voice and chat paths belongs beside classic email controls.
How does Spring Ring differ from Cloaked Ursa Teams abuse?
According to Unit 42's Spring Ring post, earlier Microsoft Teams activity associated with Cloaked Ursa (APT29) focused more on credential harvesting, malicious links, and fake Entra ID tenant social engineering in collaboration settings. Spring Ring's observed pattern centered on real-time vishing that pushed RMM or custom malware, then endpoint enumeration and, in one campaign shape, NTLM relay pressure toward domain controllers, rather than primary theft of typed secrets at a workforce login form.
