When "Productivity Tools" Become Attack Vectors

The Night the Extensions Turned

On December 24, 2024, Christmas Eve, an attacker phished an employee at the data security company Cyberhaven. The email posed as a Chrome Web Store policy warning. It led to a real Google consent screen for a malicious OAuth app called "Privacy Policy Extension," which asked for permission to publish Chrome Web Store extensions.

The employee approved it. According to BleepingComputer's reconstruction, Cyberhaven said the employee's Google credentials were never stolen and no MFA prompt appeared. The attacker didn't need a password. The OAuth grant itself gave publishing rights.

The attacker used that access to publish a malicious version of Cyberhaven's browser extension (version 24.10.4). Chrome pushed it automatically to the extension's users, reported at about 400,000. The injected code sent data to a command-and-control server at cyberhavenext[.]pro.

Per Cyberhaven's timeline as reported by Security Affairs, the bad version went live at 1:32 AM UTC on December 25. Cyberhaven's security team detected it at 11:54 PM UTC that day and removed it within 60 minutes. Browsers that auto-updated during that window of roughly a day were affected.

Cyberhaven was the first reported victim, not the only one.

Researchers soon found the same campaign had hit at least 35 Chrome extensions used by roughly 2.6 million people, according to BleepingComputer. Some of the attacker's command-and-control subdomains dated back to March 2024. Most attack domains were registered in November and December 2024.

This wasn't a single breach. It was a supply chain attack on the browser itself.

The Extension Acquisition Attack Model

The Chrome extension supply chain problem covers two distinct attack models. The second is arguably more insidious than the phishing campaign that made headlines.

Model 1: Developer Account Compromise

This is what hit Cyberhaven. The attack chain is short:

1. The attacker sends a phishing email that appears to come from Chrome Web Store developer support.
2. The email warns that the extension violates Chrome Web Store policy and will be removed.
3. The link leads to a real Google OAuth consent screen for a malicious app that requests permission to manage the developer's Chrome Web Store extensions.
4. The developer grants access, which gives the attacker the ability to publish updates.
5. The attacker pushes a malicious update, and Chrome distributes it to every user who has the extension installed.

The leverage is in step 5. Chrome extensions update automatically by default. Users don't see a notification and don't approve the update. One malicious OAuth grant can mean silent access to every browser running the extension.

Model 2: Extension Acquisition and Weaponization

This model is slower but can be just as damaging. Public cases go back to at least 2020.

The playbook works like this:

1. An individual developer builds a useful, legitimate Chrome extension, such as a tab manager, an ad blocker or a screenshot tool.
2. The extension grows to tens or hundreds of thousands of users.
3. A buyer approaches the developer with an offer to purchase it.
4. The developer, often a solo hobbyist, accepts.
5. The new owner pushes an update that adds tracking code, ad injection or data harvesting.
6. Users who installed a legitimate tool now run spyware in their browsers.

Two well-documented cases are described below. In each, users got no notice that the extension had changed hands.

The Permission Model Problem

To see why extension compromises are so damaging, you need to understand Chrome's extension permission model. It was not designed for enterprise security.

When you install a Chrome extension, it requests permissions. These can include:

Permission	What It Actually Means
"Read and change all your data on all websites"	The extension can see everything you do in your browser: every page, every form, every password you type
"Manage your downloads"	The extension can manage files downloaded through the browser
"Read your browsing history"	A record of the sites you've visited
"Manage your apps, extensions, and themes"	Can disable or manage other extensions
"Communicate with cooperating native applications"	Can interact with software outside the browser
"Read data you copy and paste"	Can read your clipboard, including copied passwords and sensitive data

The problem is structural. Many permissions are all-or-nothing. A grammar checker that legitimately needs to modify web pages requests the same "Read and change all your data on all websites" permission that malware uses to steal credentials. You can't grant a writing assistant access to edit text on a page without also giving it the technical ability to read your banking session.

The Session Token Goldmine

Modern web applications keep you signed in with session cookies and OAuth tokens stored in the browser. Extensions with broad permissions can reach these. They are often more valuable than passwords, because the session has already passed multi-factor authentication.

The code injected in this campaign went after Facebook business accounts. BleepingComputer's analysis found it collected Facebook IDs, access tokens, account information, ad account details and business accounts. It also watched for QR codes tied to Facebook's 2FA or CAPTCHA prompts, apparently to get past them.

With a stolen session or access token, an attacker can:

• Access the account without knowing the password
• Skip MFA, because the token represents a session that already passed it
• Keep access after the user changes their password, until the token expires or is revoked
• Act from what looks like the user's own session, which makes detection hard

The likely payoff is ad fraud: running ads through a victim's business account and spending its budget. No reliable public figure exists for the total financial impact of this campaign.

Real Compromises: What Actually Happened

Here are documented cases from both attack models.

The Great Suspender (acquisition model)

The Great Suspender was a popular tool for suspending unused tabs to save memory. Its original developer sold it in June 2020 to an unidentified buyer. Later versions made remote calls and loaded a remote analytics script. Microsoft Edge blocked it first. Google removed it from the Chrome Web Store in February 2021 and disabled it in users' browsers, flagging it as malware.

Nano Adblocker and Nano Defender (acquisition model)

The developer of these two ad blockers, with about 300,000 installs between them, sold the Chrome versions in October 2020. uBlock Origin creator Raymond Hill then found that new updates added malicious code. Infected browsers were liking large numbers of Instagram posts without user input, and the code could collect browsing data. Google removed both from the Chrome Web Store that month, as reported at the time.

The Cyberhaven Extension (account compromise model)

