Spring Ring: Microsoft Teams External Access Is a Domain Compromise Vector — And Web3's Identity Layer Is the Real Supply Chain

On August 31, 2026, Palo Alto Networks Unit42 published the operational report for "Spring Ring," a campaign that ran from January to April 2026. It struck more than 10 organizations, targeted more than 150 employees, burned through 26 attacker-controlled identities, and ended in domain-level compromise. The delivery vehicle was Microsoft Teams external chat — a feature enabled by default in most M365 tenants. The endgame was PetitPotam, an NTLM relay technique disclosed and patched in August 2021. No zero-day. No smart contract flaw. No private key brute force. Just a free .onmicrosoft.com tenant, a convincing "Help Desk Support" display name, and a voice call. This is the identity-layer takeover that the DeFi world has not priced into its risk models. We obsess over protocol audits, farming strategies, and TVL rankings. But the most valuable private key in a crypto organization often does not sit on a hardware wallet. It sits inside an Active Directory domain controller that nobody has hardened since 2021. Volatility is not risk; impermanent loss is. For the identity stack, the impermanent loss is configuration drift and unpatched legacy infrastructure. Unit42 attributes Spring Ring to Cloaked Ursa, an operator set whose lineage overlaps with APT29 and the broader Muddled Libra reporting. The campaign was split into two waves. Wave A deployed RMM tools and an obfuscated PowerShell RAT hosted on san-sid.com. It disabled AMSI, performed local enumeration, and was eventually blocked by Cortex XDR. Wave B was more surgical. Its S3-hosted payloads were named after the targeted company and specific usernames. It generated persistence mechanisms, abused a headless Edge browser installation to avoid visibility, and escalated through the classic path: Teams chat, vishing, RMM access, NTLM relay, Pass-the-Hash, domain controller. The macro trend is worse than the individual case. Microsoft's own security blog from April 18, 2026 described a cross-tenant help desk impersonation playbook that mirrors Spring Ring nearly step-for-step: Teams impersonation, Quick Assist sessions, WinRM lateral movement, and Rclone data exfiltration. KnowBe4 measured a 41% increase in Teams-based attacks between October 2025 and March 2026. Unit42 Cortex telemetry shows collaborative-tool phishing alerts now account for 42% of all phishing alerts, up from 30% in the prior four months. Meanwhile, CVE-2026-62911, an Exchange Auth Bypass, leaves 21,899 unpatched servers exposed. Put those trends together and you have a permissionless external attack surface on the most trusted enterprise communication channel, combined with an identity backbone that is still dependent on a 1990s-era authentication protocol. Let me break down the attack chain the way I break down a smart contract: function by function, privilege by privilege. Step one: tenant registration. The attacker creates a Microsoft 365 tenant on .onmicrosoft.com. Cost: zero. Friction: zero. Identity verification: none. The display name is set to something like "ITProtectionDepartment" or "Help Desk Support." To the average employee, the message appears to come from within the corporate collaboration ecosystem. That is the initial trust anchor, and it is forged from a default configuration. Step two: outreach. The attacker sends an unsolicited Teams chat to a target. Then a phone call follows. The vishing script is simple: "We detected unusual sign-in activity on your account. I need you to accept a Quick Assist session so we can secure your machine." The employee sees a Teams message from "IT," receives a call that sounds professional, and clicks Accept. There is no malware. There is no exploit. There is a human being persuaded to run a legitimate remote management tool. Step three: the pivot. Once the attacker has remote control, they drop a PowerShell RAT. In Wave A, that RAT was obfuscated and designed to disable AMSI. In Wave B, the attacker used an S3 bucket to host stage-two payloads named after the victim company and the employee's username. This level of personalization means the group conducted open-source reconnaissance before the first message. They knew the organizational chart. They knew the help desk naming convention. They knew the patching cadence. Step four: persistence. The attacker establishes scheduled tasks or registry auto-runs. They use a headless Edge browser to obscure malicious activity. Standard endpoint detection can still catch the payload, but by that point the human is already gone from the machine. The employee returns to work. The attacker waits. Step five: privilege escalation. PetitPotam is an ugly but effective technique. It forces a domain controller to authenticate to an attacker-controlled listener over NTLM. The captured authentication is then relayed to the Domain Controller. Pass-the-Hash takes over from there. The attacker ends up with the same privileges as the domain administrator. They do not need to crack a password. They need an unpatched ADCS endpoint and a network segment where SMB signing is not required. Both conditions are still present in a surprising number of mid-market enterprises. Now translate the chain into Web3 terms. Teams external access is an open function on the protocol. The display name is a spoofed token ticker. The Quick Assist session is a malicious approve() call. NTLM relay is a compromised admin key. Pass-the-Hash is the full control of the multisig. The code path is not written in Solidity, but the economic loss is the same. Liquidity is the only truth in a fragmented chain. In enterprise identity, the most liquid communication channel is Microsoft Teams. Every employee trusts it. Every message is rendered as if it were native to the organization. That liquidity is exactly what the attacker monetizes. They do not penetrate the firewall. They walk through the front door wearing a badge that was created on the platform's own identity tenant system. This is why the revelation matters specifically for blockchain companies. A Web3 firm has a higher concentration of privileged accounts per employee than almost any other type of business. The treasury manager, the DevOps lead, the head of finance, the multisig signer — each one possesses the ability to move more value in a single transaction than a typical Fortune 500 employee will handle in a decade. Yet most of those firms run with two or fewer security engineers. Some run with zero. They have a SOC-2 report and a code audit. They do not have a dedicated M365 threat detection program. Spring Ring demonstrates that the path of least resistance into a crypto company is not the EVM. It is the identity plane that sits above it. I have been in this situation from the other side of the table. During the 2022 Terra/LUNA collapse, I held €30,000 in UST-denominated derivatives. The stablecoin itself was an algorithmic promise. When the withdrawal function failed, I had minutes to react. I executed stop-losses across three exchanges and preserved most of the capital. That experience produced a rule I still use: if I cannot audit the logic of a position, I do not take the position. The same rule applies to enterprise infrastructure. If the trust boundary of the identity layer is open by default, then the position is already compromised. The auditor did not review it. The ledger will only show the loss after the fact. During the 2020 DeFi Summer, I built a real-time yield tracker to monitor farming opportunities across Ethereum L2s. The system was simple: quantify the APY, estimate the risk-adjusted return, define the exit threshold. I rebalanced when Compound introduced cCOMPTOKEN incentives, capturing a 15% annualized yield before the market corrected. The key was not prediction. The key was pre-committed rules. Spring Ring runs on the exact opposite principle: there are no pre-committed rules on the employee's side, because the employee has never been told that an inbound Teams message from an external tenant is equivalent to a signed transaction from an unknown address. The security industry has spent 20 years teaching users not to click email links. It has not spent enough time teaching users not to accept remote control invitations from an avatar that says "ITHelpDesk." Efficiency demands the elimination of sentiment. In market trading, that means no FOMO and no panic. In enterprise security, it means no assumptions based on display names and no authority attached to voice tone. Spring Ring did not exploit a technical bug in the final stage. It exploited a sentiment bug in the final decision step. The algorithm executes, but the human decides. The human decided to accept the session because the request came through from what looked like a legitimate internal channel. No endpoint product can rewind that decision after the fact. The contrarian angle is uncomfortable for the security industry: the bulk of the blame belongs to configuration and platform defaults, not to the targeted employees. Team after team will run phishing simulations and blame human error. That framing is convenient, but it is wrong. The human was not error-prone. The human was interacting with a platform that Microsoft designed to make external contact frictionless. The human was operating under a default company policy that had never explicitly restricted external collaborators. The employee made the same trust decision that the CISO made when he or she left Teams external access enabled. The only difference is that the CISO was not on the phone call. Beta is the tax you pay for ignorance. In this context, beta is the broad M365 tenant population with external chat open, NTLM still active, and no identity threat detection. The ignorance is not about security best practices in the abstract. It is about the actual configuration state of the infrastructure. Most organizations have never run an NTLM relay audit. Most have never inventoried their Teams security policy. The default settings were accepted because they were defaults. Spring Ring turns that acceptance into a domain compromise in four to six weeks. Now let me quantify the economics beyond the headline numbers. Teams-based attacks rose 41% in a six-month window. That is a growth rate that would make any yield farmer rebalance into the opportunity. But the yield is negative for the defender. The cost of a domain compromise is not limited to the immediate ransom demand or data exfiltration. It includes the certificate renewal, the credential reset, the insurance premium increase, and the regulatory investigation. For a Web3 company, the reputational damage is instant and unforgiving: one leaked private key or one signed malicious transaction and the market writes the token off permanently. Yield without due diligence is just borrowed luck. Security without identity due diligence is borrowed time. The second contrarian point is aimed at Microsoft's response. The vendor documented the attack pattern, published hardening guidance, and told tenants to restrict external access. That is the correct mitigation, but it shifts full responsibility onto the customer. The product's default posture remains an unlocked gate. I respect the transparency of the security blog. But a platform that ships with external chat enabled by default, integrates legacy NTLM in the same identity plane, and then distributes the configuration burden to understaffed IT teams is designing for attack surface. The company with 150 employees and one outsourced IT provider cannot be expected to conduct a cross-tenant trust architecture review. The platform must make the secure configuration the default. Until that happens, this vector will keep producing victims. Consider the 21,899 unpatched Exchange servers exposed by CVE-2026-62911 as a signal of patch hygiene. That number is not a statistic about criminal negligence. It is a number about organizational capacity. Small and mid-market enterprises do not have teams dedicated to patch orchestration. They do not have teams dedicated to Teams policy review. They have one system administrator and a backlog of tickets. Attackers know this. The 2026 threat landscape is not defined by zero-day sophistication. It is defined by APT groups exploiting defaults and neglected legacy protocols at scale. The takeaway for a crypto workspace is straightforward and I have written it into my own operating manual: First, restrict Teams external access. If your organization does not need cross-tenant collaboration with a fixed set of partners, set external access to private. If you do need it, create an allowed-domain list and block everything else. The Teams community should be governed like a firewall rule set, not like a social feed. Second, inventory your legacy authentication surface. Run the NTLM relay checks against your domain controllers. Disable NTLM on all domain controllers that do not have a hard dependency. If you have Exchange servers, patch CVE-2026-62911 before you touch anything else. The domain controller is the master key vault. Treat it like a cold wallet: no inbound connections, no unnecessary authentication protocols, multi-factor on every admin account. Third, build a ticket-first help desk culture. No IT employee will ever call you and ask for a remote session out of the blue. If someone calls and says they are IT, hang up, open the official help desk portal, log a ticket, and wait for the ticket assignment. The attacker's whole chain depends on bypassing the ticket workflow. Remove the bypass and the chain breaks. Fourth, invest in identity threat detection and response rather than spending the entire security budget on an even larger EDR fleet. Spring Ring was eventually stopped by Cortex XDR in Wave A and by Unit42 MDR in Wave B. But every successful stop cost analyst hours and flew close to the edge of total compromise. The better architecture blocks the front door at the identity layer. The detection story should focus on the identification of anomalous logon attempts, abnormal NTLM usage, and unexpected Teams external contact patterns. Sanity checks before sanity wins. The next version of this campaign will be aimed at the people who sign transactions. The exchange between RMM, NTLM, and the domain controller is generic. Elastic and cheap. The harder task for the attacker is to get the right person to click. In a trading firm, that person sits inside the same team that is watching the ETF premium spreads and the vault address. They are not harder to reach. They just need a more specific story. Ledgers do not lie, only the auditors do. In Spring Ring, the identity ledger shows the truth: a registered tenant, a crafted display name, an accepted remote session, an NTLM relay, and a logon event from a domain controller. The audit was available. The question is whether your organization has the visibility to read those records before the attacker finishes his work. The next time you review the security of the protocol, also review the trust anchor of your communication layer. The domain controller chain matters as much as the token chain. Verify the identity infrastructure the way you would audit a smart contract. The attacker is already doing that. The bull market is a distraction. Everyone is watching DEX volume and the price of ETH. The quieter campaign is running on the corporate identity plane, where a fake help desk message is the token contract and the user's trust is the exit liquidity. The algorithm executes, but the human decides. The most valuable line of code in this story is not in the protocol. It is the one that makes the employee hesitate before accepting the call. Build that into your training. Build it into your default configurations. The next attack will not announce itself with a high-severity CVE. It will arrive in a Teams chat bubble with a polite greeting and an urgent request.