Palo Alto’s Unit 42 published research at the end of August on a campaign they’re calling Spring Ring. Between January and April, someone registered a batch of Microsoft 365 tenants with names like ITProtectionDepartment and MandatoryNetworkMonitoring, used them to open Teams chats with employees at more than ten companies, and then called those employees claiming to be internal IT. Unit 42 counted 26 attacker identities and more than 150 people contacted.
Nothing was exploited. There’s no CVE to look up and no patch to deploy, and Unit 42 was explicit that they found no flaw in Teams itself. What the attackers used was a default setting in Microsoft 365 and the reasonable assumption employees make that someone contacting them inside a corporate tool works at the company.
In one of the two attack paths Unit 42 documented, that phone call ended with an attempt to coerce authentication out of the victim’s domain controller.
How the calls worked
Unit 42 came across this after turning on some new Teams detections and noticing chats being created in a pattern that didn’t look organic across several customer tenants.
The infrastructure was about as cheap as it gets. Microsoft hands every new tenant a .onmicrosoft.com subdomain, so the attackers registered tenants whose names read like internal departments rather than businesses: InternalSystemsDaily, CertifiedUpdateNetwork, InternalUSAHelpDeskIT. Display names were what you’d expect, along the lines of IT Help Desk or IT Assistance. In some cases they went further and used the names of real people who work in the industry, which turns the voice on the phone into a specific technician instead of a generic one.
Teams does warn you when an external identity starts a chat. There’s a prompt with Accept and Delete on it. People clicked Accept.
The call records are the part we found most interesting. These operators were working a list. A single identity would approach five or six people inside a few minutes. Plenty of the calls lasted seconds or went unanswered, and they left voicemails, which most phishing operations don’t bother doing. The ones that connected tended to run 10 to 15 minutes. Traffic came in through commercial VPN providers.
The campaign window
The two payloads
Once someone stayed on the line, Unit 42 saw the operation go two different directions.
Both paths started identically. The difference between a malware infection your EDR handles and a genuine directory emergency came down to which payload the operator picked that day.
In the first, the caller talked the employee into launching Quick Assist or installing a third-party RMM package, then asked for remote control. Once they had it, they ran a couple of quick commands to see whose machine they were on and what domain it belonged to, then pulled down a PowerShell RAT from their own infrastructure.
The malware is worth a brief look. It was heavily obfuscated, with junk added specifically to make automated deobfuscation time out, but strip the padding and there are nine lines underneath: turn off AMSI by setting amsiInitFailed, run a test scan to confirm the bypass took, encrypt some host details, call home for the real payload. Endpoint protection caught it at execution.
The second path was built for the specific target. Rather than an RMM tool, the caller sent the victim to a download whose filename contained both their employer’s name and their own username, sitting in an S3 bucket that also had the company name in it. Hard to blame anyone for trusting that.
The executable copied itself into a temp directory under a couple of different names for persistence, started a hidden headless Edge process, and sideloaded a browser extension. Then a Python interpreter appeared under ProgramData and the attacker began scanning internal hosts over SMB, generating NTLM traffic aimed at the domain controller, and finally running PetitPotam to force the DC to authenticate back to a machine they controlled. If that authentication had been relayed somewhere useful, AD CS web enrollment for instance, or an LDAP endpoint running without signing and channel binding, it could have ended at domain admin. Unit 42’s managed detection service caught it first.
Why this one is hard to defend
Most of our advisories end with a version number. This one can’t, which is the awkward part.
Microsoft 365 ships with Teams external access set to allow every external domain. Unless someone has changed it in your tenant, anybody who can register a Microsoft tenant can open a chat with your staff. KnowBe4 attributes a lot of the recent growth in Teams attacks to that default specifically.
Then there’s what we’ve spent a decade training employees to do. Check the sender address. Hover the link. Treat the external banner as a warning. None of it applies here. There’s a person on the line who can hear hesitation and talk someone past it, which no email has ever managed.
Visibility is the last piece. We log and inspect email, file operations, and chat messages, but a Teams voice call generally records that a call happened and very little about what was said, so an attacker who gets someone on the phone is working in the one channel nobody reads.
Mika Aalto at Hoxhunt described this as “targeting the locksmith” rather than breaking a window, which is about right.
Get the process that grants access working for you and you stop phishing accounts one at a time.
Context
None of this is isolated. Unit 42 says collaboration tools generated 42% of the phishing alerts in their Cortex platform over the first four months of 2026, against 30% in the four months before. KnowBe4 measured Teams-based attacks up 41% from October through March, and CrowdStrike says vishing doubled in the first half of the year.
Teams social engineering isn’t new either. APT29 was doing it years ago, but that campaign was after credentials and used links to get them. What’s changed is the human on the phone.
The obvious comparison is MGM in 2023, when a single phone call to a help desk turned into a nine-figure incident, though the direction was opposite. MGM’s attackers called the help desk and talked their way into a reset. Spring Ring’s attackers call your employees and say they are the help desk. Unit 42 expects this to resurface under different tenant names and personas, so the indicators in their report have a short shelf life.
Recommendations
Change the external access setting.
Use the Defender block list.
Give people permission to hang up.
Get control of remote access tooling.
Make the relay path a dead end.
Go looking in your logs.
Find out what your people actually do.
The part you can’t configure
Denis Calderone at Suzu Labs made the point that conventional awareness training “doesn’t really prepare people for this,” because it’s built around inspecting senders and not clicking links. He’s right, and it’s worth resisting the obvious reaction, which is to go buy more of the same training.
The deeper issue is that the relationship between employees and the help desk is unauthenticated in both directions and always has been. Your users have no way to confirm that a technician contacting them is real. Your technicians frequently have no strong way to confirm that the person calling about a locked account is who they claim to be. Attackers have worked out both halves. MGM was one end of it; Spring Ring is the other.
Solving that is an identity and process project, not a training module. It means deciding what a verified interaction looks like in each direction and building it into the workflow, which is a roadmap item with real cost attached. We’d rather say that plainly than pretend a slide deck closes it.
Microsoft begins rolling out outbound external messaging limits in mid-September for tenants that only use a default onmicrosoft.com domain, which makes the disposable-tenant approach more expensive. It doesn’t replace changing your own settings.
