SNOW Malware’s WebSocket C2 Tunnels: How Browser Extensions Turn Into Covert Channels

Opening position: this is not just another phishing story

State the technical claim up front — Teams lures, WebSocket tunnels, and browser extensions combine into a stealth chain

My read on the reporting is straightforward: the lure is not the interesting part. The real story is the trust chain that starts with a Teams message and ends with a browser that can be used as a relay, a persistence point, or both.

The public reporting on the SNOW malware ecosystem says the operators used Teams phishing, WebSocket tunnels, and browser extensions. I cannot verify every implementation detail from the summary alone, so I am treating the exact chain as report-level information. But the architecture itself is credible and worth paying attention to:

• a chat lure gets the user to open a path into the session
• a browser-side component helps keep access alive
• WebSocket traffic gives the operator a bidirectional channel that is harder to spot than classic polling

That is more than a single phishing success. It is a way to move control into a place defenders often under-monitor: the browser profile.

Explain why the browser layer matters more than the lure itself

Teams phishing gets the click. The browser extension is what can make that click matter later.

If the payload only ran once, defenders might catch it with a password reset, a session revoke, or a machine reimage. If the payload installs or abuses a browser extension, the attacker may keep a foothold in the user’s normal working environment. That matters because browsers already hold:

• authenticated sessions
• SSO tokens and cookies
• access to SaaS admin consoles
• internal apps that trust the browser more than the endpoint

So the browser is not just the delivery vehicle. It is part of the target surface.

What the source reporting actually confirms

Separate reported facts from inference and avoid overclaiming

From the public report, the confirmed claims are narrow:

• the activity is associated with the SNOW malware ecosystem
• the initial lure involved Microsoft Teams phishing
• WebSocket tunnels were used
• browser extensions were part of the chain

What I would not treat as confirmed from the snippet alone:

• the exact malicious extension name
• whether the extension was store-delivered, sideloaded, or pushed through another mechanism
• the precise command set the operator used
• whether every victim followed the same path

That separation matters. When a report mixes lure, channel, and persistence together, it is easy to imagine one clean kill chain. In practice, you often get several variants that share infrastructure and tooling but differ at the endpoint.

Identify the affected surface: Microsoft Teams users, browser sessions, and extension trust

The exposed surface is broader than “Teams users.” It includes:

• users who trust messages from contacts or internal-looking accounts
• browser sessions with active cloud logins
• extension policies that allow broad install paths
• organizations that log SaaS access but not browser-side behavior

If you only monitor the chat client, you miss the handoff into the browser. If you only monitor the browser, you miss the social engineering that created the initial trust. This is a cross-layer problem.

How the intrusion chain likely works end to end

Initial access via Teams phishing or social engineering

The entry point is boring on purpose. A Teams message can make a user believe they are clicking something internal, urgent, or routine. The report says Teams phishing was part of the campaign, which fits a pattern I have seen repeatedly: use an internal collaboration channel to bypass the skepticism that email phishing now triggers.

What likely happens next is not magical. The victim either:

• lands on a malicious page
• signs in through a fake or redirected flow
• installs something that appears to be needed for the task

The hard part for defenders is that the action can look like normal user behavior until you line up identity logs, browser telemetry, and the endpoint timeline.

Why WebSocket C2 is attractive for operators

WebSocket is attractive because it is bidirectional and persistent. After the initial HTTP upgrade, the connection can stay open for a long time and carry small chunks of data back and forth.

For an operator, that means:

• fewer discrete HTTP requests to alert on
• easier stateful command delivery
• a channel that can look like ordinary application traffic
• less dependence on noisy beacon intervals

WebSocket is not invisible. It is just easier to blend into legitimate browser activity than a rigid polling loop.

How a malicious browser extension can become the persistence layer

A browser extension can become the persistence layer because it sits close to the user’s authenticated web session. Depending on permissions, it can observe tabs, read page content, inject scripts, mediate requests, or access cookies and storage.

That does not mean every extension is dangerous. It does mean a malicious one can do useful attacker work without dropping a separate resident service on the host.

The practical consequence is uncomfortable: removing the original phishing page may not be enough. If the extension survives, the browser session may still be compromised.

