108 Malicious Chrome Extensions Exfiltrating Browser Data Removed from Web Store

Researchers at Duo Security published analysis of a coordinated campaign involving 108 malicious Chrome extensions collectively installed on an estimated 4.2 million browsers before Google removed them from the Chrome Web Store. The campaign represents one of the larger coordinated extension-based attacks in terms of installation count, and the 18-month longevity of some extensions before detection highlights persistent blind spots in extension marketplace security review.

Campaign Structure and Capabilities

The 108 extensions were not independent creations — researchers identified a shared infrastructure and code lineage suggesting a single threat actor or coordinated group operating what amounts to a browser implant deployment and management network.

Data collection capabilities varied by extension tier:

• Tier 1 (credential stealers): Extensions with access to all-site permissions (<all_urls>) injected content scripts that extracted credentials from login forms before submission — bypassing HTTPS since the extraction occurs at the DOM level, before data is encrypted in transit. Targeted form fields included standard username/password inputs as well as 2FA code fields.

• Tier 2 (session hijackers): Extensions requested cookies permission for specific high-value domains including financial services, corporate SSO providers, and email platforms. Session cookies from these domains were exfiltrated to C2 infrastructure, enabling account takeover without requiring the user’s password.

• Tier 3 (passive collectors): Lower-capability extensions monitored clipboard content (capturing copied passwords, OTP codes, and cryptocurrency wallet addresses) and browsing history.

Extensions across all tiers shared exfiltration infrastructure — C2 domains registered through bulletproof hosting providers, communicating over HTTPS to blend with legitimate browser traffic. The C2 infrastructure rotated domains regularly, with extensions fetching updated endpoint lists from a configuration server.

How the Extensions Evaded Web Store Review

The extensions employed several techniques to pass Chrome Web Store’s automated review process:

Delayed payload activation: Most extensions operated legitimately for 24–72 hours post-installation before activating malicious behaviour — bypassing sandbox analysis that tests extension behaviour at install time.

Remote code injection via configuration: Rather than embedding malicious logic in the initial extension package, extensions fetched JavaScript payloads from remote configuration endpoints after installation. This technique bypasses static analysis of the submitted extension package.

Permission minimisation for stealth: Tier 3 extensions requested only clipboardRead and storage permissions — combinations that appear low-risk but are sufficient for clipboard theft. More capable extensions bundled excessive permissions within packages that had large numbers of positive reviews purchased to establish credibility before switching to malicious functionality.

Impersonation of legitimate tools: Extensions impersonated real, popular tools including well-known ad blockers, VPN clients, password managers, and productivity utilities — exploiting user confusion between similar names and visual designs in search results.

Enterprise Impact

The enterprise implications are significant because Chrome extensions in corporate environments typically run with the same permissions as user-installed software:

• Corporate SSO session cookies — including Microsoft Entra ID, Okta, and Google Workspace tokens — were within scope of Tier 2 extensions for users who were authenticated to these services
• Password manager autofill can be intercepted by malicious extensions with DOM access, circumventing the security benefit of the password manager itself
• Browser-stored credentials (Chrome’s built-in password manager, which synchronises to Google accounts) were directly accessible to extensions with the passwords permission, which several extensions had acquired

The 18-month dwell time for some extensions means enterprise environments should not assume that the absence of current alerts implies clean installation history.

Recommended Actions

Audit enterprise Chrome extension inventory: Cross-reference all installed extensions in managed Chrome deployments against the IOC list published by Duo Security (extension IDs and names). Enterprise environments using Google Workspace with Chrome Management have centralised visibility into installed extensions.

Enforce extension allowlisting: Chrome enterprise policy supports allowlisting (ExtensionInstallAllowlist) and blocking (ExtensionInstallBlocklist). Organisations should enforce a policy permitting only explicitly approved extension IDs and blocking all others — preventing future unreviewed extensions from being installed.

Restrict extension permissions at policy level: Chrome enterprise policy can limit maximum permissions for user-installed extensions. At minimum, the cookies permission for sensitive domains and the passwords permission should be restricted to a verified allowlist.

Review Chrome extension governance: If no formal extension approval process exists, establish one. Every extension installed in an enterprise browser is executable code with access to all browsing context — it should be subject to the same vetting as installed software.

The Chrome Web Store review process — despite Google’s investment in automated scanning — continues to be bypassed by actors with sufficient patience and technical sophistication. Enterprise browser security cannot rely solely on marketplace integrity.