MuddyWater's Chaos False Flag: The Microsoft Teams MFA-Bypass IR Playbook for SMBs

On May 6, 2026, Rapid7's threat research team published a detailed reconstruction of an intrusion that looked like opportunistic ransomware and turned out to be Iranian state-sponsored espionage flying a Chaos-RaaS flag. The threat actor is MuddyWater - also tracked as Mango Sandstorm, Seedworm, and Static Kitten, and assessed with moderate confidence to be tied to Iran's Ministry of Intelligence and Security. The targets were U.S. construction, manufacturing, and business-services firms. The initial access did not require a CVE, a phishing payload, or a credential-stuffing list. It required one Microsoft Teams chat.

Per The Hacker News coverage of the Rapid7 report, the operators initiated one-on-one Teams chats from compromised external accounts, established interactive screen-sharing sessions, walked the victim through typing credentials into local files named credentials.txt and cred.txt, then directed the victim to add an attacker-controlled device to their MFA configuration. Once MFA was extended, the operators dropped DWAgent and AnyDesk for remote control, staged a custom downloader (ms_upd.exe) and a custom RAT masquerading as Microsoft WebView2 (Game.exe), and proceeded to exfiltrate data. No encryption. The Chaos branding on the ransom note was theater.

This is the part SMBs need to read twice: the entry vector and the persistence vector are both Microsoft 365 defaults. External Teams chat is on out of the box. End-user self-service registration of MFA methods is on out of the box. The attacker did not exploit a software flaw - they exploited two tenant configurations that ship enabled in every Business Standard and Business Premium subscription. The same kit, with a different ransom-note template, lands on any 200-person company that has not turned those two settings off.

The full kill chain in five moves

Reconstructing from the Rapid7 indicators, the sequence is:

1. External Teams chat from a compromised tenant. The operator messaged employees from previously-burned third-party Microsoft 365 accounts, posing as IT support. Teams renders these as "[External]" but the badge is small, the chat looks native, and the social-engineering pretext typically references a known vendor or partner the target actually deals with.
2. Interactive screen-share for "verification." The operator opened a screen-share, then walked the user through opening Notepad, typing the user's password and username into credentials.txt, and saving the file to the desktop. A spoofed Quick Assist verification URL at adm-pulse[.]com/verify.php reinforced the impersonation.
3. MFA device add (T1556). The operator directed the user to their own MFA self-service page and instructed them to add a new authenticator app or phone number - the attacker's. This is the single most damaging step. The legitimate user still has their MFA. So does the attacker. Standard "you have MFA enabled" reporting still shows green.
4. DWAgent and AnyDesk deployment. With valid creds plus a working MFA factor, the operator authenticated as the user from a fresh IP, dropped DWAgent (dwagent.exe, pythonw.exe, dwagsvc.exe, dwaglnc.exe) and AnyDesk, then beaconed to moonzonet[.]com.
5. Custom RAT and exfil. ms_upd.exe (SHA256 24857fe82f454719cd18bcbe19b0cfa5387bee1022008b7f5f3a8be9f05e4d14) retrieved Game.dll, Game.exe, and Game.config. The RAT registered to uploadfiler[.]com:443, masqueraded as Microsoft WebView2, and supported twelve capabilities including command execution, file transfer, and credential dumping. Data left the network. No files were encrypted. A Chaos-themed ransom note was dropped to confuse triage.

The signed downloader carried a code-signing certificate registered to "Donald Gay" (thumbprint B674578D4BDB24CD58BF2DC884EAA658B7AA250C), a known shared MuddyWater resource Rapid7 had previously linked to Operation Olalampo against U.S. and MENA targets. Together with infrastructure overlap on moonzonet[.]com, the attribution is well-grounded.

Why this hits SMBs harder than enterprise

