Microsoft Teams as an Attack Vector: MuddyWater's False Flag Campaign

Great post. We've started correlating DeviceProcessEvents with UnifiedAuditLog data to reduce false positives. We look for a sequence where a user accepts an external Teams invite and immediately runs a PowerShell script. If you block external Teams access by default, you mitigate a lot of this, but for orgs with high collaboration needs, that's not feasible. We also set up a watchlist for known MuddyWater C2 domains in our proxy logs.

This is exactly why I've been pushing to disable external file sharing in Teams for non-corporate devices. You can enforce this via the O365 Admin Center under 'External sharing'. While it doesn't stop the phishing invite itself, it prevents the initial dropper from landing if they try to push a malicious .exe or script attachment through the chat interface.

From a pentester's perspective, this vector is devastating because users are conditioned to trust Teams notifications. Unlike email, which people are skeptical of, a 'meeting request' in Teams feels urgent and legitimate. For detection, consider looking for Teams.exe making network connections to non-Microsoft IP addresses directly, as it might be trying to reach the attacker's C2 if they manage to inject code into the process space.

Don't overlook the risk of malicious app sideloading via Teams tabs. We've seen attempts to persist by adding external apps to team chats. To monitor this specific behavior in your environment, you can use this KQL query in Advanced Hunting:

kusto DeviceEvents

| where ActionType == "AppInstall"
| where InitiatingProcessFileName =~ "Teams.exe"
| where FileName endswith ".appx"
| summarize count() by DeviceName, FileName

To catch the credential theft phase mentioned, monitor for OAuth consent grants. Attackers often use Teams to prompt users into authorizing malicious apps (consent phishing). You can hunt for this specific activity by querying the UnifiedAuditLog for consent operations:

kusto UnifiedAuditLog

| where Operation in ("ConsentToApplication", "Add-AppRole")
| where Result == "Success"
| project TimeGenerated, UserId, ActorContextId, ModifiedProperties

Detecting these spikes early prevents the long-term persistence you mentioned.

Since this campaign relies on users reacting quickly to 'urgent' external communications, enforcing Conditional Access policies that require compliant devices for external Teams federation is a strong control.

For detection, here is a KQL query to hunt for Teams spawning suspicious child processes, which is a key indicator of the post-exploitation activity:

kusto DeviceProcessEvents

| where InitiatingProcessFileName == "Teams.exe"
| where FileName in ("powershell.exe", "cmd.exe", "mshta.exe")
| project Timestamp, Account, DeviceName, CommandLine

This helps catch the transition from social engineering to credential theft.

Since the lures often masquerade as urgent business updates, consider tuning DLP policies for Teams to flag specific keyword combinations (like "invoice" + "urgent") sent from external domains. It’s a noisy rule, but effective when scoped to sensitive departments.

Also, to catch the follow-on PowerShell activity often seen with MuddyWater, you can hunt for child processes spawned by Microsoft.Teams:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -like '*Microsoft.Teams*' -and $_.Message -like '*powershell.exe*'}

Excellent insights on the cloud side. To complement the UnifiedAuditLog hunting, don't ignore endpoint telemetry for the execution phase. We've seen Teams.exe spawn suspicious child processes like PowerShell or MSHTA when payloads execute.

You can hunt for this anomaly in Sentinel using:

kusto DeviceProcessEvents

| where InitiatingProcessFileName == "Teams.exe"
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
| project DeviceName, FileName, ProcessCommandLine, InitiatingProcessParentId

Catching this early prevents the persistence mentioned in the report.