Ransomware · Social Engineering

Microsoft Teams Vishing Campaign STAC4749 Delivers Chaos Ransomware in Under 17 Hours

July 31, 2026 · 6 min read

A phone call from someone claiming to be your IT helpdesk is all it took. Sophos published research on July 28, 2026 documenting a campaign they call STAC4749, where attackers spent February through June 2026 calling employees at dozens of North American organizations over Microsoft Teams, impersonating internal IT support staff, and talking victims into handing over remote control of their workstations. From there, in at least three cases, the operators deployed Chaos ransomware, in one incident completing the entire chain from first contact to encryption in under 17 hours. This is a technically unsophisticated attack path that repeatedly worked because the social engineering was disciplined and the victims had no friction standing between a phone call and full remote access.

What actually happened

The STAC4749 operators built a credible IT helpdesk persona on Teams, using cloud domains registered under the .top TLD with realistic helpdesk-style usernames. They initiated contact through Teams chat and voice calls, with call durations ranging from 90 seconds to over 20 minutes and averaging around two to two-and-a-half minutes. That is a short window in which to convince someone to install remote-access software, which tells you the social engineering script was tight and the targets were not suspicious of Teams-based IT contact.

Initially, the group used Microsoft Quick Assist to establish remote access. When organizations began blocking Quick Assist, the attackers moved to a cloud-based RMM tool called RemSupp, and by approximately April 2026 RemSupp appeared to be their preferred tool outright. In intrusions that progressed to ransomware, they also installed DWAgent and AnyDesk and attempted to enable RDP, giving themselves multiple redundant footholds. After securing access, STAC4749 deployed a modular custom loader and backdoor to maintain persistence and support follow-on activity.

At least three intrusions resulted in Chaos ransomware deployment, and in at least one case the attackers likely exfiltrated data before encrypting, which is the double-extortion pattern that has become standard for financially motivated ransomware operators. Sophos assessed with high confidence that this is a financially motivated group, either operating the ransomware directly or coordinating with affiliates. Chaos itself is a ransomware-as-a-service operation active since at least February 2025, and Cisco Talos assessed with moderate confidence that it was founded by former members of the BlackSuit (Royal) ransomware operation.

One other detail worth noting: STAC4749 continuously modified its attack chain throughout the campaign, changing malware filenames, persistence labels, and delivery methods between February and May 2026. That kind of operational hygiene makes signature-based detection unreliable, which is part of why these intrusions progressed as far as they did. This is also the same playbook, Teams vishing plus Quick Assist, that Microsoft first documented in mid-2024 against Black Basta via the Storm-1811 threat actor, and that Sophos previously linked to 3AM ransomware in a report from May 2025. The technique is maturing and spreading across multiple ransomware operations.

Why this should matter to you even if you don’t run Microsoft Teams

You do not need to run a Microsoft Teams-heavy environment for this to concern you. The underlying problem here is that employees across many organizations have been conditioned to accept IT support requests through whatever channel the supposed IT person uses, whether that is email, Teams, Slack, or a phone call. Attackers are well aware of this conditioning. Any platform your employees use to communicate with internal IT is a surface that can be impersonated, and the STAC4749 campaign shows that the impersonation does not need to be elaborate to succeed.

The specific RMM tools involved (Quick Assist, RemSupp, DWAgent, AnyDesk) are all legitimate software. Blocking one, as some organizations apparently did with Quick Assist, did not stop the campaign because the attackers simply switched tools. If your policy is to block specific applications rather than to control the conditions under which remote access is authorized, you are playing catch-up against a group that can adapt in a day.

The timeline is the part I find most operationally alarming. Under 17 hours from a Teams call to encrypted files is faster than most incident response programs can mobilize. If your detection and response depends on catching post-exploitation activity after an attacker has already established persistence, you may be outside your response window before an alert fires. The control that matters most here is the one that stops the initial access from succeeding, because once a legitimate RMM agent is running under a user's credentials, the attacker looks like your IT team to most monitoring tools.

The control that would have blunted it

The control that would have meaningfully disrupted STAC4749 at the earliest stage is a strict, verified process for IT-initiated remote access, combined with MFA enforcement on every account that could be used to authorize or receive that access. This is what cyber insurers increasingly require when they ask about privileged access management and remote-access controls. The specific mechanisms matter: MFA on the employee account being accessed, MFA or equivalent verification on any helpdesk identity initiating contact, and a defined out-of-band verification step before any remote-access tool is installed.

In practice, that out-of-band verification is the part organizations skip because it creates friction. The operational tradeoff is real: requiring employees to verify a helpdesk request through a second channel (a callback to a known internal number, a ticket number matched against a ticketing system the employee can independently access) slows down legitimate IT support calls. That friction is the point. STAC4749 calls averaged two to two-and-a-half minutes. A verification step that adds three minutes to the call will stop most of these attacks, because the attacker's model depends on speed and minimal resistance.

Beyond the verification process, there are several supporting controls worth examining. Restrict which RMM tools are permitted in your environment and block outbound installation of unsanctioned remote-access clients at the endpoint or network layer. This does not prevent a determined attacker from finding another tool, but it raises the cost and increases the chance of a detection event. Audit and alert on Quick Assist, AnyDesk, and similar tools launching under user context, because legitimate IT departments in most organizations have predictable patterns for when and how they use these tools. Deviations from those patterns are detectable if you have a baseline.

For Teams specifically, Microsoft provides controls to restrict who can initiate external chats and calls. If your organization's IT staff operate from internal tenants, there is limited reason to allow unsolicited inbound Teams contact from external tenants to reach general employees. Restricting external Teams access does carry a cost if you use Teams for legitimate external collaboration, so this requires a policy decision rather than a blanket block, but the default-allow posture is what STAC4749 depended on. Review your Teams external communication settings, and make sure employees know that a Teams call from an IT-looking account is not, by itself, proof that the caller is your IT team.

Our MFA and access-awareness program covers the verification workflows and employee training that help organizations build friction into remote-access requests without crippling IT operations.