1. Overview
- Article Title: Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams
- Source: Unit 42
- Published Date: 2026-08-31
- Original Source: Unit 42
- Related Sources: None
- Related Malware, Threat Groups, CVEs, Products: Spring Ring, PowerShell RAT, Microsoft Teams, Microsoft Quick Assist, Microsoft Edge, Active Directory
- Severity: High
2. Executive Summary
Spring Ring uses external Teams accounts to impersonate corporate IT staff. It uses voice calls to trick targets into running RMM tools or custom malware. In advanced cases, the campaign attempts NTLM Relay against domain controllers using PetitPotam.
3. Attack Flow
From External Teams Chat to Attempted Domain Privilege Escalation
- The attacker sets up an external
onmicrosoft.comtenant and a display name to impersonate the IT department. - The attacker sends a one-on-one Teams chat to the target, followed immediately by a voice call to build trust and urgency.
- In Campaign A, the attacker tricks the target into running an RMM tool like Quick Assist to enumerate devices and the domain.
- The attacker downloads an obfuscated PowerShell RAT, attempts to bypass AMSI, and connects to the C2 server.
- In Campaign B, the attacker delivers an executable file via an S3 URL tailored to the target, establishing persistence, a hidden Edge instance, and extensions.
- The attacker uses Python to scan internal TCP/445 and triggers NTLM authentication toward the domain controller.
- The attacker forces authentication using PetitPotam and attempts to gain domain privileges via NTLM Relay, though this was blocked in observed cases.
4. Attacker Positioning and Execution Location
- External attackers connecting to Teams from a Microsoft 365 external tenant.
- After running RMM or malware, the attacker reaches the internal network and Active Directory from the user device.
5. Victim and Administrator Visibility
Victim
- Receives a chat and voice call on Teams from a display name that looks like internal IT staff, followed by a request for remote support or update tasks.
Administrator
- Indicators include chats and immediate calls from external tenants, unusual RMM usage, PowerShell, customized S3 URLs, hidden Edge instances, and SMB/EFSRPC traffic.
6. Success and Failure Conditions
Success Conditions
- The attacker can start Teams chats and calls from an external tenant to the target.
- The target believes the attacker is IT staff and launches the RMM tool or executable file.
- Communication from the endpoint to C2, SMB, and domain controllers is allowed.
- Preconditions for NTLM Relay, such as authentication, signing, and certificate service configurations, remain in place.
Failure Conditions / Risk Mitigation
- Restrict external Teams communication to business needs and verify external callers through a separate channel.
- Require approval for Quick Assist and third-party RMM tools to block unauthorized RMM use by standard users.
- Enable PowerShell controls, AMSI, application control, and EDR.
- Strengthen Relay defenses, such as SMB signing, NTLM restrictions, and Extended Protection for Authentication.
7. What Happens Upon Success
- Remote device control and information gathering via RMM or RAT.
- Persistence, browser extension sideloading, and internal server discovery.
- Domain privilege escalation and lateral movement if NTLM Relay succeeds.
8. Observable Logs
- Email: The primary vector is Teams; email logs alone cannot confirm initial contact.
-
Proxy/SWG/DNS: Connections to
san-sid.com, S3 URLs containing target names, and unknown file distribution points. -
Endpoint/EDR:
QuickAssist.exeor unauthorized RMM, obfuscated PowerShell, AMSI bypass, executables inTempdirectories, hidden Edge instances, and sideloaded extensions. -
Identity/IdP: Chats and calls from external
onmicrosoft.comtenants, with the same external ID contacting multiple users in a short time. - SaaS/Cloud: Audit logs for Teams chat creation, call initiation, external participants, call duration, and shared URLs.
- Network: TCP/445 scans from non-standard processes, NTLM traffic, EFSRPC, and forced authentication toward domain controllers.
9. Attack Success Assessment
- Attack Attempt Observed (Success Unconfirmed): The stage where a chat, voicemail, or brief call arrives from an external Teams ID. Unit 42 also observed many failed and missed calls.
- User Interaction Confirmed: The stage where the user answers the call and begins interacting with Quick Assist, a third-party RMM, or an executable file on S3.
- Initial Execution Confirmed: The stage where RMM connection, PowerShell, customized executables, or hidden Edge starts on the endpoint.
- Malware Execution or Authentication Success Confirmed: The stage where PowerShell RAT C2 connection, RMM remote control, or forced NTLM authentication is confirmed. Campaign A RAT execution and Campaign B domain takeover attempts were blocked in observed cases.
- Information Theft or Session Compromise Confirmed: The stage where endpoint/domain info, credentials, or browser data acquisition and exfiltration are confirmed. Public reports do not quantify the blast radius.
- Post-Compromise Confirmed: The stage where internal scanning, connection to additional devices, successful NTLM Relay, and domain privilege acquisition are confirmed. Domain takeover success has not been confirmed in reports.
10. Investigation Playbook
- Trigger: Detect a chat or call from an external Teams ID impersonating IT, immediately followed by RMM or PowerShell activity.
- Initial Verification: Preserve the external tenant ID, display name, targeted user, call timestamp and duration, shared URL, and RMM session.
- Endpoint: Check RMM approval and connection history, PowerShell Script Block logs, AMSI, downloaded files from S3, Edge extensions, Python, and SMB scans.
- Authentication/Cloud: Investigate Teams audit logs, the scope of contact with external tenants, suspicious IdP authentications, and NTLM usage.
- Post-Exploitation: Examine TCP/445 scans, EFSRPC, domain controller authentication, Relay destinations, additional payloads, and credential access.
- Containment: Isolate the endpoint, terminate RMM sessions, block external IDs, and revoke exposed credentials and sessions.
- Severity Classification: Differentiate between contact only, accepted call, user interaction, remote control, RAT execution, forced authentication, successful Relay, and domain compromise.
11. Defense and Detection Ideas
- Single Event: An external Teams ID uses an IT-related display name and starts a voice call immediately after the first chat.
- Timeline Correlation: Correlate external chat -> call -> RMM/PowerShell -> S3 download -> SMB scan -> EFSRPC/NTLM within a roughly 30-minute window.
-
Hunting: Search for Quick Assist usage by users who do not normally use RMM,
san-sid.com, customized S3 names, hidden Edge instances, and TCP/445 traffic from Python. - Log Gaps: Without linking external Teams chat and call metadata to endpoint and authentication logs, it is impossible to reconstruct the path from voice manipulation to subsequent execution.
- Priority Mitigations: Prioritize restricting external Teams communication, enforcing an RMM allowlist, monitoring PowerShell/AMSI, and implementing SMB Relay defenses.
12. Facts / Inference / Hypothesis
Facts
- Unit 42 observed activity targeting over 150 individuals across more than 10 organizations between January and April 2026, identifying 26 attacker IDs.
- Attackers used external
onmicrosoft.comtenants to impersonate help desk or IT support, starting voice calls immediately after one-on-one chats. - In Campaign A, attackers had victims run legitimate RMM tools like Quick Assist and retrieved an obfuscated PowerShell RAT from
san-sid.com. The RAT connects to C2 after bypassing AMSI, but execution was blocked. - In Campaign B, attackers distributed executables via S3 URLs containing target organization and user names, combining hidden Edge, sideloaded extensions, SMB scans, and PetitPotam. Domain takeover attempts were blocked.
- Unit 42 explicitly stated there is no evidence of vulnerabilities or compromises within Microsoft Teams itself.
Hypothesis
- Organizations with broad external Teams chat permissions and unmanaged RMM usage are more likely to bypass email defenses and fall victim to device manipulation.
- Correlating call metadata, RMM startup, PowerShell, SMB, and EFSRPC for the same user allows analysts to determine the attack stage faster than alerts from a single product.
Hypothesis
- Subsequent campaigns using different role names or modified
onmicrosoft.comnaming conventions may continue, but public information is insufficient to determine the future scope of targets.
13. MITRE ATT&CK Mapping
- T1566.004 Phishing: Spearphishing Voice (High): Impersonated IT staff via voice calls from external Teams accounts.
- T1219 Remote Access Software (High): Induced victims to run legitimate RMM tools like Quick Assist.
- T1059.001 Command and Scripting Interpreter: PowerShell (High): Used to download and execute an obfuscated PowerShell RAT.
- T1562.001 Impair Defenses: Disable or Modify Tools (High): The PowerShell RAT used AMSI initialization failure flags to evade scanning.
- T1187 Forced Authentication (High): Attempted to force domain controller authentication using PetitPotam.
- T1557.001 Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (Medium): Reported as a vector to relay forced NTLM authentication.
14. Unknowns and Further Investigation
- The number of individuals among the 150+ contacts who proceeded to accept calls, run RMM, or execute payloads.
- The scope of information gathered before blocking and the full range of organizations and industries ultimately targeted by the attackers.
15. Impact on SOCs and Organizations
This campaign can succeed in any organization that permits external Teams chats and uses legitimate RMM tools. Organizations must not trust external tenant displays alone. Instead, they must monitor the sequence from short chats to calls, RMM, PowerShell, and SMB scans, while establishing clear policies for external Teams communication and Quick Assist usage.
16. Summary by Role
- For SOCs: Correlate calls immediately following external Teams chats, unusual RMM usage, PowerShell, S3 executables, SMB scans, and EFSRPC for the same user.
- For Administrators: Limit external Teams communication and RMM to business needs, and enable AMSI, PowerShell, and SMB Relay protections.
- For Users: Do not follow instructions for calls or remote support if requested by external users claiming to be IT staff on Teams; verify through known internal help desks instead.
Top comments (1)
The detailed breakdown of the Spring Ring attack flow really highlights the sophisticated tactics used by attackers to exploit trust within corporate communication channels. Your suggestion to restrict external Teams communication aligns well with best practices in minimizing risks, especially when it comes to tool approvals like Quick Assist. It could also be beneficial to implement user training on recognizing these types of social engineering tactics, as human error often plays a critical role in such exploits. If youβre looking for additional engineering support to enhance detection mechanisms or user training materials, Iβd be glad to discuss a paid collaboration. What are your thoughts on integrating more proactive user training into the security strategy?