A 10-to-15-minute Microsoft Teams voice call was enough. According to Palo Alto Networks Unit 42, the Spring Ring campaign used more than 26 external .onmicrosoft.com identities posing as internal IT helpdesks to target over 150 employees across at least 10 organizations between January and April 2026. Attackers did not steal passwords or MFA codes at a login prompt. They talked people into launching Quick Assist or other remote tools, or into running personalized S3-hosted executables, so the operators owned the desktop instead.
How fake Teams IT personas opened the door
Spring Ring started on the collaboration surface most enterprises treat as internal chatter, not as a gated login. Unit 42 reported attackers standing up external Microsoft 365 tenants and Teams identities with helpdesk-flavored names, including personas under domains such as ITProtectionDepartment.onmicrosoft.com. Those accounts initiated chats, then moved victims onto live voice calls that felt like ordinary IT support.
That platform choice mattered. Email still carries external-sender banners, spoof checks, and years of user training. A Teams chat from someone labeled like corporate IT rides on trust in the product employees already use for real tickets. Unit 42 described the pattern bluntly: what looks like a benign chat is in fact a voice phishing call aimed at coercing remote monitoring and management tools or custom malware. Public reporting does not name a spoofed corporate login page, an adversary-in-the-middle proxy, a Temporary Access Pass, or any capture of OTP or push approvals at authentication time.
The human pacing was deliberate. Successful calls often ran 10 to 15 minutes. That is long enough to build a scripted story, walk someone through Quick Assist or a similar RMM flow, or convince them a required installer is safe because IT is on the line. Victims were guided to grant remote control or to download executables tailored for the engagement and hosted on Amazon S3. Once that step landed, the attackers were not waiting on a password field. They were on the machine.
Unit 42 also put the channel in trend context. 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 write-up cites KnowBe4 reporting that Teams-based attacks rose 41% between October 2025 and March 2026. Spring Ring sits inside that shift: identity pressure moved into the chat and call path, not only the classic mailbox.
For contrast, Unit 42 pointed at earlier Microsoft Teams abuse by Cloaked Ursa (APT29), which leaned harder on credential harvesting, malicious links, and fake Entra ID tenant social engineering in group chat. Spring Ring's observed signature was different. Real-time vishing plus RMM or dropper execution, then hands-on endpoint work, not a primary harvest of typed secrets at a workforce login form.
What remote control unlocked on the endpoint
Unit 42 split the follow-on activity into two campaign shapes after the call succeeded.
Campaign A used legitimate-looking remote management first, then moved into an obfuscated PowerShell remote access tool pulled from infrastructure Unit 42 associated with san-sid.com. Campaign B relied on custom droppers. In both shapes, interactive control or malware on the workstation opened the ordinary post-compromise menu: host and domain enumeration, payload delivery, and the chance to lift whatever sessions, tokens, or local credential material the box already held.
That second stage is token and secret harvest after the fact, not a second login ceremony the user completes for the attacker. Files, cookies, and memory on a PC the operator already drives are not login MFA failures. Authentication for that desktop session already happened earlier for the real user, or never stood between the victim and the coached RMM click. Public reporting does not establish large-scale record theft totals, ransom demands, or named victim companies. Observed domain-takeover and malware attempts in the Unit 42 set were reported as blocked, which is useful for defenders and still leaves the initial social-engineering path intact as the lesson.
Campaign B went further on the wire. Unit 42 observed NTLM authentication traffic and a PetitPotam-style NTLM relay attempt aimed at domain controllers, the classic move when an operator already inside wants to escalate toward directory-level power. That is protocol abuse and relay after foothold. It is not an employee typing a one-time code into a fake portal. Login-time workforce MFA never gets a vote on PetitPotam.
| Stage | Attacker action | Login MFA in play? |
|---|---|---|
| Teams chat and voice | Fake external IT helpdesk 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 credential lift | Post-control harvest |
| Domain pressure | NTLM traffic, PetitPotam relay attempt | Directory or protocol path |
Why login MFA never entered the fight
Security reviews keep asking whether stronger MFA would have saved the day. For Spring Ring, that question is aimed at the wrong door.
Initial access was live social engineering on a trusted collaboration channel. The transferable thing was not a code or a push. 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 second factors sit on authentication prompts. Spring Ring's opening move skipped those prompts. Trust in a voice call from a helpdesk-styled Teams identity replaced them.
Helpdesk-style recovery abuse and coached fake logins are the same broad social-engineering class when the prize is a readable TAP, SMS code, recovery secret, or typed password. Spring Ring's documented prize was different: remote hands or malware on the endpoint. Public reporting does not establish TAP issuance, AiTM cookie replay at login, or any specific MFA product failing a ceremony that never ran. Calling the path an MFA bypass would misstate the mechanics. Nothing at the login boundary was asked to pass or fail.
After the desktop was under attacker control, session cookies, OAuth material, and local secrets were residual endpoint problems. No login redesign undoes interactive malware or RMM on a machine the user already unlocked for the operator. NTLM relay toward domain controllers is the same story one hop deeper: directory and protocol hardening, not a push notification the user never saw.
Unit 42's own framing matches that sequence. The campaigns show communication platforms weaponized as identity becomes a primary attack vector. Here identity meant the social role of IT support on Teams, not a stolen password database. Voice was less monitored than email and file flows in many environments, which is an operational gap attackers noticed.
Defenders still need the boring controls that actually touch this path: external Teams federation policy, tight handling of .onmicrosoft.com strangers, blocks or alerts on unexpected Quick Assist and commodity RMM, application control on odd S3-borne executables, and rapid isolation when helpdesk-themed calls coincide with remote-tool launches. Those measures address what Spring Ring did. Relitigating OTP length does not.
A fix still exists for the neighboring class of attacks that do steal transferable login factors through coached fake pages or helpdesk read-outs. Closing phishable login secrets does not automatically stop a human from sharing their screen with fake IT. Different stage, different control plane.
If you want to skip the attack details and go straight to what authentication can and cannot stop on this path, read the related article on mfa2point0.com: why MFA would not have blocked Spring Ring's Teams-to-RMM chain.
FAQ
Did Spring Ring steal employee passwords or MFA codes at login?
No. According to Unit 42's Spring Ring reporting, attackers did not capture passwords, OTP values, push approvals, or recovery codes at a workforce login prompt. They used external Microsoft Teams helpdesk personas and live voice calls to coerce Quick Assist, other RMM, or personalized malware execution instead.
How many people and organizations did Spring Ring target?
According to Unit 42 telemetry cited in the Spring Ring disclosure, more than 150 employees across at least 10 organizations were targeted, with activity observed from January through April 2026 and public write-up on 31 August 2026. Public reporting does not establish named victim companies or confirmed large-scale data-theft counts.
What did attackers do after a successful Teams vishing call?
After victims granted remote control or ran droppers in the Spring Ring campaigns, operators could enumerate hosts and domains and deliver further payloads. Unit 42 described one path as RMM followed by an obfuscated PowerShell RAT, and another as custom droppers with NTLM traffic and a PetitPotam NTLM relay attempt toward domain controllers. Reported domain-takeover and malware attempts in that set were blocked.
Why didn't ordinary email phishing controls stop Spring Ring?
Spring Ring's initial access ran over Microsoft Teams chats and voice calls from external .onmicrosoft.com identities styled as internal IT, not over a classic external email with a credential-harvest link. Unit 42 noted that collaboration-tool phishing already represented 42% of Cortex phishing alerts in early 2026, and that voice interaction can sit outside the monitoring many teams apply to mail and files.
Would stronger login MFA have stopped Spring Ring?
Stronger login MFA would not have stopped Spring Ring's documented opening move, because that move never presented a login or MFA challenge. The coercion target was remote tools or a binary on a live helpdesk-style call. Once the endpoint was controlled, session and credential material on the box, plus later NTLM relay attempts, sat past interactive workforce authentication entirely.
