The Teams Default That Opened the Door: How Spring Ring Weaponized External Collaboration into Domain Compromise

Hook

On August 31, 2026, Palo Alto Networks Unit42 dropped the technical details of an attack campaign that had been running silent for months. Codename: Spring Ring. Active from January to April 2026, it targeted over 10 organizations and more than 150 employees. The initial vector wasn't a zero-day exploit, a phishing email, or a vulnerable web server. It was a Microsoft Teams chat request.

Over the past seven days alone, my monitoring feeds flagged multiple security advisories that follow the same pattern: an attacker registers a free Azure tenant, creates a display name that looks like corporate IT, and initiates a conversation with an employee. No malware signature. No malicious link in the email gateway. Just a voice call through a platform that—by default—allows any external user to reach any internal employee.

The numbers bear this out. Teams-based attacks grew 41% between October 2025 and March 2026, according to KnowBe4. Unit42 Cortex telemetry shows collaboration-tool phishing alerts now account for 42% of all phishing alerts, up from 30% in the previous four months. We are not looking at a blip. We are looking at a structural shift in how enterprise identity gets compromised.

Context

Spring Ring is attributed to Cloaked Ursa, a threat actor with ties to both APT29 and Muddled Libra. The operational security discipline is notable: the attackers registered .onmicrosoft.com tenants and used professional-sounding display names like ITProtectionDepartment and Help Desk Support. They did not need to break anything. They simply walked through a door that Microsoft left open by default.

The attack chain itself is a masterclass in chaining modern collaboration features to legacy authentication protocols. It goes like this: Teams chat invitation → vishing call → remote management tool (RMM) installation → local enumeration → NTLM relay via PetitPotam → Pass-the-Hash → domain controller compromise. The campaign split into two waves. Campaign A deployed RMM tools and an obfuscated PowerShell RAT hosted on san-sid.com, disabled AMSI, and performed local enumeration. It was blocked mid-execution by Cortex XDR. Campaign B was more surgical. The attackers hosted payloads on S3 with filenames containing victim company names and usernames, deployed persistence mechanisms, used headless Edge browser sessions for session hijacking, and escalated to a PetitPotam NTLM relay attack against the domain controller. Unit42 MDR stopped the final domain takeover attempt.

What makes this campaign notable is not the sophistication of any single technique—PetitPotam has been patched since August 2021. What matters is the delivery mechanism. The attackers didn't need to exploit a software vulnerability to get inside. They needed a registered tenant and a convincing voice.

Core: The Attack Surface Nobody Configured

Let's be precise about what this attack actually exploited.

Teams external access is enabled by default in most M365 tenants. The setting that allows external users to contact internal users is frequently left on. This is not a hidden configuration buried deep in an obscure admin panel. It is a core feature designed to facilitate cross-organization collaboration. But in the context of this campaign, it functioned as an open API to every employee in the organization—a phone book that only requires a free Azure AD tenant to access.

As a security auditor, I have reviewed the configuration baselines of dozens of mid-to-large enterprises. The pattern is consistent. Organizations enable Teams external access because a business unit requested it, or because nobody explicitly disabled it. They rarely implement restrictions to allow only federated domains. They almost never apply conditional access policies to external Teams sessions. And they virtually never train employees on the difference between an internal Teams contact and an external tenant identity.

This is where the technical analysis gets uncomfortable. The attack chain demonstrates a fundamental trust boundary mismatch. The modern collaboration layer—Teams—defaults to open. The legacy authentication layer—NTLM—has known relay vulnerabilities that remain unpatched in many environments. Between these two layers sits a gap that no EDR or XDR product can fill, because the entry point is human trust, not code execution.

Let me be clear about the mechanics of the relay. PetitPotam (CVE-2021-36942) abuses the MS-EFSRPC protocol to coerce a domain controller into authenticating to an attacker-controlled machine via NTLM. The attacker then relays that authentication to compromise the domain. This vulnerability was patched in August 2021. Its continued use in 2026 tells us something important: thousands of organizations still have unpatched ADCS or certificate services infrastructure. The patching gap is not a theoretical risk. It is an active exploitation vector.

