Teams vishing is back — and it can be a state-backed cover story

A Rapid7 investigation described a targeted intrusion that used Microsoft Teams as the entry point: attackers initiated external chat requests, persuaded employees to join screen-sharing sessions, harvested credentials, and manipulated multi-factor authentication (MFA). The activity was attributed to the Iranian-linked group commonly tracked as MuddyWater (also known as Mango Sandstorm, Seedworm, and Static Kitten) and was framed as a “false flag” ransomware operation — designed to resemble opportunistic extortion while serving a strategic objective.

What’s known (and what Rapid7 says happened)#

Rapid7 reported observing the campaign in early 2026. The key theme is not a novel exploit. It’s a high-touch social engineering sequence conducted inside a tool most organizations treat as “normal business.”

According to Rapid7’s description, the intrusion flow looked like this:

• The attacker initiates external chat requests over Microsoft Teams to reach employees.
• The conversation moves into interactive screen-sharing, where the attacker can guide user actions in real time.
• Credentials are harvested during that session, and MFA is manipulated (Rapid7’s wording suggests the attacker used the session to get the victim to approve prompts or otherwise facilitate MFA bypass).
• Once inside, the attacker uses the compromised account(s) for reconnaissance and to expand access.
• Instead of following a classic ransomware workflow (encrypting large volumes of files), the attacker prioritizes data exfiltration and long-term persistence.
• Persistence is established via remote management tools such as DWAgent; Rapid7 also mentioned AnyDesk in at least one instance.
• The victim is contacted via email for ransom negotiations.

Rapid7 also described additional technical details consistent with a staged intrusion rather than a quick smash-and-grab. The attacker was observed using RDP and a curl command to download an executable named ms_upd.exe from an external server (172.86.126[.]208). Execution reportedly kicked off a multi-stage chain that collected system information, reached out to command-and-control (C2), and dropped additional components (including files named game.exe, WebView2Loader.dll, and visualwincomp.txt). Rapid7 characterized part of this as a bespoke RAT that masquerades as a legitimate application and leverages a trojanized Microsoft WebView2 sample project.

Some portions of the republished source text are truncated, so treat the component list and naming as incomplete context rather than a full malware write-up.

Why this matters: “ransomware” can be an attribution shield#

The most operationally useful point here is not the brand name attached to the extortion note. It’s the way tradecraft is being mixed.

Rapid7’s framing (as quoted) is that the operator “bypassed traditional ransomware workflows,” skipping broad file encryption in favor of exfiltration and persistence via common remote management tooling. That choice matters because it changes what defenders should look for:

• If you only alert on bulk encryption behavior, you may see nothing.
• If you treat remote admin tooling as “IT stuff,” you may miss the persistence layer.
• If you assume “ransomware-as-a-service (RaaS)” implies noisy, opportunistic crimeware, you may underweight the possibility of a targeted state-backed objective.

The report also points to a broader trend: using off-the-shelf tools and crime-ecosystem brands to complicate attribution. In the same source item, other researchers (Ctrl-Alt-Intel, Broadcom, Check Point, and JUMPSEC) are cited as observing MuddyWater leaning on underground tooling in recent months.

The “false flag” concept here is practical, not cinematic. It means defenders and incident responders can be steered toward the wrong playbook: negotiating with “a ransomware gang,” focusing on an encryptor that never arrives, and missing the longer-lived access that enables strategic collection.

Teams as an initial access vector is a policy problem, not a zero-day#

Microsoft Teams gets used as a social-engineering delivery channel because it is already trusted, interactive, and hard for users to distinguish “legitimate internal help” from an external conversation when external chat is allowed.

The Rapid7 description highlights a familiar psychological advantage: screen-sharing collapses friction. The attacker doesn’t need to send a complex phishing page if they can:

• walk the user through steps,
• ask them to type credentials into a local file (as Rapid7 described),
• and coach them through approving MFA prompts.

This also creates a logging and visibility gap. Many organizations have mature controls for email phishing and web proxies, but weaker detection around:

• external Teams chat requests,
• unusual screen-sharing sessions,
• or sudden installation/use of remote support tools after a chat.

The campaign described in the source also overlaps with known “Teams vishing” patterns used by some RaaS crews: impersonate IT support, push the victim to install remote access tools (Microsoft Quick Assist is mentioned in the same source item as a tactic used by the RaaS group “Chaos”), then deepen access.

Even if your organization is not being targeted by MuddyWater specifically, the playbook is transferable. That’s the point.

What not to overclaim from this source#

A few edges are easy to get wrong if you compress this into a single narrative:

• This is attribution, not proof in court. The source summarizes Rapid7’s assessment and cites other firms’ reporting; it does not provide raw evidence for independent verification.
• The term “false flag” can be overstated. The practical claim is that the intrusion looked like a RaaS-branded operation at first glance, while the reported intent and tradecraft suggested a targeted state-backed actor.
• The republished text includes indicators (file names, an IP, tool names) but parts of the malware section appear truncated. Don’t treat this as a complete IOC pack.
• The source discusses multiple groups and timelines (MuddyWater, “Chaos,” mentions of Qilin/Thanos). Those references provide context, but they do not necessarily mean the same operator or exact tooling is shared across all incidents.

Practical takeaways: what defenders can change quickly#

If Teams (or any collaboration platform) can be used to reach employees from outside the organization, you need controls that assume it will be abused.

🛠️ Immediate hardening moves

• Tighten external access: restrict who can initiate chats from outside the tenant; consider allowlists for known partner domains.
• Reduce “high-trust” UI paths: limit or govern screen-sharing with external users; require explicit warnings or approvals where possible.
• Treat remote admin tools as dual-use: add detections for DWAgent/AnyDesk/Quick Assist installs and first-time executions; baseline what “normal IT” looks like.
• Monitor MFA manipulation signals: alert on repeated prompts, unusual approvals, or sign-in anomalies that cluster around user-reported “support” interactions.

🔎 Detection and response ideas

• Correlate: external Teams chat → screen-sharing start → remote tool install → new persistence/service creation → outbound data movement.
• Hunt for: users creating local text files to store credentials (as described by Rapid7) during remote sessions; it’s a weird behavior worth flagging.
• Review: RDP use on endpoints that don’t normally need it, especially when paired with command-line downloads (e.g., curl fetching executables).

👥 User training that matches the attack

• Teach a single rule that survives pressure: “Real IT won’t ask you to type credentials into a file or approve MFA prompts to ‘fix’ something.”
• Give users a fast verification path: a known internal ticketing channel or callback procedure that is easier than complying in the moment.

What to check next if this hits your environment#

• Your tenant’s external Teams configuration (who can message whom, and from where).
• Endpoint inventory for remote access tools and “remote monitoring and management” agents, including those installed outside standard software deployment.
• Conditional access policies and sign-in logs for unusual device enrollment, impossible travel, or atypical IP ranges around the time of a suspicious Teams interaction.
• Data egress visibility (proxy, firewall, EDR network telemetry). This campaign description emphasizes exfiltration over encryption.

If you want a single mental model: treat collaboration apps as interactive phishing surfaces. The attacker’s advantage is conversation and control, not a link.