UNC6692 and SNOW Malware: When IT Helpdesk Calls via Teams
Just caught the report on UNC6692 using Microsoft Teams to deploy their new 'SNOW' malware suite. It's a classic social engineering play—impersonating the IT helpdesk to get a user to accept a chat invitation from an external tenant.
Since this is an undocumented cluster, the IOCs are still evolving, but the TTPs are clear: they rely on the default openness of Teams federation. Once the victim accepts the chat, the attackers likely move to deploy the payload via a malicious link or attachment dropped in the chat interface.
I've started putting together some detections. For those using Sentinel, hunting for sudden spikes in external tenant additions is a good start:
OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation == "MemberAdded" and OfficeWorkload == "MicrosoftTeams"
| where UserId contains "ext" or UserId contains "#EXT#"
| extend TenantDomain = tostring(split(UserId, "@")[1])
| summarize count() by TenantDomain, bin(TimeGenerated, 1h)
| where count_ > 5
On the prevention side, we might need to be more aggressive with External Access Policies in Skype for Business Online / PowerShell. Checking your current federation settings is critical:
Get-CsExternalAccessPolicy -Global | Select-Object EnableFederationAccess, EnablePublicCloudAccess
Given how users are conditioned to trust "IT Support," blocking external federation entirely might be the only safe play for high-security environments, but that kills collaboration. How are you guys balancing the risk of Teams-based social engineering against business needs for external chat?
We implemented a strict allow-list for federation domains last quarter after a similar phishing spike. It’s a bit of overhead to onboard new partners, but it completely stops the 'random external helpdesk' vector. You can restrict domains via the Admin Center or use the Set-CsTenantFederationConfiguration cmdlet. Definitely worth the operational friction compared to dealing with a SNOW malware outbreak.
Good catch on the KQL. I'd add a correlation to look for ProcessStart events immediately following those Team additions. If you see powershell.exe or mshta.exe spawning right after an external invite hits, that's your smoking gun. We're also inspecting MicrosoftTeams logs in the Unified Audit Log for 'ChatCreated' operations from unverified domains.
The hardest part is user training. They see the purple 'Teams' icon and assume it's internal. We've started running internal phishing simulations using external Teams accounts just to test awareness. The failure rate is scary high—around 45% accepted the chat. Blocking federation is the only real control until Microsoft adds better warning banners for external chats.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access