The fact that attackers chose PetitPotam—a known, old, well-documented technique—over a zero-day is itself a signal. It means the attack surface is so broad that reliable old techniques work just fine. Why burn a zero-day when 21,899 unpatched Exchange servers still expose CVE-2026-62911, an auth bypass vulnerability? Why develop a novel exploit when the default configuration of Teams gives you a direct line to every employee?

Based on my audit experience, I can tell you the most frustrating part of this entire campaign. The attackers did not do anything clever. They enrolled a tenant, picked a name that sounds like IT support, and made phone calls. The technical sophistication was reserved for the post-exploitation phase. The initial compromise was pure social engineering leveraging a platform trust default.

The code doesn't lie, but it also doesn't care. Teams external access is not a vulnerability. It is a feature. And this campaign demonstrates, with clinical precision, that features without security context are vulnerabilities.

Contrarian: The Blind Spot No One Is Talking About

The common response to Spring Ring will be: restrict Teams external access, disable NTLM, patch PetitPotam. All correct. All insufficient.

Here is the contrarian angle: the real problem is not the configuration. It is the absence of tenant-level reputation and trust verification in the collaboration platform itself.

Think about email security. SPF, DKIM, and DMARC exist because we learned, over two decades, that domain spoofing is trivial. The ecosystem built trust mechanisms at the protocol level. Teams has no equivalent. There is no external tenant reputation system. No DMARC-like mechanism that says "this tenant has a verified domain, this one was registered three hours ago." No visual distinction between an internal contact and an external tenant when a chat request arrives.

The attackers used 26 distinct identities registered across this campaign. They re-registered tenants, changed display names, and pivoted infrastructure. The platform did not flag a newly created tenant initiating hundreds of outbound chat requests as anomalous. The platform did not warn the recipient that this is an external user from an unverified domain. The platform is structurally incapable of distinguishing a legitimate external collaborator from an APT operator.

This is not a Microsoft-specific failure. It is a SaaS multi-tenancy design gap. Any platform that allows low-friction cross-tenant communication—whether messaging, file sharing, or collaborative editing—must implement dynamic trust scoring for tenants. Static tenant IDs are not sufficient. Age of tenant, domain verification, communication patterns, and outbound message volume are all signals that can be scored.

The security industry's response to this gap has been to sell more detection tools. But the bottleneck isn't the infrastructure. The bottleneck is the trust model. Until collaboration platforms implement tenant-level reputation and enforce graduated communication privileges based on that reputation, this attack vector remains open for every APT and ransomware group.

There is another uncomfortable dimension here. Microsoft published a security blog on April 18, 2026, describing the cross-tenant help desk impersonation playbook. Unit42 published the full Spring Ring analysis four months later. The disclosure lag is not the issue. The issue is that the platform still defaults to open external communication, and enterprise customers are expected to configure their way out of a design decision made by the vendor.

Takeaway

The Spring Ring campaign will be replicated. Not because Cloaked Ursa is uniquely capable—they demonstrated solid operational discipline, but nothing that requires nation-state resources. The playbook is now public. The tooling is freely available. The entry point is a default configuration in the world's most widely deployed enterprise collaboration platform.

Resilience isn't audited in the winter. It is tested when the attack comes through the channel your employees trust the most. The question for every CISO reading this is not whether your organization will be targeted. It is whether your Teams tenant currently allows external users to initiate conversations with your employees. If the answer is yes, the only thing standing between an attacker and your domain controller is a phone call.

The code doesn't lie. The attack chain is public. The mitigation is clear. But the deeper lesson is structural: identity attacks don't care about your endpoint detection. They care about your defaults. And your defaults, right now, are probably open.