Three reasons. First, large enterprises with mature SOCs have already restricted Teams external chat to a small allowlist of federated partners and have removed end-user MFA self-service in favor of administrator-driven registration with token-protection policies. Most SMBs have done neither. Second, the social-engineering pretext - "IT support running a verification" - is wholly believable in an org where users genuinely do hear from an outsourced MSP they have never met. Third, the indicators of compromise here look like normal IT behavior: AnyDesk and DWAgent are legitimate remote-management tools the company's MSP may already use. An EDR alert on AnyDesk.exe is noise unless someone has policy that says it is.

Hunt your tenant for the next 30 days

If you run Microsoft 365 with E3, E5, or Business Premium, you have the audit data to detect this campaign retroactively. The two queries below run against the Microsoft 365 Unified Audit Log via the Microsoft Graph Security API or the Microsoft 365 Defender advanced hunting console. Run them across the last 30 days as a baseline, then on a weekly cadence going forward.

// KQL: external Teams 1:1 chats initiated against your users in the last 30 days
// Hunts the pattern of an external account starting a private chat with a single internal user.
CloudAppEvents
| where Timestamp > ago(30d)
| where Application == "Microsoft Teams"
| where ActionType in ("ChatCreated", "MessageSent")
| where RawEventData has "external" or RawEventData has_cs "[External]"
| extend Initiator = tostring(RawEventData.UserId)
| where Initiator !endswith "@yourdomain.com"
| project Timestamp, Initiator, AccountObjectId, IPAddress, RawEventData
| order by Timestamp desc

// KQL: user-added MFA methods in Entra audit log
// MuddyWater's signature step. Investigate every result that is not a known user-driven change.
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Add registered security info",
                          "User registered security info",
                          "Update user")
| where Result == "success"
| extend Target = tostring(TargetResources[0].userPrincipalName)
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, Target, Initiator, IPAddress = tostring(InitiatedBy.user.ipAddress)
| order by TimeGenerated desc

Pivot any hit on the second query into the sign-in logs for that user and look for an authentication from a new country or ASN within 24 hours of the MFA change. That is the indicator that the new factor was used, not that a legitimate user replaced a lost phone.

On the endpoint side, add explicit detections for the Rapid7 indicators. The hashes for ms_upd.exe and Game.exe belong in your EDR's custom indicator list today. The remote-management binaries belong in a separate watchlist. The presence of DWAgent.exe or AnyDesk.exe on a host that has never run them before, especially one that does not interact with your MSP, is a Sev-2 starter.

# PowerShell: scan endpoints for the public MuddyWater binaries and RMM persistence
# Run via your endpoint management platform (Intune, NinjaOne, Kaseya, etc.).
$badHashes = @(
  "24857fe82f454719cd18bcbe19b0cfa5387bee1022008b7f5f3a8be9f05e4d14",  # ms_upd.exe
  "1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6",  # Game.exe
  "a92d28f1d32e3a9ab7c3691f8bfca8f7586bb0666adbba47eab3e1a8faf7ecc0",  # DIDS.exe
  "3df9dcc45d2a3b1f639e40d47eceeafb229f6d9e7f0adcd8f1731af1563ffb90"   # WebView2.exe variant RAT
)
$rmmBinaries = "AnyDesk.exe","dwagent.exe","dwagsvc.exe","dwaglnc.exe"

Get-ChildItem -Path "C:\Users","C:\ProgramData","C:\Windows\Temp" -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $rmmBinaries -contains $_.Name -or $badHashes -contains (Get-FileHash $_.FullName -Algorithm SHA256).Hash } |
  Select-Object FullName, LastWriteTime,
    @{n="SHA256";e={(Get-FileHash $_.FullName -Algorithm SHA256).Hash}}

Block the three IOC domains at your DNS resolver, your egress firewall, and your secure web gateway: moonzonet[.]com, uploadfiler[.]com, and adm-pulse[.]com. The first two are dead infrastructure now, but the third was the social-engineering lure and may rotate to a sibling subdomain.

Five hardening steps to close the door

Detection finds intrusions in progress. Configuration closes the door entirely. Five steps, all free if you already pay for Microsoft 365.

1. Restrict Teams external access to an allowlist

The Teams external-access policy by default permits chat with any external Microsoft 365 tenant. Change that to allow only your known federated partners, or block all external access outright if you do not federate. The PowerShell to apply a global block:

