Microsoft Teams vishing attacks lead to Chaos ransomware attacks

When a "Microsoft Teams IT support" call turns into a full-blown Chaos ransomware incident, the attack chain reveals deep-seated gaps in identity governance, endpoint telemetry. And the fundamental trust models baked into cloud collaboration platforms.

The recent BleepingComputer report on threat actors using Microsoft Teams vishing to drop Chaos ransomware is not just another social engineering headline. It is a textbook case of how loosely federated identity, over-permissioned remote access tools, and insufficient voice-channel monitoring converge into a practical attack path. The adversaries didn't exploit a zero-day; they weaponized legitimate platform features - guest calling, screen sharing and Quick Assist - to slip past layers of defense that most organizations assume are sufficient.

Having conducted forensic triage on similar incidents in enterprise environments, I can tell you: the technical signals were there hours before any encryption began. The problem is that our detection stacks are blind to the telemetry that bridges telephony systems, cloud collaboration. And endpoint process creation. In this deep dive, we'll dissect the kill chain, map it to MITRE ATT&CK, and rebuild a defensible architecture for Teams voice phishing resilience - all through the lens of engineering, not just security awareness memos.

Deconstructing the microsoft Teams Vishing Kill Chain

The initial vector is straightforward: an external user or compromised guest initiates a Microsoft Teams call to an unsuspecting employee, posing as internal IT support. Because Teams guest access is often configured with minimal friction - sometimes even allowing federation with any domain - the attacker can reach an inbox and a call button with nothing more than a free Microsoft account. The call itself exploits a human trust heuristic: a familiar interface, a professional-looking profile picture, and a plausible pretext around a security update or VPN issue.

Once the target accepts the call, the attacker guides them through a series of seemingly helpful screensharing or remote control requests. Tools like Quick Assist, Teams' native screen sharing, or even third-party RMM tools are invoked. The victim is coaxed into granting full control, often under the guise of "checking firewall settings" or "validating MFA codes. " At this point, the attacker executes PowerShell or Command Prompt commands to drop a Chaos ransomware payload. The entire sequence - from call invite to initial access - can occur in under ten minutes, leaving minimal time for SOC escalation.

Mapping this to ATT&CK, we see T1566. 003 (Phishing: Spearphishing via Voice) as the initial access vector, followed by T1562. 001 (Impair Defenses: Disable or Modify Tools) if the attacker kills EDR processes, T1059. 001 (Command and Scripting Interpreter: PowerShell) for payload delivery. The lateral movement phase often relies on T1552. 004 (Unsecured Credentials: Domain Account Passwords) stolen via built-in Windows tools while the session is active.

Why Cloud Collaboration Platforms Are Trust Targets, Not Just Tools

