7AI - The Agentic Security Platform - Blog

CRXfiltrate: A Chrome Extension JavaScript Execution Backdoor Past Every Defense Layer

Written by 7AI THREAT RESEARCH TEAM | May 14, 2026 10:45:00 AM

A coordinated browser extension cluster strips page defenses and executes operator-controlled JavaScript inside authenticated sessions. Source-level evidence, mapped infrastructure, and deployable detection signatures.

The starting point was mundane. A 7AI researcher wanted a very specific shade of blue and was about to download a color-dropper extension to sample it. Before installing a new extension into a real browser profile, we looked at the listing, permissions, and public threat-intelligence footprint. One sample, MyColorPick, had no public threat-intelligence record and declared permissions that did not fit a simple color picker. We took it into an isolated test VM. Every page the browser loaded carried an injected JavaScript file labeled redirect_checker.js in Chrome DevTools. The file was not served by the visited site. It was injected by the extension into the page context, reporting visited hostnames, install UUID, extension ID, and country tag to a server our threat intelligence had no priors on.

That packet led to a coordinated browser extension cluster that independent researcher Wladimir Palant publicly documented and named "Phoenix Invicta" in January 2025. Sixteen months later, the cluster is larger, actively maintained, and still operating an undocumented JavaScript execution backdoor that delivers operator-controlled code into authenticated corporate browser sessions. Past every layer of the standard enterprise security stack.

This post is the overview. The full technical analysis, with reverse-engineered payload code, infrastructure mapping, IOCs, Suricata signatures, and YARA rules, is on the CRXfiltrate research page.

What the cluster does

The cluster ships browser extensions to the Chrome Web Store and Microsoft Edge Add-ons under utility-application disguises: color pickers, ad blockers, screen capture tools, font finders, sound boosters. Each extension requests host permission for every URL on the web and uses Chrome's declarativeNetRequest API to strip Content-Security-Policy and X-Frame-Options headers from every page response. The extension's content script then injects a <script> element into the visited page's DOM, which fetches operator-controlled JavaScript from the cluster's C2 endpoint and executes it in the page's own realm.

This is how the cluster bypasses Manifest V3. The platform prohibits extensions from loading and executing JavaScript from a remote source in the extension context. The cluster does not run remote code in the extension context. It strips CSP, injects a script tag into the page, and lets the page execute the operator's JavaScript. Both bypasses target the page context, not the extension context, so the Manifest V3 prohibition does not apply.

The current shipped payload monetizes through search-engine ad fraud: Google, Bing, and Yahoo SERPs are hijacked and overlaid with cloned ads from a Yahoo Search Partner integration. The architecture supports any JavaScript the server chooses to deliver. On a banking page, that JavaScript could read session contents. On an SSO page, it could capture credentials at submission. On an admin console, it could inject UI to capture authentication tokens. The payload is the variable. The architecture is the constant.

What was new in our research

Palant documented 14 cluster extensions and reverse-engineered the core CSP-stripping mechanism. Sixteen months later, our research extends that work in five directions.

First, the cluster is larger and more actively maintained than prior reporting documented. We mapped roughly 60 active and reserved domains, identified a 13-domain config and staging cluster, obtained source-level evidence from three samples, and identified extensions Palant did not catalogue. Across the broader cluster we count 22 confirmed extensions and one lower-confidence ledger-only entry, with 85,000+ documented installs across the catalog as a conservative floor.

Second, we documented the static fingerprint that ties the factory together. The themed fake-header CSP-stripping pattern appears across confirmed cluster extensions. We validated it against a 265-extension corpus and observed zero false positives. The corpus is biased toward adjacent categories, so defenders should re-test locally before treating it as globally exhaustive. As an attribution signal, it is strong.

Third, we obtained the JavaScript execution backdoor at source level. The captured Gen 1 framework posts a base64-encoded JSON body (visited hostname, install UUID, extension ID, country tag) to statsdata[.]online/alk/g2.php, then appends the server response as a <script> element inside the visited page. The paper also documents the rotated backup at secdomcheck[.]online. The demonstrated payload family is ad injection and fake-SERP manipulation. The execution channel is not technically limited to ad fraud.

Fourth, we documented the C2 round-trip mechanism. The cluster's primary C2 endpoint at lottingem[.]com/re.php does two things at once: the request URL carries exfiltrated data (visited domain, full page title, install UUID, extension ID) as query parameters; the response body delivers the payload. The round-trip is a single HTTP transaction. Enterprise proxies that block the response, preventing the ad injection, have already let the request URL through. The data was gone before the block took effect. Blocking the response prevents monetization. It does not prevent surveillance. DNS-tier or pre-connection blocking is required to stop exfiltration.

Fifth, we obtained and reverse-engineered the live production payload. The first-generation redirect_checker.js has been replaced. m3011.js, currently served from fivestat[.]com, is a complete rewrite: a Webpack-bundled, single-line production build, 111-135 KB depending on version, with module exports, comprehensive error handling, and no dead code. It supports Google, Bing, and Yahoo natively. It uses computed CSS cloning, reading styles off the live SERP at runtime and applying them to injected ads, so the injected ads are visually indistinguishable from native results and adapt automatically when Google or Bing change their styling. It uses infected browsers as a distributed reconnaissance network: when an unknown ad placement is encountered, the surrounding DOM is exfiltrated to a logb.php endpoint so the cluster can update the payload to handle new SERP layouts. It is delivered from versioned release directories. Source-code comments reference internal project-tracker tickets numbered above 390. This is software product engineering, not a fire-and-forget malware drop.

