










Between January and April 2026, we uncovered a coordinated social engineering operation that leveraged external Microsoft Teams accounts to masquerade as IT help desk personnel. Our telemetry reveals that this operation targeted more than 150 employees across at least 10 companies in various industries. We call this activity Spring Ring.
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).
We provide a technical breakdown of this operation’s attack lifecycle across two observed campaigns, both illustrating vishing manipulation that resulted in the attempted payload delivery via two distinct attack vectors.
These two campaigns demonstrate the weaponization of communication platforms as identity becomes a primary attack vector.
Palo Alto Networks customers are better protected from the threats described here through the following products and services:
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Spring Ring’s activity mirrors a broader trend in the threat landscape toward social engineering campaigns. According to our recently published Insights blog, threat actors have increasingly moved away from traditional phishing techniques toward trusted collaboration tools.
In the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% of all phishing alerts in the preceding four months. In addition, according to KnowBe4’s Phishing Threat Trends Report, Teams-based attacks rose by 41% [PDF] between October 2025 and March 2026. They note that this surge is driven by attackers exploiting the platform's default “Chat with Anyone” feature to initiate direct chats with users outside their organization.
Previous Teams-based attacks, such as those by Cloaked Ursa (aka APT29), focused on credential harvesting and group chat-based social engineering. They often relied on malicious links or fake Entra ID tenants to appear legitimate.
Spring Ring’s approach relies on active human voice interaction. In this way, attackers can evade detection without a software exploit. Instead, they rely on exploiting the trust that employees place in software as a service (SaaS) collaboration platforms.
SaaS applications are essential for business operations, storing an organization’s most critical and sensitive data. Unlike email, where users are trained to look for external sender banners or suspicious links, communications platforms provide a closed loop that attackers exploit by:
The Spring Ring operation represents an evolution from previous campaigns by merging vishing into the Teams workflow. This shift moves the attack from a passive click-and-harvest model to a real-time engagement.
Attackers can then pivot based on the victim's responses. Once the trust gap is crossed, the path to domain-level privileges via open-source tools like PetitPotam is short.
Figure 1 shows an example of the warning that Teams users get when an external identity creates a chat with them.

The Spring Ring campaigns are a coordinated operation that relies on impersonating corporate IT structures. Attackers can drop their lures into a victim's primary communication channel using external Microsoft Teams accounts.
Our investigation 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:
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:
Names have been partially redacted because the attackers used specific names of legitimate industry personnel. The use of these names does not indicate a compromise of their accounts.
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:
Figure 2 shows several vishing attempts made by the same attacker identity on six different targets, with different conversation durations.

The reach of these campaigns is significant:
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.
Figure 3 shows the full attack flow of the two campaigns' attack methods.

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:
whoami /groups net group /dom |
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:
After attempting to coerce the DC, the attacker's domain-takeover attempt was blocked by Unit 42 Managed Detection and Response.
By comparing the two campaign paths, we can better understand the diversity of threats targeting collaboration platforms. Table 1 compares the campaigns' specific methods of attack.
| Feature | Campaign A | Campaign B |
| Initial Lure | Microsoft Teams vishing | Microsoft Teams vishing |
| Primary Delivery | RMM tools | Tailored hosting infrastructure executables |
| Stealth Mechanism | Obfuscated PowerShell | Headless Microsoft Edge and sideloaded extension |
| Lateral Movement | Basic enumeration only | PetitPotam NTLM relay |
Table 1. Comparing the two campaigns’ methods.
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:
Our researchers were able to identify key markers of Spring Ring activity by analyzing the metadata of these interactions, despite the deceptive nature of the attacker’s initial lures:
Upon a successful compromise, we observed endpoint activity characterized by:
Organizations can identify the Spring Ring lifecycle before the attacker transitions from a chat to a domain-level attack, by profiling these signals, the origin of the tenant and the subsequent attack flow.
Figure 5 shows one example of a Cortex alert on a new suspicious conversation created in Microsoft Teams. This alert is based on behavioral and metadata analysis of a newly created chat.

The Spring Ring campaigns demonstrate a strategic pivot in social engineering, where attackers move beyond email phishing to enterprise collaboration tools. Attackers turn an important productivity tool into a conduit for domain-level exploitation, masquerading as internal help desk personnel through vishing calls.
This activity highlights an important shift in the security landscape. Identity is now a primary perimeter, and the platforms we rely on for daily communication are being weaponized.
Looking forward, attackers might further refine their ability to operate within SaaS ecosystems. These platforms are not just an initial access vector, they contain sensitive documentation, workflows and communication logs that could allow an adversary to advance their attack chain.
Our analysis of the Spring Ring operation reinforces several key lessons:
As these threats evolve, organizations must prioritize user education regarding unsolicited external communication across collaboration platforms. Robust behavioral monitoring can help identify identity-based anomalies before they escalate to lateral movement.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Names have been partially redacted to protect the users associated with accounts that were impersonated by the attackers.
File description: Obfuscated PowerShell RAT dropper downloaded via Invoke-WebRequest
Description: URL hosting obfuscated PowerShell payload used as RAT dropper
Table 2 lists the Cortex XDR alerts and the associated MITRE ATT&CK techniques these alerts detect.
| Alert Name | Alert Source | MITRE ATT&CK Technique |
| External user started a Microsoft Teams conversation | XDR Analytics, Identity Threats | Phishing (T1566) |
| External user created a Microsoft Teams conversation with suspicious operations | XDR Analytics, Identity Threats | Phishing (T1566) |
| External user added a link to a Microsoft Teams chat | XDR Analytics, Identity Threats | Phishing (T1566) |
| External user call via Microsoft Teams | XDR Analytics, Identity Threats | Phishing: Spearphishing Voice (T1566.004) |
| Rare process execution by user | XDR Analytics, UEBA | User Execution (T1204) |
| Rare process execution in organization | XDR Analytics, UEBA | User Execution (T1204) |
| Multiple rare process executions in organization | XDR Analytics, UEBA | User Execution (T1204) |
| A process connected to an atypical rare cloud resource | XDR Analytics | Exfiltration Over Web Service: Exfiltration to Cloud Storage (T1567.002) |
| Uncommon local scheduled task created | XDR Analytics | Scheduled Task/Job (T1053) |
| A browser was forced to load an extension using a special command-line argument | XDR Analytics | Software Extensions: Browser Extensions (T1176.001) |
| Uncommon browser extension loaded | XDR Analytics | Software Extensions: Browser Extensions (T1176.001) |
| SMB traffic from non-standard process | XDR Analytics | Network Service Discovery (T1046) |
| Rare NTLM access by user to host | XDR Analytics, UEBA | Use Alternate Authentication Material (T1550) |
| Unusual Encrypting File System Remote Protocol call (EFSRPC) to domain controller | XDR Analytics, UEBA | Forced Authentication (T1187)
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001) |
| Possible authentication coercion to a sensitive server | XDR Analytics, UEBA | Forced Authentication (T1187)
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001) |
| Possible Distributed File System Namespace Management (DFSNM) abuse | XDR Analytics | Forced Authentication (T1187)
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001) |
| Possible authentication coercion | XDR Analytics, UEBA | Forced Authentication (T1187)
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001) |
Table 2. Cortex XDR alerts and MITRE techniques.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。