Teams, Slack. And Zoom were never designed as security perimeters. They assume that any user who can join a call is trusted to some degree. The underlying real-time communication protocol (WebRTC combined with Microsoft's signaling) exposes session descriptions - ICE candidates, and media streams that, while encrypted in transit, are fully accessible to a remote actor once a call is accepted. This means screen sharing grants near-transparent access to the desktop - a feature, not a bug. The architectural challenge is that the application layer has no native mechanism to authenticate a user's intent beyond a simple "Accept" button.

From an IAM perspective, the attack exploits a collusion of factors: external access policies that permit unverified domains, guest users who can masquerade as Helpdesk by changing their display name. And the absence of session risk scoring for voice channels. Microsoft Entra ID (formerly Azure AD) provides some conditional access signals like unfamiliar sign-in locations for the caller. But voice calls from federated guests don't automatically trigger additional authentication prompts. The attack surface is widened by the fact that the Teams admin center allows external communication with all domains by default, unless explicitly restricted via external access policies

Quick Assist and RMM: The Double-Edged Remote Access Toolchain

Quick Assist (msra exe) is a built-in Windows 10/11 application that provides peer-to-peer remote assistance. It operates over port 443 using TCP, making it blend into normal HTTPS traffic and often bypassing restrictive firewall rules. In several incident response cases, I've seen it used as a vector because the help desk relies on it daily. And its usage is rarely correlated with the caller's identity. Attackers can simply instruct the victim to open Quick Assist and enter a six-digit code, instantly establishing a fully interactive session.

The underlying issue is that Quick Assist's authentication relies on a shared code with no cryptographic binding to the caller's identity there's no MFA challenge embedded in that workflow. Even if the attacker's Teams account is flagged, the Quick Assist session continues independently. For organizations that rely on third-party RMM tools like ConnectWise Control or ScreenConnect, the same principle applies: an attacker can direct the victim to install an instance that phones home to a C2 server, achieving persistence outside of Microsoft's ecosystem. The lack of integrated session auditability between Teams and these remote tools is the blind spot that lets the ransomware payload land unseen.

Chaos Ransomware: Not Just Another Crypto-Locker Variant

Chaos ransomware is an interesting specimen. While not as sophisticated as Conti or LockBit, it's potent in its simplicity - often compiled as a 64-bit binary that uses the Windows CryptoAPI and embeds a ransom note as a resource. Some forks of Chaos are open-source, meaning any actor can compile and customize the strain, as noted in analyses of the CISA ransomware trendsThe payload typically enumerates local and network drives, skips system-critical folders. And performs in-place encryption with a hybrid approach: a fast stream cipher (like Salsa20) for file data, with the symmetric key encrypted by an embedded RSA public key.

From a forensics standpoint, Chaos often leaves a distinct mutex name and registers a persistence mechanism via registry Run keys or scheduled tasks. Its file-naming convention - appending the extension ". chaos" or a variant - is trivially detectable post-exploitation. But the encryption phase can complete before any SOC analyst receives the first endpoint alert. The real engineering problem is that the time-to-detect for these attacks, when initiated through a voice call, is orders of magnitude slower than email-based phishing because there is no SMTP gateway filtering, no attachment sandboxing. And no URL rewriting engine that can intervene.

What Your SIEM Should Have Caught: Key Telemetry Signals

In the aftermath of such an incident, the forensic question is always: "Did we see anything anomalous? " The answer, almost always, is yes - but the signals were scattered across disparate log sources not connected by any correlation rule. Critical indicators include unusual Teams call logs from external users outside the organization's list of allowed federated domains, via the TeamsCalling table in the unified audit log. Microsoft 365's audit log can capture event types like TeamsSessionStarted and TeamsScreenSharingStarted. But these aren't streamed in real time by default.

At the endpoint level, process creation events for msra exe or QuickAssist exe paired with an immediate child process - often powershell exe executing encoded commands - are a high-fidelity signal. EDR solutions like Microsoft Defender for Endpoint and CrowdStrike Falcon can surface this. But only if they monitor parent-child relationships and unusual command-line arguments (-EncodedCommand, Invoke-WebRequest to a sketchy IP). Furthermore, NetFlow logs may show the Quick Assist outbound connection to a Microsoft IP followed by a second connection to an unknown C2 within seconds, signaling the bridge from legitimate to malicious activity.

Hardening Teams External Access Without Breaking Collaboration

Many organizations hesitate to lock down Teams external communications because it conflicts with business agility. However, a principle of least privilege can be enforced via Microsoft Teams External Access Policies that whitelist only specific partner domains. In the Teams admin center, navigating to Users > External access allows you to define an allow list, thereby blocking any incoming call from a consumer account like @outlook com or an untrusted tenant. That single policy change would have thwarted the initial call in these vishing campaigns.

Additionally, Teams Governance and Information Barriers can prevent users from communicating with external guests if they aren't in a designated group. Combined with Azure AD B2B settings that require guest inviter approval and MFA for guest accounts, the blast radius shrinks dramatically. For orgs that must keep external calling open, deploying a call simulator that injects synthetic vishing attempts (similar to phishing simulations) can train employees to verify caller identity through a separate channel-like an internal ticket system. Read more about integrating Teams with your identity governance framework.

Integrating Voice Channel Telemetry into Your Security Operations

Most SIEMs treat voice calls as an opaque event. Yet, Microsoft Graph API now exposes richer call records through the callRecords entity, including organizer IDs, modalities (video, screen sharing). And failure reasons. In a production SOC, we can ingest these records into Azure Sentinel by configuring a Data Connector for Microsoft 365 Defender and writing detection queries that alert on first-time external calls to high-value targets, especially when followed by screen share initiation within a short window.

Consider this Kusto query: OfficeActivity | where Operation == "TeamsCallStarted" | where OrganizerUPN! = "" and OrganizerUPN. And endswith "@yourdomaincom" | join kind=inner (OfficeActivity | where Operation == "TeamsScreenSharingStarted") on CorrelationId | where TimeGenerated between (ago(5m). now()). Coupled with a UEBA baseline, this can surface anomalies like a caller with a newly created account or a display name matching "Helpdesk". The missing link is real-time enrichment - for example, linking the caller's IP to threat intelligence feeds via Azure Sentinel playbooks, then automatically dropping the call if the risk score exceeds a threshold. That's a technically feasible feature, but rarely implemented.

Identity Trust and MFA: Why Voice Social Engineering Still Wins

MFA fatigue is real. But the vishing attack bypasses MFA entirely by not relying on credential theft during the initial phase. The attacker gains access to a legitimate session, not a stolen token. This means that even organizations with strong passwordless authentication and FIDO2 security keys are vulnerable if the victim can be convinced to run arbitrary commands. The session's existing access token (with the user's privileges) is used to encrypt files or reach network shares. No new authentication event triggers a second factor.

The deep lesson here is that identity trust must be layered with endpoint trust. Zero Trust architectures call for continuous verification of device posture. But if a user deliberately grants remote control, the endpoint signals become contradictory: a trusted device performing high-risk actions in quick succession. Solutions like Microsoft Defender for Endpoint's device risk score coupled with conditional access policies that require a compliant device can help. But they won't prevent the user from initiating a Quick Assist session. What's needed is a new policy construct that blocks inbound remote assistance sessions from unmanaged callers. Or at least imposes a "break glass" manual approval step. Link to our blueprint for implementing Zero Trust for remote workers.

Ransomware-as-a-Service and the Democratization of Chaos

Chaos ransomware is emblematic of the RaaS (Ransomware-as-a-Service) model's lower tier, where affiliates can purchase or freely download a builder, customize the ransom note. And start a campaign with minimal infrastructure. The attack described in the BleepingComputer article likely involved an affiliate who paid a commission to the Chaos operators for the encryptor, while the initial access was gained through their own social engineering effort. This separation of roles - initial access broker vs. ransomware affiliate - complicates attribution and means that the same Teams vishing technique could tomorrow deliver BlackCat or Hive payloads.

From an engineering defense perspective, this modularity means that locking down against Chaos alone is insufficient. The detection focus must be on the delivery mechanism (voice phishing + remote access), not the payload hash. Behavioral analytics that profile typical user interaction patterns with remote assistance tools are far more scalable. For instance, tracking the time of day, geolocation of the caller's IP, and the sequence of processes can create a machine learning classifier that flags anomalies. In a production environment, we've used Microsoft Sentinel's anomaly detection templates to surface impossible travel from a Teams guest's IP before a call, correlating it with sign-in data from Azure AD.

Engineering a Resilient Incident Response Plan for Voice-Driven Ransomware

Tabletop exercises rarely include a Teams v