UNC6692 Uses Microsoft Teams Helpdesk Impersonation to Deploy SNOW Malware

A threat group tracked as UNC6692 used Microsoft Teams helpdesk impersonation, email bombing, and a custom malware suite called SNOW to gain deep access inside a victim network.

The campaign was detailed by Google Threat Intelligence Group and Mandiant, which described a multi-stage intrusion that started with social engineering and ended with access to domain controller data.

UNC6692 did not rely on a software exploit for initial access. The attackers created a support crisis, contacted the victim through Microsoft Teams, and convinced the user to install what looked like a local patch for an email spam problem.

How the UNC6692 Teams attack worked

The attack began with an email-bombing campaign designed to overwhelm the victim’s inbox. That flood created urgency and made the later fake helpdesk message feel more believable.

After the victim faced the spam flood, the attacker contacted them through Microsoft Teams while posing as IT support. The message offered help and told the user to install a patch that would stop the email problem.

The victim then opened a phishing page that downloaded a renamed AutoHotkey binary and an AutoHotkey script from an attacker-controlled AWS S3 bucket. According to ExtraHop’s analysis, this multi-channel approach let the attacker move around traditional email-only security controls.

Stage	What the victim saw	What UNC6692 did
Email bombing	A sudden flood of unwanted messages	Created pressure and distraction
Teams contact	A message from someone posing as IT support	Built trust through a familiar collaboration tool
Fake patch	A mailbox repair or spam protection page	Delivered AutoHotkey-based malware
SNOW deployment	No obvious infection warning	Installed browser, tunneling, and backdoor components
Post-compromise activity	Normal workstation behavior	Scanned the network, stole credentials, and moved laterally

Why Microsoft Teams was useful to the attackers

Microsoft Teams is a trusted workplace tool, which makes it attractive for social engineering. Employees often expect IT support to contact them through Teams, especially during urgent account or email issues.

The abuse also depends on external communication settings. Microsoft documents how administrators can control cross-tenant and external communication through Teams external access settings, including which external domains users can communicate with.

If organizations allow broad external Teams chats, attackers can reach employees without needing to compromise an internal mailbox first. That makes helpdesk impersonation harder for users to judge quickly.

The fake mailbox repair page

The phishing page posed as a mailbox repair and sync utility. It asked the victim to perform a health check, then used that interaction to drive the next stage of the infection.

Google said the page included anti-analysis behavior, including checks designed to deliver the payload only to intended targets and avoid automated sandbox environments.

Once the victim interacted with the page, the downloaded AutoHotkey files triggered initial reconnaissance and installed SNOWBELT, a malicious Chromium browser extension that was not distributed through the Chrome Web Store.

What is the SNOW malware suite?

SNOW is not a single malware file. It is a modular toolkit made of three main components: SNOWBELT, SNOWGLAZE, and SNOWBASIN.

The Google Cloud report says the components worked together as a pipeline, giving the attacker browser-based access, a tunnel into the victim’s internal network, and a local backdoor for command execution.

The design allowed UNC6692 to keep access after the first phishing interaction. It also helped the attacker route commands and data through components that looked less suspicious than obvious malware traffic.

Component	Type	Main role
SNOWBELT	Malicious Chromium browser extension	Acts as the initial foothold and relays commands
SNOWGLAZE	Python-based tunneler	Creates an authenticated WebSocket tunnel and supports proxy traffic
SNOWBASIN	Python-based local HTTP backdoor	Executes commands, captures screenshots, moves files, and supports exfiltration

How SNOWBELT gained persistence

SNOWBELT was installed as a browser extension and loaded through Microsoft Edge in a windowless or headless mode. The attackers used scheduled tasks to keep the extension running and to manage unwanted headless Edge processes.

This approach is notable because it abuses a legitimate browser process instead of launching a more obvious standalone malware binary. Security teams may miss it if they only look for unknown executables.

Administrators can manage browser extension behavior with Microsoft Edge policies. Microsoft’s ExtensionInstallBlocklist policy can block extension installation patterns, while allowlists can limit installations to approved extensions.

What SNOWGLAZE and SNOWBASIN did

SNOWGLAZE helped the attacker route traffic through the compromised host. Google described it as a Python tunneler that could create an authenticated WebSocket tunnel and support SOCKS-style proxy operations.

SNOWBASIN acted as a local HTTP backdoor, typically listening on local ports such as 8000, 8001, or 8002. It supported command execution, screenshot capture, file download, file deletion, and self-termination.

These components made the victim workstation a bridge into the internal network. Once the tunnel existed, UNC6692 could scan services, move laterally, and reach systems that would not normally face direct internet exposure.

• SNOWBELT helped maintain browser-based persistence.
• SNOWGLAZE helped route attacker traffic into the network.
• SNOWBASIN gave operators command execution and file access.
• AutoHotkey helped launch the early infection chain.
• Cloud storage and web services helped hide parts of the activity in normal traffic.

