Between January and April 2026, attackers created external Microsoft Teams tenants named to look like internal IT departments, opened chats with employees, and then immediately placed a voice call posing as the help desk. The call was the attack. Everything that followed—remote access tools, malware, and an attempted domain controller takeover—only happened because a human agreed to it on the phone. Palo Alto Networks Unit 42 tracked the operation across more than 150 employees at more than 10 organizations.
Key takeaways
- The initial access vector was a live voice call, not a link or an attachment. No exploit, no vulnerability in Teams.
- Attackers registered lookalike
.onmicrosoft.comtenants with names like "ITProtectionDepartment" and used display names such as IT Help Desk or IT Assistance. - 26 distinct attacker identities approached more than 150 employees across more than 10 organizations in four months.
- Calls that converted typically ran 10 to 15 minutes. Attackers cycled fast through targets, leaving voicemails and abandoning short calls.
- Collaboration tools accounted for 42% of phishing alerts in Unit 42 telemetry in early 2026, up from 30% in the preceding four months.
- Post-call outcomes ranged from a standard malware infection to an attempted NTLM relay against the domain controller. Same hook, very different blast radius.
What actually happened?
An unsolicited Microsoft Teams chat request arrived from an external identity. Once the employee accepted, the attacker placed a voice call within moments, claiming to be internal IT handling an urgent technical issue.
On the call, the attacker talked the employee through granting remote control or running a file. That was the whole social engineering payload. The technical stages that followed were mechanical.
The attackers operated from adversary-controlled .onmicrosoft.com tenants, the same subdomain format legitimate Microsoft 365 customers use. Tenant names leaned on authority words: internal, certified, network, infrastructure, mandatory. Some identities used real first names of industry personnel rather than generic role titles, which raises the perceived authenticity of the technician on the other end of the line. Source IPs came from commercial VPN services.
Unit 42 was explicit that this involved no vulnerability or compromise in Microsoft Teams. The product worked as designed. The trust around it is what got exploited.
Where does the vishing sit in the attack flow?
At the front, and it is load-bearing. Both observed campaigns opened identically with a Teams chat and a voice call, then diverged only at payload delivery.
Full attack flow of the two campaigns. Source: Palo Alto Networks Unit 42.
| Stage | What the attacker does | Whose decision is it |
|---|---|---|
| 1. Chat request | External identity opens a 1:1 Teams chat under a help desk persona | Employee accepts or deletes |
| 2. Voice call | Unsolicited call within moments, urgent technical pretext | Employee answers or ignores |
| 3. Coercion | Talks the employee through remote control or file execution | Employee complies or verifies |
| 4. Payload | RMM tool and obfuscated PowerShell, or a personalized cloud-hosted executable | No longer the employee's decision |
| 5. Escalation | Enumeration, SMB scanning, NTLM relay against the domain controller | Detection and response |
Stages 1 through 3 are entirely human. That is three separate moments where a trained employee ends the attack for free, before any control has to work. Miss all three and you are relying on EDR to catch stage 4 or 5.
In this case, Unit 42 blocked both campaigns before the objective. That is not a plan.
Why does a voice call beat an email?
Because it removes the artefacts people are trained to check. Employees have been drilled for a decade on sender domains, external banners, hover-the-link, and attachment types. None of that exists on a call.
Three things make voice structurally harder to defend:
Platform trust transfers to the caller
A message inside the tool employees use all day carries more implicit legitimacy than an email from an unknown domain, even when the sender is external.
Real-time interaction defeats scripted suspicion
The attacker hears hesitation and adapts. A phishing email cannot answer an objection. A person can, and does, in the ten seconds before the employee decides to hang up.
Voice is the monitoring blind spot
Email is logged, scanned, and retained. Calls inside collaboration platforms are usually none of the above, which gives the attacker a private room to run the lure in.
This is the same pattern behind the wave of AI-assisted help desk vishing that has been hitting identity and support functions, and part of why vishing has become a primary threat vector in 2026.
What are the signals worth alerting on?
Priority order, highest signal first.
- Chat-to-call in seconds. An external identity that opens a 1:1 chat and immediately places an unsolicited audio call. This is the single strongest indicator.
- Volume from one identity. The same external identity approaching five or six people in a few minutes.
- Tenant naming. External
.onmicrosoft.comtenants containing internal, certified, network, infrastructure, mandatory, or help desk. - RMM execution by the wrong people. Quick Assist or remote support software running on the machine of someone who has never needed remote support.
- Personalized download URLs. Cloud-hosted files named with both your company name and the individual user's name.
- Post-call domain noise. SMB scanning, unusual EFSRPC calls, or NTLM traffic to domain controllers shortly after a call.
What should you actually change?
- Policy: Publish one rule employees can recite: IT never calls unsolicited to ask you to install software or grant remote control. Ever. If it happens, hang up and call the help desk on the known number. A rule that fits in one sentence is a rule that survives a stressful phone call.
- Platform: Restrict or govern external Teams communication where the business allows it. The default "chat with anyone" posture is what puts the attacker in the room.
- Process: Mandate callback verification for any support interaction that involves remote access. Prohibit your own help desk from asking for it on unsolicited calls, so the legitimate behaviour and the attack behaviour stop looking identical.
- Detection: Alert on the chat-to-call pattern and on external identity behaviour, not just on endpoint execution. By the time PowerShell runs, three human decision points have already been lost.
- Training: Awareness content on voice attacks does not transfer from email training. Employees need to have refused a plausible fake help desk call at least once before they meet a real one. Our vishing resource hub covers scenario design, cadence, and what to measure.
-
No. Unit 42 stated there is no evidence of compromise or vulnerability in Microsoft's product. The attackers used standard external tenant provisioning and the default ability to chat across organizations. The exploited surface was employee trust in the platform, not code.
-
There is no link, no attachment, and no sender domain to inspect. The attacker is a live human who adapts to the target's responses in real time and applies urgency directly. Detection controls tuned for email content have nothing to parse.
-
That is roughly the time needed to build enough rapport to walk someone through launching a remote access tool and approving a control request. Short calls in the data were failures or cycling, not conversions. It is a useful benchmark for how long a realistic simulation scenario should run.
-
It removes this specific delivery channel and is worth doing where the business tolerates it. It does not remove the underlying technique, which moves to phone, SMS, or any other collaboration tool in use. The durable control is a verification process employees apply regardless of channel.
-
Run the scenario. Vishing simulation places a controlled help desk impersonation call against a defined population and measures who verifies, who hangs up, and who complies, which produces a compromise rate for voice that email simulation results cannot tell you.
Full technical breakdown, indicators of compromise, and detection mapping are in the Unit 42 research.
