Browser extension sideloading attacks: how to detect SNOWBELT before it owns your enterprise

Most people picture malicious browser extensions as things that sneak through Chrome Web Store review — a dodgy productivity tool, a fake AI assistant that somehow passes Google's checks. A sideloaded browser extension skips all of that.

The threat actor UNC6692 takes a completely different approach. According to research by Google GTIG (Mandiant) and BleepingComputer, this group never goes anywhere near the Web Store. They install a browser extension directly into a hidden Microsoft Edge process using a command-line flag that most enterprise security tools never even think to monitor.

The result: a JavaScript-based backdoor running inside your organization's browser, with no store listing, no visible window, and no entry in the kind of extension inventory reports most security teams rely on. And once it's in, the campaign Mandiant documented ends with full domain controller compromise.

How the attack chain starts: Teams impersonation

The initial access is social engineering at scale. Mandiant's researchers describe a pattern of large-scale email bombing — flooding a victim's inbox to create noise and urgency — followed by a Microsoft Teams message from an account impersonating the company's IT helpdesk. The story is predictable: there's a problem with your computer, click this link, download this tool.

The link goes to a phishing page hosted on an attacker-controlled AWS S3 bucket. Hosted on S3 specifically because S3 traffic is trusted by most network inspection tools — it's encrypted, it comes from a reputable cloud provider, and blocking it would break half your legitimate workflows. Once the victim runs the downloaded installer, the interesting part begins.

A scheduled task launches Microsoft Edge in headless mode using the --load-extension flag:

msedge.exe --load-extension="C:\Users\...\SysEvents" --headless=new --disable-sync

A second scheduled task immediately kills any visible Edge windows that might briefly appear. From the user's perspective, nothing happened. In the background, Edge is silently running with a malicious extension loaded — Mandiant calls it SNOWBELT, typically disguised as "MS Heartbeat" or "System Heartbeat" in the extension directory.

What SNOWBELT can actually do

SNOWBELT is not a simple keylogger. Mandiant's analysis documents over 12 command-and-control commands implemented using standard browser extension APIs — the same APIs legitimate extensions use every day:

• Screenshot capture — grab what's on the screen at any moment
• File staging via chrome.downloads — queue files for exfiltration through the browser's own download API
• Native messaging bridge — connect the extension to a Python backdoor (SNOWBASIN) running as a local process, giving attackers host-level execution without needing a separate binary dropper
• WebSocket tunneling — route traffic through SNOWGLAZE, a custom WebSocket tunneler in the attack chain
• Protocol handler abuse — launch other processes or URLs via registered protocol handlers
• Cache deletion — wipe evidence after operations complete

The persistence mechanisms are layered. Service Worker Alarms act as a heartbeat to keep the extension's background service worker alive, and a helper.html page is injected to maintain a live visible tab (an old trick for preventing service worker suspension).

The initial scheduled tasks ensure headless Edge restarts on every reboot. Multiple redundant mechanisms mean killing one doesn't take the extension down.

The C2 infrastructure is designed to look normal. As Mandiant put it: "This 'living off the cloud' strategy allows attackers to blend malicious operations into a high volume of encrypted, reputably sourced traffic, making detection based on domain reputation or IP blocking increasingly ineffective." The group generates AWS S3 bucket URLs using time-based domain generation — rotating every 30 minutes — with AES-GCM encryption keyed from a SHA256 hash of a seed plus the current time slot. Every outbound C2 packet looks like a routine S3 request.

The campaign Mandiant tracked ends at the domain controller. SNOWBELT relays commands to SNOWBASIN, which enables Pass-the-Hash attacks, dumps LSASS credentials, and extracts the full Active Directory database (NTDS.dit) using FTK Imager. From a sideloaded browser extension to complete enterprise credential theft.

Why your current extension monitoring misses this

Standard enterprise extension monitoring checks what's installed through the Chrome Web Store, or inventories extensions through browser management policies (Chrome Enterprise, Intune). Both approaches miss SNOWBELT entirely:

No Web Store presence. There's no listing to check, no extension ID in any store-based inventory. The extension never went through review.

Headless browser, no visible window. There's nothing for a user to notice, no taskbar entry, no obvious browser window. Standard process monitoring might see Edge running, but headless Edge is also used by legitimate automation tools — it doesn't stand out.

Extension loads from a local directory. It bypasses enterprise browser management policies entirely. It won't appear in browser extension policy reports because those reports track policy-installed and user-installed extensions, not --load-extension loads.

C2 blends into cloud traffic. Domain reputation alerts and IP blocklists don't help when every packet goes to S3.

I've written before about how even zero-permission extensions can be weaponized as malware droppers — the threat model for browser extensions is broader than most people assume. SNOWBELT is the enterprise-scale version: an extension running entirely outside the normal review and monitoring infrastructure. And unlike ClickFix-style ownership-transfer supply chain attacks, which still go through the Web Store, sideloading skips that layer of trust completely.

How to detect and respond