WebSocket tunnels as a covert command-and-control channel

Connection behavior to look for in browser and proxy logs

If you are hunting this class of activity, start with the shape of the traffic, not the payload.

If your proxy decrypts traffic, you can sometimes see message cadence and path. If it does not, you still get metadata: destination, timing, duration, certificate, and possibly SNI. That is enough to build a hunt, but not enough to prove intent by itself.

Why WebSocket traffic blends in better than classic polling or beaconing

Classic malware beaconing often shows a rigid pattern: every N seconds, a request to the same endpoint, same method, same shape. WebSocket looks more like an application session.

That buys the operator three things:

1. fewer obvious periodic requests
2. easier command delivery without reconnect churn
3. a channel that sits inside ordinary browser behavior

This is why I do not like treating WebSocket C2 as a niche trick. It is a practical way to hide in the traffic pattern of modern web apps.

What defenders can and cannot infer from encrypted WebSocket sessions

You can usually infer:

• which host connected
• when the session started and ended
• how long it stayed open
• how much data moved
• which process or browser profile opened it, if endpoint telemetry is good

You usually cannot infer, from the network alone:

• the command content
• whether the frames were malicious or merely noisy
• whether the browser was acting under user control or extension control

That is why WebSocket hunting works best when you join network telemetry with browser inventory and identity logs.

Malicious browser extensions: the real persistence problem

Permission abuse, token access, and session hijacking risk

Extension risk is mostly about permissions and trust.

A normal enterprise extension usually has a tight purpose: password management, DLP, SSO, productivity, or a business-specific workflow. A suspicious extension often asks for more than it needs:

• broad host access
• cookie access
• tab inspection
• script injection
• request modification
• access to all sites

If a malicious extension can read page context or session state, it may be able to relay authenticated activity without stealing the password itself. That is why extension permissions deserve the same attention as endpoint privilege.

Extension-installed backdoors versus normal enterprise extensions

The difference between legitimate and malicious extensions is not “does it have code?” Everything has code. The difference is whether the code’s behavior matches the business need.

Red flags I look for:

• extension installed shortly after a phishing event
• publisher not tied to the business
• permissions wider than the documented function
• update source outside normal enterprise controls
• odd service worker or background activity when no tab is active

A good extension review is less about branding and more about capability.

Indicators that an extension is acting as a covert relay

Useful indicators include:

• extension ID not on the allowlist
• host permissions spanning unrelated domains
• requests to WebSocket endpoints after login
• extension activity that persists after the original page closes
• logins from a browser profile that suddenly starts talking to rare infrastructure

None of these prove maliciousness alone. Together, they are enough to escalate.

Practical detection checks for defenders

Browser inventory and extension allowlist review

I would start with inventory before signatures.

Questions to answer:

• Which extensions are installed across managed browsers?
• Which ones have broad host permissions?
• Which ones were installed recently?
• Which ones are allowed by policy versus user-installed?

If you can export Chrome profile data from a test machine, this kind of check is practical. For example, on a controlled endpoint you can inspect the browser profile JSON to see what is installed and what permissions it requested.

jq '.extensions.settings
    | to_entries[]
    | {id: .key, name: .value.manifest.name, location: .value.location, permissions: .value.manifest.permissions}' \
  "$HOME/Library/Application Support/Google/Chrome/Default/Preferences"

That path varies by platform and browser, but the idea is the same: compare installed extensions against business need, not against familiarity.

Network detections for unusual WebSocket endpoints, long-lived connections, and odd user agents

Build detections around behavior:

• browser process opening WebSockets to rare hosts
• connections lasting far longer than normal page activity
• repeated upgrade requests from the same profile
• destinations that are new, low-reputation, or unrelated to known SaaS

If your tooling supports it, tag sessions by browser process or user profile. That makes it easier to separate a user opening a real app from an extension quietly relaying commands in the background.

Endpoint and identity checks for suspicious Teams-driven login flows or post-click activity

The kill chain becomes much easier to see when you line up:

• Teams message timing
• first browser navigation after the click
• identity provider login events
• extension install or update events
• first suspicious WebSocket connection

