Spring Ring: Teams Vishing Turns Help Desks Into Attack Paths

Microsoft Teams has become an unexpected front door for a highly human form of intrusion. In research published by Palo Alto Unit 42, a campaign the organization calls Spring Ring used external Microsoft Teams accounts to impersonate corporate IT support, initiate voice calls and persuade employees to run remote-management software or malware.

Unit 42 says it observed the activity between January and April 2026, with more than 150 employees at at least 10 companies approached across multiple industries. The operation did not depend on a Microsoft Teams software flaw. Instead, it exploited the credibility employees assign to a familiar collaboration platform and to a caller claiming to be a help-desk technician.

The findings matter because the same initial conversation could lead to different levels of compromise. One observed path stopped at remote-control tooling and an obfuscated PowerShell payload. Another progressed toward internal discovery, authentication coercion and an attempted NTLM relay attack against a domain controller. Unit 42 reports that the latter domain-takeover attempt was blocked.

Confirmed findings and scope

Unit 42 identified a recurring pattern of suspicious Microsoft Teams chats created by external identities. Its investigation found 26 distinct identities approaching targets in different organizations. The accounts used professional-sounding names such as “help desk,” “IT assistance” and “support staff,” often paired with external .onmicrosoft[.]com tenants whose names included terms such as “internal,” “network,” “infrastructure” or “certified.”

The identities were not simply used to send a link. After opening a chat, the attacker typically attempted a Teams voice call and presented themselves as an internal technician. Unit 42 observed repeated attempts, including voicemails and short or missed calls. Successful conversations commonly lasted between 10 and 15 minutes, giving the caller time to respond to the employee’s questions and guide the interaction.

The research organization also cautions that names used in some lures matched legitimate industry personnel. That similarity does not demonstrate that the real people or their accounts were compromised. Likewise, the presence of external Microsoft 365 tenants does not mean Microsoft infrastructure itself was breached. Unit 42 explicitly reports no evidence of a Microsoft product compromise or vulnerability connected to this campaign.

Two payload paths after the call

Unit 42 analyzed two Spring Ring campaigns that shared the Teams-and-vishing opening but diverged in execution. This difference is important for defenders: a familiar social-engineering script may be followed by a relatively conventional remote-support scam, a malware infection or an attempt to reach domain-level privileges.

Campaign A: legitimate remote-support software followed by PowerShell

In the first path, the caller persuaded the employee to launch Windows Quick Assist or download third-party remote-monitoring and management software. Once remote control was available, the operator conducted basic host and domain enumeration. Unit 42 observed commands including whoami /groups and net group /dom.

The attacker then used PowerShell to retrieve an obfuscated PowerShell-based remote-access Trojan from the attacker-controlled domain san-sid[.]com. The sample used variable manipulation and arithmetic obfuscation to complicate automated analysis. Unit 42’s analysis found that the effective payload was a small command-and-control stager hidden beneath anti-analysis material.

According to the report, the script attempted to disable the Antimalware Scan Interface by setting the amsiInitFailed flag, performed a test scan to check the result, encrypted host information and beaconed to san-sid[.]com to download and execute additional payloads. Palo Alto Networks reports that Cortex XDR protections blocked this campaign during malware execution.

Campaign B: organization-specific cloud delivery and authentication coercion

The second path used a more customized lure. During the Teams call, the attacker directed the victim to a cloud-hosted endpoint whose filename incorporated the target organization and the employee’s name. Unit 42 documented a pattern resembling <company_name>-org-filters-update-<victim_name>.s3.us-west-2.amazonaws[.]com, with a correspondingly named executable.

After execution, the file moved itself into the Windows temporary directory and created copies with names such as vhlp-*.exe and scnr-*.exe. Unit 42 describes these copies as a persistence mechanism. The malware also launched a hidden, headless Microsoft Edge instance and sideloaded an Edge extension.

The observed post-compromise sequence then used Python from C:\ProgramData\IntegrityData\python.exe. The process generated SMB traffic toward internal systems and NTLM authentication traffic aimed at the organization’s domain controller. Unit 42 reports an attempted PetitPotam attack intended to coerce the domain controller to authenticate to an attacker-controlled system, enabling an NTLM relay path designed to obtain domain-level privileges. Unit 42 Managed Detection and Response blocked the domain-takeover attempt.

The research confirms the attempted sequence, not a successful domain compromise. It also does not establish that every victim reached the same stage or that the campaign achieved domain-level access in other environments.

Detection opportunities across identity and endpoints

The strongest detection signal may appear before malware execution. Teams administrators should treat a rapid transition from a new external one-to-one chat to an unsolicited audio call as a meaningful behavioral anomaly, particularly when the sender’s display name suggests IT support or administration.

Useful collaboration-platform telemetry includes:

