Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams

Between January and April 2026, Palo Alto Unit 42 uncovered a coordinated social engineering operation, dubbed ‘Spring Ring,’ leveraging external Microsoft Teams accounts to masquerade as IT help desk personnel and deliver malicious payloads. The operation involved a voice phishing (vishing) tactic, where attackers initiated calls to gain trust and then guided victims to execute RMM software or install custom malware. Attackers utilized spoofed domain names within .onmicrosoft.com to appear legitimate and employed a two-pronged approach: one campaign involved executing legitimate RMM software, while the other utilized a more sophisticated NTLM relay attack to gain domain-level privileges. The campaigns demonstrated a significant reach, targeting over 150 employees across multiple organizations and highlighting the evolving threat landscape of exploiting trusted collaboration tools.

What seems like a benign chat is in fact a voice phishing (vishing) call, during which adversaries try to coerce victims into executing remote monitoring and management (RMM) tools or custom malware. In a more advanced variant, attackers transitioned from a vishing call to a full-blown Microsoft NT LAN Manager (NTLM) relay attack aimed at an organization’s domain controller (DC).

Palo Alto Networks customers are better protected from the threats described here through the following products and services: [details omitted for brevity].

Unit 42’s research into this activity began after the release of a new detection suite for Microsoft Teams. By monitoring these alerts, we identified a suspicious pattern of chat creation across multiple tenants. Further investigation into these alerts led to the initial discovery of 26 distinct identities approaching targets across different organizations. The attack begins with creating a Microsoft Teams chat using identities designed to mirror legitimate internal support units. The attackers opt for professional, urgency-focused display names such as help desk, IT assistance or support staff.

To strengthen the impression of legitimacy, the attackers operate from external .onmicrosoft[.]com tenants. These are meant to resemble legitimate corporate infrastructure. They are used by attackers to provision Microsoft 365 tenants. The subdomains are controlled by the adversaries.

Threat actors frequently abuse or subvert legitimate products for malicious purposes. This does not indicate that the product itself is flawed or compromised. Unit 42 has no evidence of any compromise or vulnerability within Microsoft's product related to this campaign.

Here are examples of these subdomains:

• ithelp@InternalSystemsDaily[.]onmicrosoft[.]com
• HelpDesk@ITProtectionDepartment[.]onmicrosoft[.]com
• itadmin@MandatoryNetworkMonitoring[.]onmicrosoft[.]com
• Internal@InternalUSAHelpDeskIT[.]onmicrosoft[.]com
• ithelpdesk@CertifiedUpdateNetwork[.]onmicrosoft[.]com

In some instances, the actors went beyond generic role names and used specific names to increase the perceived authenticity of the technician on the other end of the line:

• patrick[..]@infrastructureopsdesk.onmicrosoft[.]com
• robert[..]@systemdeploymentcenter.onmicrosoft[.]com
• clara[..]@systemsupportoperations.onmicrosoft[.]com

After the chat is created, the attacker initiates a voice call (the vishing element) to coerce the victim. After establishing a connection with what the victim believes is their own IT department, the attacker guides targeted employees through the steps to grant them remote control or execute malicious payloads.

Our telemetry reveals that these attackers often make several attempts — including leaving voicemails — before establishing a connection. We observed the attackers engaging victims in calls that varied in duration:

• Many calls last only a few seconds or they are missed by the victim as the attacker cycles through targets
• Successful calls often last between 10 and 15 minutes.

The reach of these campaigns is significant:

• More than 10 tenants were attacked: We observed the campaigns targeting many organizations across different industries
• More than 150 targets were approached: The attackers contacted more than 150 individual employees
• Persistent activity: We tracked the campaigns since January 2026 over a period of several weeks. According to our telemetry, these campaigns were active up until April 2026.

Once the attacker establishes trust through the initial vishing call, the Spring Ring campaigns transitioned into a technical execution phase designed to gain a permanent foothold. We provide a detailed analysis of two campaigns (Campaign A and Campaign B) that both began with a Microsoft Teams lure. They then diverged in their payload delivery, tool complexity and post-compromise activities.

In Campaign A, the attacker used a bring-your-own-tool approach, luring the victim to execute legitimate RMM software. The attacker posing as a technician walked the employee through launching built-in Windows tools like Quick Assist or downloading third-party RMM software. Once the RMM tool ran, the attacker could request remote control of the victim’s machine.

After gaining remote control, the attacker performed a series of basic enumeration commands to gain information on the host and domain. We observed them executing:

After confirming the environment’s value, the attacker pivots to payload delivery. The attacker used a PowerShell command line to download an obfuscated PowerShell-based remote access Trojan (RAT) from the attacker-controlled domain, san-sid[.]com. This malware used variable manipulations and arithmetic obfuscation designed to evade automated security analysis and sandbox detection.

By leveraging advanced AI and pattern-matching algorithms, we were able to de-obfuscate the RAT. We started by stripping away anti-analysis bloat from the code that was used to cause a time-out for deobfuscation tools.

The actual payload is a tiny, nine-line command and control (C2) stager. The script disables Antimalware Scan Interface (AMSI) via the amsiInitFailed flag and executes a test scan to verify the bypass. Upon verification, the script encrypts host data and beacons out to san-sid[.]com to download and execute further payloads.

Figure 4 shows a snippet of the obfuscated PowerShell-based RAT.

This campaign was blocked by automated Cortex XDR Agent protections during the malware's execution phase.

The second campaign used a more customized delivery method. During the vishing call, the attacker directed the victim to a cloud endpoint. The attackers tailored the cloud infrastructure and filenames to match the targeted organization and the specific user, for example: <company_name>-org-filters-update-<victim_name>.s3.us-west-2.amazonaws[.]com

When the victim clicked a link containing their own company's name and downloaded <company_name>-org-filters-update-<victim_name>[.]exe, it triggered an execution chain:

• Staging and persistence: The executable moved itself to the emp\\ directory and spawned copies (e.g., vhlp-*.exe and scnr-*.exe) as a persistence mechanism
• Browser hijacking: The malware launched a hidden, headless instance of Microsoft Edge, and the attackers wrote to the disk and sideloaded an Edge extension
• Lateral movement and authentication coercion: The attackers used Python (C:\ProgramData\IntegrityData\python.exe) to initiate a lateral movement sequence:
• SMB scanning: Initiated port 445 traffic targeting internal servers
• NTLM authentication: Generated NTLM traffic targeting the organization’s DC
• PetitPotam exploitation: The attacker attempted a PetitPotam attack to coerce the DC into authenticating back to an attacker-controlled machine. This NTLM relay attack was designed to grant the attacker domain-level privileges

After attempting to coerce the DC, the attacker's domain-takeover attempt was blocked by Unit 42 Managed Detection and Response.

Table 1 compares the campaigns’ specific methods of attack.

This comparison highlights an important point for defenders. A simple vishing hook can lead to either a standard malware infection, or to a serious domain-level breach if the attacker pivots to payload delivery.

Recognizing campaigns like Spring Ring requires a strategy of profiling external and internal entity behaviors. The attackers behind these campaigns operate within a legitimate ecosystem, so detection hinges on identifying small anomalies in how external identities interact with your organization.

The first line of defense is recognizing the markers of the external actor. Our research into these campaigns highlights several consistent patterns:

• Spoofed domain naming: Attackers mostly use external .onmicrosoft[.]com tenants that include