# Microsoft Teams: block all external tenants, then allow specific partners
Connect-MicrosoftTeams
Set-CsTenantFederationConfiguration -AllowFederatedUsers $false
Set-CsTenantFederationConfiguration -AllowTeamsConsumer $false
Set-CsExternalAccessPolicy -Identity Global `
    -EnableFederationAccess $false `
    -EnableTeamsConsumerAccess $false `
    -EnablePublicCloudAccess $false

# If you do need federation with specific partners, allowlist them:
Set-CsTenantFederationConfiguration -AllowFederatedUsers $true `
    -AllowedDomainsAsAList @("partner1.com","msp.example.com")

Per the Microsoft Learn guidance on trusted-organizations external meetings and chat, you can also push this through the Teams Admin Center under External Access. Microsoft also rolled out a centralized block list in the Defender portal in January 2026 that holds up to 4,000 domains - useful if a future MuddyWater operator burns a new tenant.

2. Lock down MFA registration via Conditional Access

The user-adds-MFA-device step is the campaign's pivot point. Remove that capability from end users via a Conditional Access policy that requires registration of new authentication methods to occur from a trusted location and through a privileged Identity Protection flow. Set Authentication methods > Authentication strengths to require phishing-resistant MFA (FIDO2 or Windows Hello for Business) for the registration action itself. The result: a help-desk-driven re-registration replaces the user-driven one, and no chat message can talk a user through it.

3. Treat all remote-management tools as Tier-1 controlled apps

AnyDesk, DWAgent, ScreenConnect, Splashtop, TeamViewer, RustDesk, and Quick Assist are all legitimate. They are also the most common post-access tooling in 2026 intrusions. Pick one that your MSP needs, allowlist it through your EDR's app-control policy or Windows Defender Application Control, and block the rest. Add an alert on first execution of any allowlisted RMM on a host that has not run it in the last 30 days.

4. Force Quick Assist out of the equation

The adm-pulse[.]com/verify.php spoof imitated Quick Assist. The real Quick Assist requires the helper to send a six-digit code, and there is no legitimate reason for any outside party to walk an employee through entering credentials into a text file. Disable Quick Assist via Intune or Group Policy on machines outside the IT support team. Replace it with a sanctioned remote-assistance flow that requires the help desk to initiate, not the end user to accept.

5. Add a verbal-callback rule to your help-desk procedure

The cultural fix is the cheapest one and the one most SMBs skip. Document that any "IT support" request that arrives in Teams chat, email, SMS, or phone call must be verified through a callback to a number on the corporate directory before any credentials, MFA changes, or remote-control sessions occur. Train your users to hang up and call back. The ADT vishing breach earlier this month and this MuddyWater campaign share that single defensive control: a verbal callback would have broken both intrusions.

Why the false flag actually matters

The natural reaction to a Chaos ransom note is to treat the incident as a financially motivated extortion, work the negotiation, and rebuild. That response leaves the espionage objective untouched - the data is already gone, the persistence is still on the box, and the operator now has the time and runway to live in your environment for months. The Rapid7 assessment is explicit that the absence of encryption is the behavioral signal: ransomware crews encrypt because encryption is the leverage. When encryption is missing, the leverage is the data itself, and that data is now somewhere the operator chose.

The corollary for SMB defenders is to treat every apparent ransomware incident as an espionage incident until encryption-or-no-encryption is verified within the first eight hours. If files are not encrypted, work the case as data theft plus persistence, not as extortion. The forensic priorities flip. Image the box, pull memory, capture the RMM telemetry, search the Entra audit log for MFA method adds and Teams chat events, and assume the operator is still resident until proven otherwise.

The patch for this is configuration, not a CVE. Restrict external chat. Move MFA registration behind Conditional Access. Allowlist your remote-management tools. Kill Quick Assist for non-support users. Make your help desk verify by callback. Five changes, none of which require a budget request, all of which break this exact intrusion at one of five different layers. The MuddyWater operator working through this kit right now is counting on every one of those settings staying at default.