Browser Extensions With a Shared C2 on Your Pages

Most client-side security assumes the threat arrives through your page: a compromised dependency, an injected script, a tag somebody added. This one arrives through the visitor.

The hosts we track here belong to a command-and-control cluster shared by a large family of malicious browser extensions. The extensions do the usual things — exfiltrate data, steal sessions — and they do it on whatever site the visitor happens to be on. Which is to say, on yours.

Why you see it at all

An extension with permission to run on a page can inject script into it. When it does, some of the requests that follow are attributed to your document, and your Content Security Policy sees them like anything else the page did.

That gives you a view of something you otherwise have no visibility into at all — but a partial one. An extension that does its network work from a background context rather than the page is not covered, so the absence of these hosts in your reports is not evidence that no visitor is affected.

What it means when you do see it

Almost certainly not that your site is compromised. The likely explanation is one visitor with a hostile extension, and your pages can be entirely clean.

That does not make it uninteresting. An extension with access to your pages can read what the visitor reads, including everything behind their login, and session theft is explicitly what this family does. For anyone running an account area, that is a session on your service being taken from a device you have no control over, which will look like a legitimate login when it is used.

One cluster, many extensions

The striking thing about this campaign is the concentration. Dozens of separately published extensions, presenting as unrelated tools, all reporting to subdomains of one registered domain: an API endpoint, a CDN, a chat endpoint, several themed like games and mining utilities.

That structure is a defender's advantage. The operator publishes many small plausible extensions because individually they attract less attention than one ambitious one, and the shared backend that makes that cheap is also the thing that ties them together. Recognising the C2 identifies the whole family, including the extensions nobody has looked at yet.

What to look for

An unfamiliar host in your reports that correlates with no change on your side is the shape of this. Your files are identical, your dependencies are unchanged, and yet a page is talking to somewhere new — that pattern points away from your own supply chain and towards the visitor's browser.

Volume is a useful signal too. Page-level compromises affect every visitor to that page, so the reports arrive in bulk. Extension traffic arrives from the fraction of visitors who installed something, so it looks like a handful of reports against a very small number of sessions.

For an authenticated area, treat this as a session-integrity question rather than a page-integrity one. The page was fine; the browser it was rendered in was not.

The hosts we're tracking for this campaign

These are the entries in our threat intelligence feed for this campaign, shown exactly as we match them. An entry starting *. covers that domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do that when the attacker registered the domain themselves.

The feed changes as we go. We add hosts when they show up and pull them out when the evidence no longer holds, so this is what we're matching today rather than a permanent record.

Frequently asked questions