• External users creating new chats with employees, especially from recently established or unfamiliar .onmicrosoft[.]com tenants.
• Role-based display names that imply help-desk authority but do not match an approved support identity.
• Repeated calls from one external identity to several employees within minutes.
• Short failed attempts, voicemails and later calls lasting roughly 10 to 15 minutes.
• Links posted during an external chat, especially links to cloud storage or file-hosting services.

Endpoint monitoring should connect those identity events with unusual user activity. Examples include an employee who does not normally receive remote support launching Quick Assist or another RMM tool; rare execution of downloaded executables; PowerShell retrieving content from an unfamiliar domain; AMSI-related tampering; and a rare process connecting to an atypical cloud resource.

For the second attack path, defenders should investigate executables appearing in temporary directories, unexpected copies with vhlp- or scnr- naming patterns, headless Edge processes and browser extensions loaded outside normal administrative workflows. Network monitoring should also examine SMB traffic from non-standard processes, unusual port 445 activity and rare NTLM authentication involving sensitive servers.

Unit 42’s published detection mapping includes phishing, spearphishing voice, user execution, exfiltration to cloud storage, scheduled tasks, browser extensions, network service discovery, alternate authentication material, forced authentication and SMB relay-related activity. These mappings are useful as analytic categories, but they should be adapted to each organization’s logging and identity architecture rather than treated as a complete detection strategy.

Indicators reported by Unit 42

The report lists the following infrastructure and file indicators. They are reproduced in defanged form and should be handled according to an organization’s threat-intelligence and incident-response procedures:

• Domain: san-sid[.]com
• Payload URL: hxxps://san-sid[.]com/owners
• SHA-256: 24ab9fe5d5be62d3bf055a0ca4508e8bca2996b6d78649dce8145d8a27bc1c5b
• Observed Teams identities include helpdesk@itprotectiondepartment[.]onmicrosoft[.]com, ithelp@internalsystemsdaily[.]onmicrosoft[.]com, itadmin@mandatorynetworkmonitoring[.]onmicrosoft[.]com and ithelpdesk@certifiedupdatenetwork[.]onmicrosoft[.]com.
• Reported network indicators include 193.32.248[.]251, 193.138.7[.]142, 185.65.134[.]209, 178.130.47[.]46, 5.181.3[.]106 and 45.33.22[.]47, among others listed in the source report.

Indicators should not be used in isolation. The reported domains, identities and addresses may change, and legitimate-looking names can be impersonated without compromising the real accounts associated with similar names.

Attribution and what remains uncertain

Palo Alto Unit 42 discusses Spring Ring alongside earlier Microsoft Teams activity associated with Cloaked Ursa, also known as APT29. However, the supplied research does not state that Unit 42 has attributed Spring Ring itself to Cloaked Ursa or APT29. That distinction is important: the campaign’s observed behaviors are confirmed findings, while any connection to previously reported actor activity remains unconfirmed in this report.

The research also does not provide a CVE for Spring Ring, and no CVE should be inferred from the PetitPotam reference. The report describes an attempted authentication-coercion and NTLM-relay sequence, not a newly disclosed product vulnerability.

What organizations should do now

• Restrict external collaboration paths. Review whether employees need to receive unsolicited chats or calls from external Teams tenants. Where business requirements allow, limit or govern external communication and make the external status of a contact prominent.
• Define a trusted support process. Tell staff that internal IT will not request unapproved remote-control tools, unexpected executables or security changes during an unsolicited call. Require employees to verify support requests through a known internal channel.
• Monitor identity behavior. Alert on new external chats followed quickly by calls, repeated targeting by one identity and support-themed tenant or display-name patterns.
• Control remote-access software. Maintain an approved RMM inventory, restrict execution to authorized tools and review unusual Quick Assist or RMM activity.
• Harden PowerShell and browser execution. Log PowerShell activity, investigate AMSI tampering and control the installation or sideloading of browser extensions.
• Protect domain controllers. Investigate unusual NTLM authentication, EFSRPC-related requests, SMB connections from unexpected processes and possible authentication coercion involving domain controllers.
• Prepare for rapid response. If a user followed the caller’s instructions, isolate the endpoint as appropriate, preserve Teams and endpoint logs, review authentication activity and assess whether credentials or privileged sessions were exposed.

Conclusion

Spring Ring shows how a short Teams conversation can become the start of a multi-stage intrusion without exploiting the collaboration platform itself. The decisive control point is often the interaction between identity telemetry, voice-call metadata and endpoint behavior. Organizations that verify support contacts, reduce unnecessary external collaboration and correlate unusual remote-access, PowerShell, browser and NTLM activity can interrupt the chain before a social-engineering success becomes a broader identity or domain incident.

Sources

Palo Alto Unit 42: Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams