A popular Chrome add-on, “QuickLens – Search Screen with Google Lens,” has quietly morphed from a legitimate productivity tool into a full‑fledged remote code-execution platform that abuses browser trust, security headers, and silent auto‑updates.
What began as a simple Google Lens wrapper ended in a covert C2‑driven campaign capable of injecting arbitrary scripts into any site a victim visits.
Its early versions used a straightforward background service worker for window and capture management and a content script for UI overlays, with network calls limited to Google domains and no obfuscation or suspicious logic.
The extension’s wide but understandable permissions (activeTab, scripting, screen capture‑related access, and a content script injected on all pages) appeared normal for its functionality.
QuickLens originally provided on‑screen Google Lens search with features like screen capture, area selection, YouTube frame lookup, and Amazon product discovery, eventually reaching around 7,000 users and even earning a Featured badge in the Chrome Web Store.
The original developer identity, backed by multiple legitimate extensions, gave little indication that anything was wrong until ownership quietly changed and a monetized codebase turned into an attack platform overnight.
Ownership Change and Malicious 5.8 Release
Just days after launch, QuickLens was listed for sale on ExtensionHub, a marketplace where developers sell extensions complete with users and reviews, a pattern now common in extension‑based supply chain attacks.
On February 1, 2026, control shifted to “LLC Quick Lens” under [email protected], with a new privacy policy on an almost non‑functional domain, signaling a likely throwaway entity.
On February 17, 2026, version 5.8 landed with a very different intent, adding declarativeNetRequestWithHostAccess and webRequest permissions, a new rules.json file, and a C2‑aware background.js that had never existed in the benign 5.7 build.
Google has since removed the extension from the store for a generic “policy violation,” but the underlying changes show a deliberate effort to bypass browser defenses and monetize access to users’ browsing sessions.
The newly introduced rules.json leverages Chrome’s declarativeNetRequest API to modify HTTP responses and remove key security headers from every page, frame, and XHR request.
The rule set strips Content-Security-Policy, CSP‑Report‑Only, X-Frame-Options, legacy CSP headers, and X-XSS-Protection, effectively eliminating browser‑enforced protections against inline script execution, clickjacking, and some reflected XSS defenses.
By globally clearing CSP, the attackers ensure that their later inline onload‑based payloads can execute even on well‑hardened sites that would normally block such constructs.
Combined with a content script injected everywhere, this gives the extension freedom to make cross‑origin requests and interact with page content in ways the original site owners never intended.
Pixel‑Based Script Injection
The updated background script introduces a C2 client talking to api.extensionanalyticspro.top, where the extension registers a persistent UUID, fingerprints the country via Cloudflare’s 1.1.1.1 trace endpoint, collects browser/OS data, and periodically polls /extensions/callback for instructions.
The developer, “[email protected]”, even has many other extensions published in his name (including a new, similar, recently published ‘Google Lens.
The server returns an array of JavaScript strings stored as cached-agents-data in local storage, with webRequest handlers monitoring a /finish endpoint to trigger on‑demand refreshes when the operator wants immediate changes.
Execution happens inside content.js using a clever pixel trick: for each payload string, the extension creates a hidden 1×1 GIF <img> element and assigns the C2‑provided JavaScript to the onload attribute before programmatically firing the load event.
When the image “loads,” the inline onload handler executes in the page context, allowing arbitrary script execution that can read session data, capture form inputs, scrape page content, and exfiltrate via the browser context itself.
For defenders, this highlights the need to treat browser extensions as part of the enterprise supply chain: monitor ownership changes, flag newly added network and declarativeNetRequest permissions, and use runtime behavior analysis to detect covert script injection patterns.
The QuickLens incident shows how a highly rated, Featured extension can become a browser‑resident C2 client with one update, turning 7,000 legitimate installs into an attack surface without any new downloads.
Because the actual malicious code is delivered at runtime from the C2 and never resides in the packaged source, static store reviews and basic permission monitoring are unlikely to see more than “image element helpers” and telemetry‑sounding names like extensionanalyticspro and safelyProcessElement.
Indicators of Compromise
| Type | Value |
|---|---|
| Extension ID | kdenlnncndfnhkognokgfpabgkgehodd |
| Extension Name | QuickLens – Search Screen with Google Lens |
| C2 Domain | api.extensionanalyticspro[.]top |
| Developer Email | support@doodlebuggle[.]top |
| Privacy Policy | kowqlak[.]lat |
| Malicious Version | 5.8 |
| SHA256 | fa3d0c8c8e9f3dacaa9f34e42ad63dceeba16689e055b90e9a903fa274d35df0 |
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