Compromised through a malicious OAuth grant on December 24, 2024. The malicious version 24.10.4 targeted Facebook business and advertising account data. It was live for roughly a day before Cyberhaven detected and removed it. Cyberhaven told customers to update to 24.10.5 or later and rotate credentials.

The Rest of the 2024 Campaign

The same phishing technique compromised at least 35 extensions. Reported victims included productivity tools, VPN extensions and AI assistant extensions. Many had modest user counts: small enough to escape scrutiny, large enough to be worth hijacking.

The Scale of the Problem

There is little reliable public data on how many installed extensions are risky. Most enterprises can't answer a simpler question: which extensions are installed on our devices right now?

The arithmetic is still uncomfortable. Take an illustrative company of 1,000 employees with ten extensions each. That is 10,000 extension installations, from hundreds of different publishers, each able to update silently. If even a small fraction of those publishers is ever phished or sells out, the chance of a compromised extension somewhere in the fleet is high.

Enterprise Browser Extension Governance Playbook

Based on these attack patterns, here is a practical framework for managing browser extension risk. The timings are my recommended pace, not a standard.

Phase 1: Visibility (Week 1-2)

You can't secure what you can't see. Start by understanding your current extension landscape.

Actions:

• Use browser management (Chrome Enterprise, Microsoft Edge management, or a third-party tool such as Nudge Security) to inventory all installed extensions
• Catalog each extension by name, publisher, permissions requested, install count, last update date and risk classification
• Identify extensions installed by more than 10 employees, since these have the highest impact if compromised
• Flag any extension that hasn't been updated in more than 12 months, because abandoned extensions are acquisition targets

Phase 2: Policy (Week 3-4)

Set clear rules for what's allowed.

Extension Classification Tiers:

Tier	Definition	Examples	Policy
Approved	Vetted by security team, from known publishers, limited permissions	Enterprise password manager, enterprise writing assistant, video conferencing	Allowed, auto-installed if needed
Permitted	Not formally vetted but from reputable publishers, acceptable permissions	Specific developer tools, accessibility extensions	Allowed with monitoring
Restricted	Broad permissions, unknown publishers, or unnecessary for business	Social media tools, coupon finders, personal utilities	Blocked on managed devices
Prohibited	Known malicious, abandoned, or broad permissions with no business justification	Free VPN extensions, screenshot tools requesting all-site access	Blocked and removed

Phase 3: Enforcement (Month 2)

Put technical controls behind the policy.

Actions:

• Configure Chrome Enterprise policies to allow approved extensions and block all others, using the ExtensionInstallBlocklist and ExtensionInstallAllowlist policies
• Turn on extension reporting in your browser management console
• Set up alerts for new extension installations across the organization
• Automate removal of prohibited extensions
• Require admin approval for extensions that request broad permissions

Phase 4: Ongoing Monitoring (Continuous)

Extension risk changes over time. An approved extension today can be compromised tomorrow.

Actions:

• Check approved extensions for ownership changes at least quarterly, since no tool catches these perfectly
• Review permission changes in extension updates
• Subscribe to threat intelligence feeds that track extension compromises
• Review the approved extension list every quarter
• Run tabletop exercises that simulate a compromised extension

The Manifest V3 Mirage

Google's move from Manifest V2 to Manifest V3 for Chrome extensions was presented as a security improvement. It does make some attacks harder. Manifest V3 replaces persistent background pages with service workers, bans remotely hosted code, and moves toward a declarative model for modifying network requests.

Manifest V3 doesn't address the problems that enabled the 2024 campaign:

• Developer account compromise: Manifest V3 doesn't change how extensions are published or updated. A phished developer account can still push malicious updates.
• Ownership transfers: Manifest V3 doesn't notify users when an extension changes hands. The acquisition model is unaffected.
• Broad permission grants: Extensions can still request access to all sites. The model is incrementally better, not fundamentally different.
• Auto-updates: Extensions still update silently. Users still don't approve individual updates.

The code injected in the 2024 campaign stole data through ordinary content scripts and network calls. Manifest V3 still allows both.

Manifest V3 is a step forward. It is not the solution. Organizations that treat it as their extension security strategy will be disappointed.

The Browser as the New Endpoint

The browser has quietly become the most important endpoint in enterprise computing. Consider what runs inside it on a typical workday:

• Email (Gmail, Outlook on the web)
• Document creation and collaboration (Google Workspace, Microsoft 365)
• CRM access (Salesforce, HubSpot)
• Code repositories (GitHub, GitLab)
• Cloud infrastructure management (AWS Console, Azure Portal)
• Communication (Slack, Teams web clients)
• Financial systems (banking, expense management, invoicing)

For many knowledge workers, the browser is effectively the operating system. Yet the security model for browsers, and especially extensions, hasn't kept up.

Traditional endpoint security watches the operating system: EDR agents monitor processes, file access and network connections. A malicious extension runs inside the browser. It can read sensitive data without triggering typical EDR alerts. It can exfiltrate over ordinary HTTPS that looks like normal web traffic, and it can manipulate web sessions without touching the file system.

Attackers have found this gap, and they are using it.

What Comes Next

The Chrome extension supply chain problem is not a one-time event. The economics favor attackers. One compromised extension can reach hundreds of thousands of signed-in sessions. The cost of the attack, a phishing email or a modest purchase offer, is low compared to the payoff.

Google has taken steps, including stricter review for extensions that request broad permissions and the move to Manifest V3. Those measures treat symptoms. The root problem remains: browser extensions update silently and can have broad access to user data.

For enterprises, browser extension governance is no longer optional. It belongs alongside endpoint, email and network security. The organizations that act now will be prepared. The rest may learn on their own Christmas Eve.