The "IT Support" Trap: UNC6692 Abusing Teams for SNOW Delivery
Just caught the report on UNC6692 leveraging Microsoft Teams for initial access. It’s fascinating to see threat actors pivoting from traditional email phishing to direct chat platforms. The premise is simple but effective: impersonating the IT helpdesk to convince users to accept a chat from an external tenant.
The real headache here is the delivery of the SNOW malware suite. Once the user accepts the chat, the actors typically push a "support" file or a link to a payload. Since this traffic originates from a trusted internal application (Teams), standard email gateways and DLP solutions often miss it.
We've been hunting for similar activity in our environment. The key is flagging external Teams invitations and unusual file transfers. If you're using Microsoft Sentinel, the following KQL query helps identify external users joining Teams chats with a focus on creation dates (new accounts are suspicious):
OfficeActivity
| where OfficeWorkload == "MicrosoftTeams"
| where Operation in ("MemberAdded", "TeamsSessionStarted")
| extend InitiatedBy = tostring(InitiatedBy.User.Id)
| extend TargetUser = tostring(Members[0].UPN)
| where isnotempty(TargetUser)
| project TimeGenerated, Operation, InitiatedBy, TargetUser, TeamName
| where InitiatedBy has "#EXT#"
Currently, our remediation plan involves a Conditional Access policy that blocks external Teams access by default and requires explicit allow-listing.
Has anyone else seen SNOW payloads delivered this way? I'm curious if the malware uses any specific process injection techniques that trip EDRs, or if it's purely living-off-the-land once inside.
We saw a similar attempt last month, though they didn't get far enough to deploy SNOW. The user actually called the real helpdesk because the external invite looked "weird." It highlights that user awareness is still the best defense, even with technical controls.
For detection, we added a trigger for when TeamsIncoming invitations are accepted from domains not in our trusted partner list. One thing to watch: the attackers are now spoofing display names to match your internal IT department, even if the domain is obviously external.
From a sysadmin perspective, the fix is tedious but necessary. You can tighten this down via the AllowGuestsAccess and AllowExternalCommunication settings in the Teams Admin Center, but it breaks collaboration with vendors.
We ended up using a PowerShell script to audit and disable external federation for specific security groups:
Get-CsExternalAccessPolicy | Where-Object {$_.EnableFederationAccess -eq $true}
Set-CsExternalAccessPolicy -Identity Global -EnableFederationAccess $false
It's a heavy-handed approach, but given the UNC6692 report, it might be the only way to stop the initial infection vector before it hits the endpoints.
Interesting that they are using Teams. I tested a similar vector during a red team engagement last year. The "Purple Shield" icon (the external user badge) is the only visual indicator, and most users just assume IT is doing something magical in the background.
Regarding SNOW, the samples I've analyzed from other clusters show it attempts to disable AMSI via PowerShell reflection before decrypting the payload. If your EDR isn't monitoring PowerShell runspace manipulation, the execution might appear benign until it's too late.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access