Chrome Web Store bypass for sale: how to protect your extensions from MaaS phishing kits

Someone sold a guaranteed path into the Chrome Web Store for $6,000. The buyers got a working malware toolkit, a note-taking extension with real positive reviews, and a ready-made phishing page that would appear to load from your bank's actual URL. The seller called it Stanley. Varonis found it in January 2026. And the scariest part? It worked exactly as advertised.

How Stanley slipped past Chrome's review

According to Varonis, Stanley is a Russian malware-as-a-service (MaaS) toolkit that appeared on a Russian-language cybercrime forum starting January 12, 2026. The pricing ran from $2,000 to $6,000, with the top-tier "Luxe Plan" explicitly guaranteeing Chrome Web Store placement — meaning the sellers were confident enough in their bypass technique to put it in the sales copy.

The demo extension was "Notely," a note-taking app. It looked legitimate. It had genuine positive reviews. Varonis researchers found that it accumulated real user trust before its malicious payload ever activated. This is the sleight of hand: submit something benign, pass review, then flip a switch server-side.

Once installed, Notely polled a command-and-control server (api.notely.fun) every 10 seconds. When operators decided a target was worth hitting — identified by IP-based geographic filtering — the extension injected a fullscreen iframe overlay onto specific sites like binance.com. According to Varonis, "the browser's URL bar continues to display the legitimate domain (e.g., binance.com), while the victim sees and interacts with the attacker's phishing page." You're on the real website. The extension is painting a fake one on top.

What the MaaS model actually means

The code itself, according to Varonis researchers, had Russian-language comments and rough error handling. The $6,000 price tag doesn't reflect engineering sophistication — it reflects access. Stanley isn't a product you buy once; it's a service. Operators can push Chrome-native browser notifications that appear to come from Chrome itself, rotate backup domains if the primary C2 goes offline, and configure targets remotely without touching the extension code at all.

This matters because it dramatically lowers the barrier. You don't need to write malware. You don't need to understand browser internals. You need $6,000 and a target list. The expertise is centralized in the sellers; the risk is distributed to buyers. That's what makes MaaS kits so structurally dangerous.

Why "only install from the official store" isn't enough anymore

The conventional wisdom has been simple: stick to the Chrome Web Store, avoid sideloaded extensions, and you're safe. Stanley is a direct challenge to that mental model.

SecurityWeek reported on the structural gap here: Google's review process evaluates extension code at submission time. But an extension can behave completely differently post-installation based on server-side configuration. The extension that reviewers approved does nothing harmful. The extension that activates three weeks later — after the C2 receives a targeting update — is a different beast, and the review process has no visibility into it.

Varonis described the toolkit as "a turnkey credential theft solution that bypasses Google's review process." That framing is worth sitting with. It's not that attackers found a bug in Chrome's review pipeline. They worked around its fundamental architecture: you can't review behavior that hasn't happened yet.

There's also the review timeline problem. Extensions can sit in review for days. By the time a malicious extension is flagged after deployment, it may have already harvested credentials from thousands of users. In Stanley's case, Varonis reported the C2 infrastructure went offline on January 22, 2026 — one day after they reported it to Google — and the Notely extension was removed from the Chrome Web Store by January 27. Fast, once someone was looking. But someone had to be looking first.

The iframe overlay technique is worth understanding precisely because it's so counterintuitive. You navigate to binance.com. Your browser connects to binance.com's servers. The URL bar shows binance.com. But the extension, running with permissions you granted at install time, injects a full-page iframe from an attacker-controlled domain on top of the real page. You type your login credentials into a form that looks pixel-perfect. That form submits to a server in Russia. The extension's C2 never needed to intercept your traffic or spoof DNS — it just painted over the window.

How to protect yourself

Audit your extension permissions before you install anything. Before you click "Add to Chrome," look at what permissions the extension requests. A note-taking app that wants access to all sites you visit, the ability to read and change all your data on websites, and storage access is worth a hard look. You can check extension permission details in the Extenshi catalog before installing — it breaks down what each permission actually means in plain language.

Treat permission creep as a red flag. Chrome extensions can request additional permissions after installation, sometimes through legitimate-looking prompts. If an extension you installed months ago suddenly asks for new permissions — especially broad host permissions — that's a signal something changed. It might be a legitimate feature update, or it might be a MaaS operator expanding their toolkit's reach. Either way, it's worth verifying.

Keep your installed extension list short and intentional. Every extension you install is a process running in your browser with access to your browsing session. Most people have forgotten extensions they installed years ago from developers who no longer maintain them. A dormant extension can be acquired by someone with worse intentions than the original developer, then updated with new functionality. Prune anything you don't actively use.

Watch for unexpected fullscreen overlays on financial sites. If you visit a banking, exchange, or payments site and something about the page feels slightly off — loading behavior, font rendering, form fields that seem detached from the rest of the layout — that's worth stopping to investigate. Open DevTools (F12), look at the DOM. An injected iframe won't look like native page content in the element inspector. This sounds like a lot of work but it only takes 30 seconds on sites where the stakes are high.

Use a dedicated browser profile for financial activity. This one is simple and high-leverage. Create a separate Chrome profile with zero extensions installed. Use that profile exclusively for banking, crypto exchanges, and anything involving real money. Extensions can't attack a profile they're not installed in. The Stanley technique depends entirely on an extension being present in the browser session when you visit the target site.

What Google is doing, and what it can't fix

To Google's credit, the response in this case was fast. Varonis reported Stanley to Google on January 21, 2026. The C2 infrastructure went offline the next day, and the Notely extension was removed from the Chrome Web Store within a week. That's a reasonable incident response timeline.

Google has also invested significantly in extension review over the years — mandatory review processes, manifest version requirements, and policy restrictions on certain permission combinations. These aren't trivial efforts. But as SecurityWeek noted, the structural challenge here isn't about catching bad code at submission time. An extension that polls an external server and renders content from it can always behave differently after approval. Google has not publicly commented on whether it's building specific detection for the fullscreen iframe overlay technique that Stanley used. The overlay approach works precisely because it doesn't interfere with the real page's network traffic — it just draws on top of it.

The honest answer is that no review process can fully solve the behavioral gap between submission and runtime. The defense has to be multi-layered: better tooling for users to understand what they've installed, permission transparency, and behavioral monitoring that catches extensions acting outside their stated purpose.

How Extenshi helps

This is exactly the visibility problem Extenshi is built to address. When you scan your extensions in the Extenshi catalog, you get a clear breakdown of every permission each extension holds, what those permissions enable an extension to do, and flags for anything that looks inconsistent with the extension's stated purpose. A note-taking app with full host permissions is exactly the kind of mismatch that shows up in that analysis. You can't always catch a sleeping malicious payload — but you can catch the permissions that would make an attack possible.

Scan your extensions →

---

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].