Seventy-Seven Percent of Targets Were Executives
Between March and April 2026, Google's Mandiant team tracked a campaign by UNC6692 where more than three-quarters of observed targets were senior employees — CFOs, IT directors, people with elevated access to domain infrastructure. The group wasn't spraying phishing links at the entire organization. They were selecting individuals whose credentials would give them the shortest path to a domain controller, then engineering a scenario where those individuals would voluntarily install malware and hand over their passwords.
The attack starts with an inbox flooded by thousands of spam emails within minutes. While the target is overwhelmed, a Microsoft Teams message arrives from what appears to be IT helpdesk staff offering to fix the problem. The victim clicks a link to a "Mailbox Repair and Sync Utility." Within hours, UNC6692 has a browser extension running in a headless Edge instance, a WebSocket tunnel to a Heroku C2, a local HTTP backdoor, and is scanning internal ports. Within a day or two, they've extracted the NTDS.dit file, SAM, SYSTEM, and SECURITY registry hives from the domain controller. Game over.
Mandiant published their full technical breakdown on April 23, 2026. Microsoft followed five days earlier with their own advisory on cross-tenant Teams impersonation. This article focuses on the detection opportunities across each stage of the kill chain, because UNC6692's tradecraft is built to exploit gaps between collaboration platform security, endpoint detection, and identity monitoring.
Track Threat Intelligence like this every Monday.
Every Monday, the 5 threats SOC teams can't afford to miss — with analyst commentary.
The Trust Asymmetry That Makes Teams Work as an Attack Vector
Email security has had decades of hardening. SPF, DKIM, DMARC, sandboxing, URL detonation. Most organizations have layered defenses on inbound email that make raw phishing harder every year. Microsoft Teams occupies a different psychological and technical space. Users treat it as internal communication. When a message arrives from "IT Support" in Teams, the instinct is trust — even when the sender is from an external tenant.
Teams does display external user labels. It shows Accept/Block prompts. It has phishing indicators on cross-tenant messages. But UNC6692's approach is designed to make the victim override every one of those warnings voluntarily. The email bombing creates genuine distress and urgency. The Teams message offers a solution to a real problem the target is experiencing right now. The phishing page is named "Mailbox Repair and Sync Utility v2.1.5" and has a professional layout with a "Configuration Management Panel." It rejects the first two password entries to simulate real authentication validation — a detail that simultaneously captures the password twice to eliminate typos and reinforces the page's legitimacy.
Microsoft shipped the Tenant Allow/Block List integration for Teams in February 2026, letting security teams block external users and domains from the Defender portal. That's a meaningful control. But it's reactive — you need to know which domains to block. UNC6692 hosted their phishing infrastructure on AWS S3 buckets (service-page-25144-30466-outlook.s3.us-west-2.amazonaws.com) and used disposable tenant accounts. Blocking one domain doesn't prevent the next operation.
The more effective control is restricting external Teams communication at the organizational level. If your business doesn't require employees to accept Teams messages from arbitrary external tenants, disable it. If you need external collaboration with specific partners, allow-list those domains and block everything else. This single configuration change eliminates UNC6692's entire initial access path (T1566.002).
SNOWBELT: Browser Extension Persistence That Bypasses EDR
Once the victim clicks the phishing link, the landing page enforces Microsoft Edge as the browser (redirecting via the microsoft-edge: URI scheme if the user opens it in anything else), then delivers an AutoHotKey binary alongside a script from the attacker-controlled S3 bucket. AutoHotKey's behavior is worth noting: if a binary is named identically to a script file in the same directory, it auto-executes the script without command-line arguments. That's a feature, not a vulnerability, but it means there's no suspicious command-line to detect.
The AutoHotKey script installs SNOWBELT, a malicious Chromium browser extension masquerading as "MS Heartbeat" or "System Heartbeat." It's never distributed through the Chrome Web Store. Instead, it's side-loaded into a headless Microsoft Edge instance via the --load-extension and --headless=new flags, with a custom --user-data-dir pointing to %LOCALAPPDATA%\Microsoft\Edge\System Data.
Persistence is layered. A Windows Startup folder shortcut runs an AutoHotKey script on login that checks whether the headless Edge process is running and restarts it if not. Two scheduled tasks are created: one to launch Edge headless with SNOWBELT loaded, and another that kills Edge processes missing CoreUIComponents.dll (headless instances don't load this DLL, so this cleanup task removes orphaned headless processes from previous sessions).
This is a detection-rich environment if you know what to look for. Three signals stand out.
First, msedge.exe launched with --headless=new and --load-extension flags is abnormal in virtually every enterprise environment. This maps to Sigma rule proc_creation_win_browsers_chromium_headless_exec. In Sysmon, look for Event ID 1 (Process Create) where CommandLine contains both --headless and --load-extension. In Microsoft Defender for Endpoint (MDE), the equivalent KQL:
DeviceProcessEvents
| where FileName == "msedge.exe"
| where ProcessCommandLine has_all ("--headless", "--load-extension")
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessFileNameSecond, the scheduled task creation is visible in Event ID 4698 (Security log) or Sysmon Event ID 1 when schtasks.exe is called. The task arguments reference the Extension Data path under %LOCALAPPDATA%\Microsoft\Edge\. Legitimate enterprise extension deployments use Group Policy or the ExtensionInstallForcelist registry key, not scheduled tasks pointing to local Extension Data directories.
Third, the cleanup task that kills Edge processes without CoreUIComponents.dll is itself suspicious. The scheduled task runs cmd /c with a chained tasklist /M SHELL32.dll, findstr, and taskkill pipeline — a string pattern distinctive enough for behavioral detection:
cmd /c "for /f "tokens=2" %p in ('tasklist /M SHELL32.dll ^| findstr "msedge.exe"') do @(tasklist /M CoreUIComponents.dll | findstr "%p" >nul || taskkill /F /PID %p)"Any scheduled task containing CoreUIComponents.dll and taskkill in its arguments should be flagged immediately.
SNOWGLAZE and SNOWBASIN: The Tunnel and Backdoor
Once SNOWBELT is established, UNC6692 downloads SNOWGLAZE, SNOWBASIN, and a portable Python distribution through the browser extension.
SNOWGLAZE is a Python-based tunneler that creates an authenticated WebSocket connection to the attacker's C2 — in observed cases, a Heroku subdomain. It wraps data in JSON objects, Base64-encodes it, and sends it over WebSockets, making traffic look like standard HTTPS communication to a cloud service. It supports SOCKS proxy operations, allowing arbitrary TCP traffic to route through the compromised host. This is the component that bridges the attacker's external infrastructure to the internal network.
SNOWBASIN is a Python-based bindshell that listens as a local HTTP server on port 8000. It accepts commands via HTTP POST, executes them through cmd.exe or powershell.exe, captures screenshots, and stages data for exfiltration. The command flow is SNOWBELT (browser extension) → SNOWGLAZE (WebSocket tunnel) → SNOWBASIN (local HTTP backdoor). Each component has a distinct role, and together they form a pipeline where the browser extension acts as the relay, the tunneler handles C2 transport, and the backdoor provides interactive access.
Detection for SNOWGLAZE focuses on outbound WebSocket connections from Python processes. In environments where Python isn't a standard part of the desktop build — which is most corporate endpoints — any Python process making outbound HTTPS connections is worth investigating. In MDE:
DeviceNetworkEvents
| where InitiatingProcessFileName in ("python.exe", "python3.exe", "pythonw.exe")
| where RemotePort in (443, 8443)
| where RemoteUrl has_any ("herokuapp.com", "s3.us-west-2.amazonaws.com")
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessCommandLineBroaden this beyond the specific UNC6692 infrastructure. Any Python process on a non-developer workstation making sustained outbound connections to cloud hosting platforms is anomalous.
For SNOWBASIN, the indicator is a Python process listening on a local TCP port. This is trivially detectable with network monitoring or endpoint telemetry:
DeviceNetworkEvents
| where InitiatingProcessFileName in ("python.exe", "python3.exe")
| where ActionType == "ListeningConnectionCreated"
| where LocalPort == 8000From Foothold to Domain Compromise: The Last-Mile Detection Window
UNC6692's post-access tradecraft follows a familiar pattern, but each stage offers detection opportunities that defenders should have in place regardless of the initial access method.
After establishing access, UNC6692 runs a Python script scanning for ports 135 (RPC), 445 (SMB), and 3389 (RDP) across the local subnet. Internal port scanning from a workstation — especially via Python — is a strong signal. Then they use PsExec to establish sessions through the SNOWGLAZE tunnel and enumerate local administrator accounts (T1087.001). PsExec execution from a non-admin-tools host is a well-understood detection, but many organizations still don't alert on it.
The privilege escalation step is notable. UNC6692 uses Windows Task Manager to dump LSASS process memory from a backup server (T1003.001), then exfiltrates the dump via LimeWire. Extracting credentials offline, outside the victim environment, avoids triggering Credential Guard alerts or EDR rules that fire on tools like Mimikatz running in-process. The detection opportunity here is the LSASS access itself. In MDE, DeviceProcessEvents where FileName == "Taskmgr.exe" accessing lsass.exe should generate a high-severity alert. Sysmon Event ID 10 (ProcessAccess) with TargetImage matching lsass.exe and SourceImage matching Taskmgr.exe is the equivalent.
Once armed with NTLM hashes, UNC6692 performs Pass-the-Hash (T1550.002) to authenticate to domain controllers. On the DC, they download FTK Imager — a legitimate forensic tool — mount the local drive, and extract NTDS.dit along with the SAM, SYSTEM, and SECURITY registry hives. They exfiltrate everything through LimeWire.
Two things stand out about this final stage. First, FTK Imager being downloaded to a domain controller's \Downloads folder via Edge is not something that should ever happen without a DFIR team's planned activity. Browser process execution on a DC, especially downloading executables, should be a critical alert. Second, the use of LimeWire for exfiltration is unusual — most operators use Rclone, Mega, or cloud sync tools. If your egress controls or DLP don't have coverage for LimeWire traffic, add it.
What Makes UNC6692 Operationally Different
Several aspects of this campaign deserve attention beyond the specific IOCs.
The email bombing is not a distraction tactic in isolation. It creates the psychological conditions where the victim actively wants help, making the Teams impersonation far more effective than a cold approach would be. The two techniques are designed to work together — the bombing creates the problem, the Teams message offers the solution. Defenders need to correlate these events: a sudden spike in inbound email volume for a specific user, followed by an external Teams message within a short window, is a signature pattern. Microsoft Defender for Office 365 can surface the email bombing. Defender for Cloud Apps can log the Teams interaction. The correlation between them needs to be built manually in most environments.
The browser extension as a C2 relay is another evolution worth tracking. Browser extensions persist across reboots through the browser's own extension management. They run in the browser's process context, inheriting its network permissions and TLS certificates. URL reputation services see traffic going to Heroku or S3 — both legitimate cloud platforms that can't be blanket-blocked. The extension doesn't appear in the task manager as a separate process. It's inside msedge.exe. Unless you're inventorying extensions at the endpoint level and comparing against a known-good allow list, SNOWBELT is invisible.
Organizations using Microsoft Edge should enforce extension allow-listing via Group Policy (ExtensionInstallAllowlist and ExtensionInstallBlocklist) and block side-loading from local directories entirely (ExtensionInstallSources). Chrome equivalents exist for the same registry keys. Any extension not distributed through the Web Store and not on the organization's approved list should be blocked by policy, not by hope.
The Detection Stack This Attack Exposes
UNC6692's kill chain crosses at least four distinct detection domains: email security (the spam bombing), collaboration platform security (the Teams impersonation), endpoint detection (the extension, Python processes, LSASS access), and identity monitoring (PtH against the DC). Most organizations have tooling in each area. Few have correlation across all four.
The teams that will catch UNC6692 early are the ones monitoring for headless browser execution with extension flags, Python processes on non-developer endpoints establishing outbound WebSocket connections, and external Teams messages arriving within 30 minutes of abnormal inbound email volume spikes. Each signal alone might be a low-confidence indicator. Together, they're a kill chain in progress.
Microsoft's April 18 advisory stated it clearly: the attacker does not exploit a software vulnerability at any stage. Every technique uses either a built-in Windows tool or a legitimate application. The detection challenge isn't identifying malicious binaries — it's identifying malicious sequences of legitimate actions. That's a fundamentally different problem, and it's one that signature-based detection alone will never solve.
