Spring Ring: the Microsoft Teams vishing campaign targeting Windows domain control

A fake help desk technician starts a chat on Microsoft Teams, calls the victim, and guides them through installing remote access tools. Behind the simulated support interaction, however, is an offensive operation that can ultimately reach the domain controller.

The campaign, dubbed Spring Ring by Palo Alto Networks and first identified on September 2, 2026, targeted at least 150 users across at least 10 organizations. The activity observed took place between January and April.

The attackers combined social engineering, legitimate remote support software, PowerShell payloads, and NTLM relay techniques. In the most advanced attack vector, they attempted to coerce a domain controller into authenticating to infrastructure under their control.

The fake help desk enters Teams directly

The attack begins inside Microsoft Teams, a platform many employees automatically associate with trusted corporate communications. The attackers create conversations using display names that evoke the help desk, IT assistance, or support staff.

The chat is followed by a voice call. Switching to voice allows the fake technician to apply real-time pressure, respond to hesitation, and walk the victim through a precise sequence of actions.

Successful calls generally last between 10 and 15 minutes. The operators also show persistence: they repeat their attempts to make contact and, when necessary, leave voicemails.

The goal is not to persuade the user to click a single link. The victim is induced to run programs, install remote administration tools, or open files prepared specifically for their organization.

This represents a significant shift from traditional phishing. Employees are not simply evaluating a static message; they are making decisions during a conversation with someone posing as an authorized colleague.

According to a threat-hunting report from CrowdStrike cited in the campaign analysis, vishing attacks doubled in the first half of 2026. That figure does not, however, independently confirm Spring Ring.

Quick Assist and RMM software provide initial access

In the first observed scenario, the fake technician persuades the user to launch Windows Quick Assist or RMM software—a legitimate tool for remotely monitoring and managing devices.

Administrators normally use these programs to provide support. If the session is authorized by the victim, however, the attacker can gain control of the computer without necessarily exploiting a software vulnerability.

After gaining access, Spring Ring operators perform initial reconnaissance of the host and Windows domain. Their aim is to understand the device configuration, the corporate environment, and potential opportunities for continuing the intrusion.

In one of the activities analyzed, the attackers attempted to download an obfuscated RAT written in PowerShell. The payload was reportedly designed to provide persistent remote access, but endpoint protection blocked its execution.

The RAT's name was not disclosed. No file hashes, domains, IP addresses, or other technical indicators suitable for direct retrospective searches are available either.

This lack of information makes behavioral detection more important. Focusing solely on a specific malware signature may fail to detect the initial phase, which is conducted using authorized tools and actions confirmed by the user.

From a hidden browser to an attempted NTLM relay

The second attack vector involves a more complex technical chain. The attackers direct the victim to files hosted on cloud infrastructure and customized for the user and target organization.

The executables establish persistence and launch a hidden instance of Microsoft Edge. They then sideload an extension, conduct internal network reconnaissance, and generate NTLM authentication traffic.

The most dangerous phase involves an attempted PetitPotam-based NTLM relay. The technique is designed to coerce a Windows system—in this case, the domain controller—into authenticating to a destination controlled by the attacker.

The attacker then attempts to relay that authentication to another service, using it to obtain privileges they do not directly possess. If successful against exposed systems and configurations, the operation could extend control from the initial endpoint to the organization's identity infrastructure.

The ultimate target is particularly sensitive. A domain controller manages authentication, accounts, policies, and trust relationships in a Windows environment; compromising it can pave the way to control of the entire domain.

The Unit 42 managed detection service, a division of Palo Alto Networks, blocked the attempted takeover of the infrastructure. There is therefore no indication that the observed domain controller was actually compromised.

Scope and limitations of the available information

Palo Alto Networks counted at least 150 targeted users across at least 10 organizations. It did not disclose an overall success rate, however, so it is impossible to determine how many victims executed the files or granted remote access.

The two attempts described in detail were stopped: endpoint protection blocked the PowerShell RAT, while Unit 42 blocked the attack against the domain. This does not demonstrate that every incident associated with the campaign had the same outcome.

The specific versions of Microsoft Teams, Windows, Quick Assist, or Edge involved were not identified. Spring Ring is not described as the exploitation of a vulnerability in a particular release, but as the abuse of legitimate functionality combined with social engineering and Windows authentication techniques.

Accordingly, no remediation patch or CVE associated with the campaign has been identified. Keeping systems up to date remains necessary, but it does not neutralize a phone call in which a user voluntarily authorizes a remote session.

The available data comes from Palo Alto Networks' investigation. No independent corroboration of the same set of incidents has been provided.

How to recognize and contain Spring Ring

The first countermeasure is to separate the communication channel from identity verification. A request received through Teams should not be considered authentic merely because it appears in a corporate environment.

When a purported technician asks an employee to launch Quick Assist, install an RMM tool, or run a file, the employee should stop and contact the help desk through a phone number or portal already known to them. They should not use contact details provided by the caller.

Organizations can also act at multiple levels:

• restrict Quick Assist and RMM tools to authorized users, devices, and support workflows;
• log unexpected remote-session launches and correlate them with new contacts received on Teams;
• detect obfuscated PowerShell, unusual downloads, browsers launched in hidden mode, and extension sideloading;
• inspect executable files downloaded from cloud services, especially when they are customized or delivered during a call;
• analyze NTLM authentication to external destinations or unapproved systems;
• look for behavior consistent with authentication coercion and relay attacks;
• strengthen monitoring of domain controllers and identity-related anomalies;
• train staff with voice-call simulations, not just email phishing exercises.

In the absence of public hashes and network addresses, the most useful indicators are behavioral: repeated contact from fake support accounts, unexpected calls, unauthorized RMM launches, PowerShell execution, and unusual NTLM traffic.

Teams availability issues are separate incidents

On September 4, 2026, operational issues affecting Microsoft Teams were also reported, but there is no evidence linking them to Spring Ring.

Incident TM1466820 may prevent the Windows desktop client from opening or delay the initial load by up to two minutes. Microsoft listed Teams on the web, the mobile app, and other access methods as temporary workarounds.

A separate issue, identified as TM1466659, affects some Mac users who are unable to join calls or meetings. Microsoft was analyzing the logs and reassessing the cause after an initial hypothesis involving a code change.

These are availability problems, not evidence of a compromise. There is no indication that they caused, facilitated, or concealed the Spring Ring attacks.

The distinction is essential: the campaign exploits trust in collaboration tools, not the service disruptions reported in the clients. Defenses must therefore focus as much on technical controls as on verifying support processes and identities.