If those timestamps line up within minutes, the case for compromise gets much stronger.

Defensive controls that actually reduce exposure

Harden Teams and adjacent identity workflows against phishing and impersonation

Teams is not the only problem, but it is part of the attack path. Tighten the surrounding identity controls:

• enforce MFA with phishing-resistant methods where possible
• review Teams external access and guest rules
• train users to distrust “quick sign-in” workflows that land outside normal domains
• monitor for new device or browser-session enrollment after chat-based lures

Restrict browser extension installation and monitor privileged permissions

This is the control I would prioritize after identity hardening.

• use enterprise allowlists
• block sideloading where you can
• review high-risk permissions
• alert on new extensions that request cookies, webRequest, scripting, or broad host access

If the browser is a business client, treat extensions like software deployment, not user decoration.

Use proxy, EDR, and SaaS logging together instead of relying on one control

No single log source is enough here.

• proxy logs show destinations and session shape
• EDR shows process and browser association
• SaaS logs show identity and session behavior
• browser inventory shows the extension layer

If one of those is missing, the chain is harder to prove. If all four are present, the story becomes much clearer.

What I would prioritize first if I saw this in a real environment

Remove unknown extensions and validate browser sessions before chasing the network tunnel

If I saw this pattern in production, I would not start with the proxy block list. I would start with the browser.

First step:

1. identify recent or unknown extensions
2. remove anything that is not explicitly approved
3. revoke active sessions for the affected user
4. re-check identity logs for abnormal logins and token use

That is the fastest way to cut off a browser-side relay.

Treat WebSocket C2 as a symptom, not the root cause

The tunnel is the transport. The root issue is trust abuse: a user trusted a Teams message, then trusted the browser, then trusted an extension or session state that should not have been trusted.

If you only block the tunnel, the next variant may use HTTPS polling, DNS, or some other relay. Fix the trust boundary.

Reproducible validation ideas for blue teams

Simulate a benign WebSocket beacon and confirm your logging path

Use a local lab to prove that your sensors actually see WebSocket behavior.

const http = require("http");
const WebSocket = require("ws");

const server = http.createServer();
const wss = new WebSocket.Server({ server });

wss.on("connection", (ws, req) => {
console.log("connection", req.socket.remoteAddress, req.headers["user-agent"] || "-");
ws.on("message", (msg) => console.log("message", msg.toString()));
ws.send(JSON.stringify({ type: "ping", ts: Date.now() }));
});

server.listen(8765, "127.0.0.1", () => {
console.log("listening on ws://127.0.0.1:8765");
});

Run a browser client against it, then confirm your logs capture the connection start, duration, and source process or profile. If you cannot see that in a lab, you will not see it during an incident.

Expected output should look roughly like this:

listening on ws://127.0.0.1:8765
connection 127.0.0.1 Mozilla/5.0 ...
message {"type":"hello","host":"lab"}

Audit extension permissions and compare them against actual business need

Make a small review list:

• extension name
• publisher
• install source
• permissions
• host permissions
• last update time
• business owner

Then ask one question: what does this extension need that a normal page cannot do?

If the answer is “access all sites, cookies, and tabs” and the extension is just a convenience add-on, that is a problem.

Test whether identity logs can link the phishing entry point to the browser activity

Pick one suspected user and line up the timeline:

• message received
• link clicked
• login or token refresh
• extension install or update
• first unusual WebSocket session

If your logs can stitch those together, you are in good shape. If they cannot, you have a visibility gap worth fixing before the next campaign.

Closing assessment

Clear conclusion on risk, likely impact, and what this incident shows about browser trust boundaries

My conclusion is not that Teams phishing suddenly became more sophisticated in some abstract sense. It is that the browser trust boundary is still too soft in many environments.

A phishing lure gets attention. A WebSocket tunnel gives the operator a quiet channel. A malicious extension gives them persistence and access to the user’s authenticated web world. That combination is a real risk, not a theoretical one.

If I were defending this environment, I would prioritize extension control, session revocation, and cross-log correlation over generic “phishing awareness” messaging. Awareness helps at the margin. Browser control and identity logging reduce the blast radius.