One captured payload variant contains an active function that scrapes the signed-in Google user's real name and email address from the Chrome sign-out element and exfiltrates the data to doublestat[.]info. We also observed a variant where this block was removed, so identity harvesting should be treated as variant-gated rather than universally present. When this variant is served, the captured identity links to detailed browsing activity indexed by a persistent install UUID.

The detection gap

Across the customer environments we hunted, the security stack saw essentially nothing.

EDR platforms with behavioral and ML detection raised no analyst-visible alerts on infected endpoints. The raw EDR sensor layer contained a SuspiciousDnsRequest event for ahacdn[.]me that the detection pipeline never promoted to a visible alert. A SOC analyst running the standard workflow would never see it. The signal was there. The pipeline was the failure.

SSL inspection proxies and cloud web gateways saw browser-originated requests to recently registered or low-reputation domains, often without the extension context that would make those requests meaningful. Where shared CDN and ad-tech infrastructure sat alongside actor-specific subdomains and paths, categorization databases were structurally unable to separate them. DNS protection, where deployed, can stop confirmed actor-controlled domains before the URL-parameter exfiltration request completes, but cannot safely generalize from shared CDN apexes.

This is structural, not a tuning issue. The malicious activity occurs entirely inside the browser's JavaScript execution environment. No file is dropped. No process is spawned outside the browser. No registry key is created. The network activity originates from a normal Chrome process making normal-looking HTTPS requests to domains the categorization databases have not seen. EDR is architected for process behavior, file changes, and network anomalies at the host level. A browser-internal injection that uses the browser's own network stack is invisible to that telemetry model.

A related, separately-operated finding

During the hunt, "Color Picker ยท Eyedropper" (extension ID gogbiohkminacikoppmljeolgccpmlop, about 400,000 users) surfaced as installed alongside cluster extensions on infected endpoints. Subsequent analysis confirmed it is operated by a separate threat actor and is not part of the cluster Palant named. Prior public reporting attributes it to a separate malicious operation. It uses different infrastructure (Cloudflare, not HZ-Hosting Bulgaria), a different technique (AES-GCM with a hardcoded key, not this cluster's base64 JSON pattern), and shares no code, no domains, and no infrastructure with this cluster. The relationship is co-installation, not common control. For defenders the important point is attribution hygiene: this extension is independently malicious and worth tracking, but it belongs in a separate bucket from this cluster's IOC set.

What defenders should do right now

Inventory browser extensions across the fleet. Use Chrome and Edge enterprise policy controls to restrict extension installation to an approved list. Apply the full 23-ID cluster reference set in the IOC explorer, treating the single ledger-only entry as lower-confidence and requiring surrounding context before action. Any extension requesting <all_urls> host permission warrants explicit review against its stated functionality. Any extension requesting nativeMessaging alongside <all_urls> should be treated as high risk by default.

Run the IOC sweep, do not skip it on a clean extension audit. The cluster also reaches victims through third-party tracker chains on legitimate websites, with no extension installed on the host. A clean extension inventory does not rule out exposure. Query DNS logs (14-day lookback) and network connection logs (7-day lookback) against the IOC list. The highest-signal CDN-path indicator from the research is requests to cdn23602612[.]ahacdn[.]me/500b-bench.jpg, a 500-byte JPEG the production payload uses as a connectivity check, especially when paired with a cataloged extension ID or actor-owned Host/SNI value.

Treat browser-context attacks as a distinct detection problem. The detection gap exposed by this campaign is structural. Closing it requires acknowledging that the standard EDR plus SSL proxy plus DNS stack is not architected to detect browser-internal attacks. Adding browser-resident security telemetry, infrastructure-level visibility into browser-originated network calls, or extension-aware threat hunting capability are paths forward. None of them is standard equipment.

Disclosure

We coordinated disclosure with Google's Chrome Web Store security team ahead of publication. At paper validation, three confirmed cluster extensions remained installable: Easy Dark Mode on the Chrome Web Store as an unlisted but live listing, and two Microsoft Edge Add-ons listings (1-Click Color Picker: Instant Eyedropper and AdBlock for Youtube: SkipAds). Removal of a listing from a store does not retroactively uninstall the extension from endpoints where it is already installed. The full IOC packet, Suricata signatures, YARA rules, and detection guidance in the deep-dive remain operationally valid for hunting regardless of store status.

How 7AI surfaced this

The investigation did not start in a customer environment. It started with a researcher wanting a specific shade of blue and reviewing a color-picker extension before trusting it in a real browser profile. Once we had the scoped IOC set, the hunt phase began. The 7AI Threat Research team built the full IOC sweep into our agentic platform, and PLAID ELITE ran targeted hunts across customer environments in scope, querying browser-extension inventory, DNS, proxy, and network telemetry. Where the hunt surfaced exposure, the customer's AI Security Engineer moved directly into triage and response, with supporting context already assembled by the platform. Customers did not have to wait for publication.

Read the full analysis

This post is the overview. The full technical analysis, including the four-component extension architecture, the C2 round-trip mechanism, the production payload reverse-engineering, the Yahoo Search Partner revenue rotation, the identity harvester, the full IOC tables with Suricata signatures and YARA rules, and the complete action checklist, is on the CRXfiltrate research page.

For questions about this research or to run this hunt against your own environment, contact security@7ai.com. To learn how 7AI's AI SOC agents detect browser-context threats and other attacks that bypass traditional defenses, visit 7ai.com.

This research was conducted by the 7AI Threat Research Team, with field validation through PLAID ELITE proactive hunting. Individual researcher names are withheld for operational-safety reasons. We extend public credit to Wladimir Palant, whose January 2025 analysis named the cluster and reverse-engineered the core mechanism the hunt was built on.