From January through April 2026, threat actors created external Microsoft Teams tenants designed to resemble legitimate internal IT departments. They initiated chats with employees and, almost immediately afterward, placed voice calls while pretending to be help desk personnel. The phone conversation itself was the core of the attack. Remote access tools, malware deployment, and an attempted compromise of a domain controller became possible only after an employee followed the attacker’s instructions during the call.
What actually happened?
Employees first received unsolicited Microsoft Teams chat requests from external accounts. After a request was accepted, the attacker typically initiated a voice call within moments and introduced themselves as a member of the organization’s IT support team responding to an urgent technical problem.
During the call, the attacker instructed the employee to allow remote access or execute a file. This conversation represented the main social engineering component of the intrusion. The technical actions that followed were largely procedural once the employee had complied.
The attackers relied on .onmicrosoft.com tenants under their own control. This is the same subdomain format used by legitimate Microsoft 365 customers. Tenant names frequently included words intended to convey authority or legitimacy, such as internal, certified, network, infrastructure, and mandatory. Some attacker identities also used the real first names of people working in the industry instead of relying only on generic job titles. This could make the supposed technician appear more credible during the conversation. The associated source IP addresses were linked to commercial VPN services.
The campaign did not involve exploitation of a Microsoft Teams vulnerability or a compromise of the platform itself. Microsoft Teams functioned as intended. The attackers instead exploited the trust employees placed in communications delivered through the platform.
Where does vishing fit into the attack flow?
Vishing sits at the very beginning of the intrusion chain and plays a critical role in enabling everything that follows. Both campaigns observed, began in the same way: an external Teams chat request was followed by a voice call. The campaigns only began to differ when the attackers moved to payload delivery.
Complete attack flow observed across the two campaigns.
| Stage | What the attacker does | Whose decision is it |
| 1. Chat request | An external account starts a 1:1 | Teams conversation while presenting itself as an IT help desk identity The employee accepts or deletes the request |
| 2. Voice call | The attacker quickly follows with an unsolicited audio call and uses an urgent technical issue as the pretext | The employee answers or ignores the call |
| 3. Coercion | The attacker verbally guides the employee through granting remote control or executing a file | The employee complies or verifies the request |
| 4. Payload | An RMM utility and obfuscated PowerShell are deployed, or a personalized executable hosted in the cloud is delivered | The process is no longer primarily dependent on employee choice |
| 5. Escalation | The attacker performs enumeration, SMB scanning, and NTLM relay activity targeting the domain controller | Detection and response mechanisms become critical |
The first three stages depend entirely on human interaction. Each one provides a separate opportunity for the attack to stop before a technical security control needs to intervene. An employee can reject the chat request, ignore the call, or independently verify the support request before granting access.
If all three opportunities are missed, the organization becomes dependent on controls such as EDR to identify malicious activity at the payload or escalation stage.
In the incidents, both campaigns were stopped before the attackers achieved their intended objective. Successful intervention in individual cases, however, should not replace preventive controls and established procedures.
Why can a voice call be more effective than email?
Voice removes many of the indicators employees are normally taught to inspect when evaluating suspicious messages. Security awareness programs have spent years emphasizing sender domains, external email warnings, suspicious attachment formats, and checking link destinations before clicking. Those indicators are not available during a live phone conversation.
Three characteristics make voice-based social engineering structurally more difficult to defend against:
Trust in the platform can transfer to the caller
A message that appears inside a collaboration platform used throughout the working day can feel more legitimate than an email arriving from an unfamiliar domain. This effect can remain even when the Teams identity is clearly marked as external.
Real-time conversation allows suspicion to be challenged immediately
An attacker can hear uncertainty in the employee’s response and adapt the explanation in real time. An email cannot respond when a recipient questions its legitimacy. A person on the phone can answer an objection immediately, often during the brief period in which the employee is deciding whether to end the call.
Voice communication can create a monitoring gap
Email activity is commonly logged, scanned, inspected, and retained. Voice calls made through collaboration platforms are often subject to significantly less security inspection. This can provide attackers with a relatively private communication channel in which to deliver and adjust the social engineering pretext.
The same approach can be seen in the wider rise of AI-assisted help desk vishing campaigns targeting identity teams, support personnel, and other enterprise functions. It also helps explain why vishing has emerged as an increasingly important threat vector during 2026.
What signals are worth alerting on?
The following indicators can be prioritized from the strongest signal downward.
- A chat followed almost immediately by a call. An external account initiates a 1:1 conversation and then places an unsolicited audio call within seconds. This is one of the strongest behavioral indicators associated with the activity.
- High-volume contact attempts from a single identity. One external account contacts five or six employees within only a few minutes.
- Suspicious tenant naming patterns. External .onmicrosoft.com tenants contain authority-related terms such as internal, certified, network, infrastructure, mandatory, or help desk.
- Unexpected execution of remote management software. Quick Assist or other remote support tools are launched on a workstation belonging to an employee who does not normally require remote assistance.
- Personalized file download links. Cloud-hosted files use names that combine the organization’s name with the name of the individual employee being targeted.
- Unusual domain activity after the call. SMB scanning, unexpected EFSRPC activity, or NTLM traffic directed toward domain controllers occurs shortly after the voice interaction.
What should actually change?
- Policy: A simple and consistent internal rule should establish that IT support does not make unsolicited calls asking employees to install software or grant remote control. Any unexpected request of this type should be terminated and verified by contacting the help desk through a known and trusted number. A short rule is easier to remember during a high-pressure interaction.
- Platform: External communication through Microsoft Teams should be restricted or governed wherever business requirements permit. Broad external messaging permissions increase the ability of unknown identities to establish direct contact with employees.
- Process: Callback verification should be mandatory for support interactions involving remote access. Internal help desk teams should also avoid requesting remote control during unsolicited calls. This creates a clear distinction between legitimate support procedures and attacker behavior.
- Detection: Monitoring should focus on the sequence of external chat activity followed by voice calls, as well as abnormal behavior from external identities. Detection should not begin only after PowerShell or another payload executes. By that stage, several earlier opportunities to stop the intrusion have already been missed.
- Training: Traditional email-focused awareness training does not fully prepare employees for voice-based attacks. Training should include realistic scenarios in which employees practice refusing a plausible but fraudulent help desk request. Scenario-based exercises can help reinforce verification procedures, response behavior, and measurable awareness outcomes.
Conclusion
The campaigns demonstrate that initial access did not begin with a malicious link or attachment. It started with a live voice conversation. No Microsoft Teams exploit was required, and no vulnerability in the platform was involved.
The attackers created deceptive .onmicrosoft.com tenants using names such as ITProtectionDepartment and selected display names including IT Help Desk and IT Assistance. In total, 26 separate attacker identities contacted more than 150 employees across over 10 organizations during a four-month period.
Calls that resulted in successful engagement generally lasted between 10 and 15 minutes. The attackers moved quickly between targets, frequently leaving voicemail messages or abandoning calls that ended after only a short interaction.
Telemetry also showed a broader shift toward collaboration platforms. During early 2026, these platforms represented 42% of phishing alerts observed, compared with 30% during the previous four-month period.
The consequences after a successful call varied significantly. In some cases, the result was a conventional malware infection. In others, the attackers progressed toward network enumeration and attempted NTLM relay activity against a domain controller.
The campaigns therefore demonstrate how the same social engineering technique can lead to very different levels of impact. The common element is the initial trust established during the voice call, which provides the attacker with the opportunity to move from social engineering into technical compromise.
The Arsen platform strengthens one of the most vulnerable links in any cybersecurity framework – the employees. The human factor remains the primary challenge, particularly with the rapid advancement of social engineering and artificial intelligence.