From workstation compromise to domain controller access

After initial access, UNC6692 scanned the local network for ports commonly tied to Windows administration and remote access, including 135, 445, and 3389.

The attackers then used a PsExec session through the SNOWGLAZE tunnel, enumerated local administrator accounts, and moved to a backup server. Google said they later extracted LSASS process memory and exfiltrated it through LimeWire.

With elevated credential material, the group used pass-the-hash to access domain controllers. They then downloaded FTK Imager, collected NTDS.dit and registry hives, and exfiltrated the data.

Why this campaign is hard to stop

The campaign combines common workplace behavior with custom tooling. A user overwhelmed by email spam may welcome a helpdesk message, and a Teams chat feels less suspicious than an unknown email attachment.

ExtraHop said the campaign shows how adversaries now chain email, collaboration platforms, browser tooling, cloud services, and internal network movement into one coordinated sequence. The SNOW malware analysis also notes that the final impact included compromise of domain controller infrastructure.

The attack also creates alerting challenges because several steps involve legitimate tools or services, including Microsoft Teams, Microsoft Edge, AutoHotkey, AWS S3, Python, PsExec, and FTK Imager.

Defensive challenge	Why it is difficult	What to monitor
Teams impersonation	External chat can look like normal collaboration	External chat requests, unknown domains, helpdesk-themed messages
AutoHotkey execution	Can look like automation software	Unexpected AutoHotkey binaries and scripts in user folders
Headless Edge	Uses a legitimate browser process	Edge launched with extension-loading and headless arguments
SNOWGLAZE tunnel	Uses encrypted web traffic	Unusual WebSocket connections and proxy behavior
Credential theft	Uses legitimate admin tools	LSASS dumps, PsExec activity, NTDS.dit access, FTK Imager execution

Warning signs for security teams

Organizations should look for a combination of user reports and endpoint signals. A sudden email flood followed by an external Teams request should trigger helpdesk verification and security review.

Technical indicators include AutoHotkey execution shortly after Teams activity, Microsoft Edge launched with load-extension and headless arguments, unusual scheduled tasks, Chromium extension folders with names such as SysEvents, and local HTTP services on unexpected ports.

Network teams should also watch for unexpected WebSocket tunnels, cloud storage uploads, LimeWire use in enterprise environments, and internal scanning from ordinary user workstations.

Recommended defenses

The first defensive layer is policy. Organizations should restrict who can receive external Teams messages and which external domains can communicate with users through Teams.

Microsoft’s external access documentation gives administrators options to allow or block external domains. High-risk organizations should avoid broad open external access unless business requirements justify it.

The second layer is endpoint hardening. Browser extension controls, script execution monitoring, and suspicious scheduled task detection can help catch the SNOW infection chain before it reaches internal systems.

1. Restrict Microsoft Teams external access to approved domains.
2. Train employees to verify unexpected helpdesk chats through a known support channel.
3. Block or alert on unsolicited Teams links that claim to install patches or mailbox repairs.
4. Monitor AutoHotkey execution from download folders, temporary paths, or user profile directories.
5. Alert on Microsoft Edge launched with headless and load-extension arguments.
6. Limit browser extension installation to approved extensions.
7. Monitor WebSocket tunnels, PsExec activity, LSASS dumps, and NTDS.dit access.

How to harden browser extension controls

Because SNOWBELT relies on a malicious Chromium extension, browser management matters. Enterprises should enforce an extension allowlist for sensitive users and block extensions that load from untrusted local paths.

The Microsoft Edge extension policy can help administrators block unwanted extension installation behavior. It should work alongside endpoint detection rules for unusual Edge launch arguments.

Organizations should also review scheduled tasks that start Edge from non-standard user-data directories. A legitimate browser process running without a visible window can still act as a malware host.

Incident response guidance

If a user clicked a Teams link tied to a fake helpdesk request, responders should treat the endpoint as compromised. The response should include session revocation, credential resets, endpoint isolation, and memory and disk collection.

Teams should also inspect the user’s mailbox, Teams chat logs, browser extension folders, scheduled tasks, AutoHotkey artifacts, Python payloads, local HTTP listeners, and outbound cloud storage connections.

For domain environments, responders should check for lateral movement through SMB, RDP, PsExec, LSASS dumping, pass-the-hash activity, backup server access, and any attempt to copy NTDS.dit or registry hives.

The bottom line

UNC6692 shows how far social engineering can go when attackers combine workplace trust with custom malware. The operation starts with a routine-looking helpdesk interaction but can end with credential theft, lateral movement, and domain controller compromise.

Microsoft Teams should not be treated as a safe channel by default when external communication is enabled. Helpdesk identity verification, strict external access rules, browser extension controls, and endpoint monitoring all matter.

The SNOW malware suite also shows why defenders need to watch for living-off-the-land behavior around legitimate tools. In this campaign, familiar software helped the attacker hide the transition from a fake support chat to deep network access.

FAQ