If you're running enterprise endpoint or security tooling, here's what to look for:

1. Hunt for headless browser processes with --load-extension

Query running processes across your fleet for any msedge.exe or chrome.exe invocations that include --load-extension or --headless flags together. In normal enterprise use, headless browser invocations loading third-party extension directories are rare enough that any match deserves investigation. Most EDR platforms (CrowdStrike, SentinelOne, Microsoft Defender XDR) can query process command-line arguments at scale — I compared the main enterprise extension audit tools separately. For a quick local check on Windows:

Get-WmiObject Win32_Process |
  Where-Object { $_.CommandLine -like "*--load-extension*" } |
  Select-Object Name, ProcessId, CommandLine

2. Inventory extension directories outside browser profile paths

SNOWBELT loads from a directory like C:\Users\...\SysEvents — outside the normal browser profile extension path. Scan endpoints for directories containing manifest.json files in unusual locations: AppData\Local subdirectories, temp folders, or anywhere that isn't the standard browser profile path. Any manifest found outside the profile tree is worth investigating.

3. Audit scheduled tasks for browser invocations with unusual flags

The attack creates at least two scheduled tasks: one to launch headless Edge with the sideloaded extension, one to kill visible windows. Export and analyze scheduled tasks fleet-wide for anything that invokes a browser executable with --load-extension, --headless, or --disable-sync. A scheduled task launching Edge with those flags is a high-confidence indicator of compromise.

4. Monitor for native messaging pipe creation from browser processes

SNOWBELT uses a native messaging bridge (chrome.runtime.connectNative) to link the extension to SNOWBASIN on the host. Native messaging creates named pipes. Monitoring for new named pipe creation from browser processes — especially headless ones — gives you an additional detection signal that doesn't rely on process command-line visibility.

5. Review Teams external access and helpdesk impersonation risk

The initial access starts with a Teams message. Review your Teams governance settings: external users (or users from different tenants) should not be able to appear indistinguishable from internal IT accounts. Consider sensitivity labels on IT communication channels, alert rules for Teams messages containing download links from accounts outside your tenant, and user awareness training specific to Teams-based social engineering — it's a vector that's distinct from email phishing and often undertrained.

Why sideloaded browser extension attacks are an underappreciated surface

The --load-extension flag exists because developers need to test extensions before publishing. But that same flag has no equivalent production safeguard. Chrome and Edge will load any directory containing a valid manifest.json — no signing requirement, no policy enforcement by default, no user confirmation prompt.

Google has been tightening developer mode restrictions for consumer Chrome, but headless invocations in enterprise environments haven't received equivalent attention. An attacker with enough privilege to create scheduled tasks can launch headless browser processes without modifying any user-facing browser settings. The browser itself becomes a persistence and C2 mechanism that sits between the OS and the network in a way that doesn't match traditional malware patterns.

Mandiant's disclosure confirms that this technique is now in active production use against enterprise targets. UNC6692 has been running this campaign since at least late December 2025, and Mandiant explicitly notes no nation-state attribution has been confirmed — meaning this is a technique available to a range of threat actors, not just a narrow state-sponsored group.

How Extenshi fits in

Extenshi's catalog and security scanning covers extensions distributed through the Chrome Web Store and other public marketplaces. For sideloaded extensions like SNOWBELT that operate entirely outside the store ecosystem, detection has to happen at the endpoint and network level — the steps above are where to focus first.

That said, reducing your overall extension attack surface matters here too. SNOWBELT exploits the legitimacy cover that real browser extension APIs provide — chrome.downloads, chrome.runtime, Service Worker Alarms. If your team is running extensions with broad permissions they don't actively need, those extensions represent potential cover for similar techniques and real risk on their own.

Scan your extensions with Extenshi to see which ones have downloads, nativeMessaging, tabs, or host permissions across your installed set — and prioritize removing anything you're not actively using. Fewer extensions with fewer permissions is a genuine risk reduction, not just hygiene.

Browse the catalog to check the extensions your team already has installed and get security scores before deciding what stays.

FAQ

What is a sideloaded browser extension?

It's an extension loaded straight from a local folder instead of installed from the Chrome Web Store or Edge Add-ons. Chrome and Edge will load any directory containing a valid manifest.json via the --load-extension flag — no signing, no review, no store listing. That's what makes sideloading both a normal developer workflow and an attack vector.

How do attackers sideload an extension into Chrome or Edge?

In the SNOWBELT case, a scheduled task launches msedge.exe --load-extension="..." --headless=new, pointing at a directory the installer dropped on disk. Because it runs headless, there's no visible window — the same --load-extension mechanism developers use to test extensions is just pointed at malicious code instead.

Can a sideloaded extension be made unremovable?

Not truly unremovable, but SNOWBELT layers persistence — Service Worker Alarms, an injected helper tab, and reboot-launched scheduled tasks — so killing one piece doesn't stop it. Removing it for good means deleting the scheduled tasks and the on-disk extension directory, not just closing the browser.

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].