152 Malicious Chrome Extensions Were Secretly Logging Your Data and Forging Google Search Traffic

Content Summary: Security researchers at Socket discovered 152 Chrome "live wallpaper" extensions operating as a coordinated fraud network. These extensions lied about collecting user data on the Chrome Web Store, secretly logged IP addresses and browsing behavior, and manufactured fake Google organic search traffic to inflate ad revenue. This article breaks down exactly what happened, how the deception worked at a technical level, who was behind it, and what you should do right now if you had any of these installed.

Detail	Summary
Extensions Caught	152 Chrome "live wallpaper" new-tab extensions
Publisher Accounts	38 separate Chrome Web Store accounts
Brand Backends	tabplugins[.]com, yowgames[.]com, chromewallpaper[.]com
Affected Users	~105,000 (likely higher Chrome rounds install numbers)
Data Collected	IP address, ISP, browser type, timestamps, click counts, device info
Data Shared With	Google AdSense, DoubleClick, unnamed third-party ad partners
Fraud Method	Forged Google organic search attribution via UTM tags and signed redirect tokens
Anti-Forensic Behavior	IndexedDB wipe on every service worker start
Discovered By	Socket Threat Research Team (June 2025)
Status	Network dismantled after disclosure

An Extension You Trusted Was Working Against You

Picture this. You install a wallpaper extension for Chrome because you want a nice anime or football-themed new tab page. It looks clean. It has decent ratings. The Chrome Web Store says right there under Privacy Practices: "This extension does not collect or use your data."

You believe it. Why wouldn't you?

What you did not know is that in the background, from the very first second it was installed, that extension was logging your IP address, your internet service provider, your browser configuration, what pages you had been on, how many times you clicked on things, and detailed information about your device and installed software. All of that was being quietly shipped off to ad networks and unnamed third parties.

And that was only the beginning.

This is the story of 152 Chrome browser extensions, 105,000 unsuspecting users, and one of the more technically crafty ad fraud operations researchers have seen inside the Chrome Web Store.

How Socket Found It

Socket's Threat Research Team, the same group that regularly digs into supply chain threats inside open-source software and browser extensions, noticed something familiar about a cluster of Chrome extensions in 2025. They all looked different on the surface. Different publisher names. Different wallpaper themes. Anime, cars, football, games.

But underneath, every extension in the family shared a single codebase and pointed back to three brand backends: tabplugins[.]com, yowgames[.]com, and chromewallpaper[.]com.

The operation spanned 38 separate Chrome Web Store publisher accounts and had accumulated approximately 105,000 installs from unsuspecting users. That 105,000 figure is almost certainly a floor, not a ceiling, because Chrome rounds its install counts into buckets.

The extensions were not hiding in some dark corner of the internet. They were on the Chrome Web Store, sitting in plain sight, with privacy disclosures that flatly stated no data was being collected.

The Privacy Lie That Made It All Possible

The first and most straightforward piece of the deception was a simple lie.

On the Chrome Web Store listing for every one of these 152 extensions, the Privacy Practices tab stated clearly that the extension does not collect or use user data, does not sell data, and does not transfer data for purposes unrelated to the extension's core function.

That is exactly what users saw when they decided to install.

The linked privacy policy told a completely different story. The operator's own privacy policy directly contradicted this, admitting the extensions log IP addresses, ISP, click counts, and referrer data and sharing it with Google AdSense, DoubleClick, and unnamed third-party ad partners.

So there were three documents saying three different things. The store listing said no data. The privacy policy said data is collected and shared. And the actual network traffic confirmed the extensions were phoning home in real time.

This kind of three-way contradiction is not an accident or an oversight. It is the architecture of the deception. The store listing is what users and Google reviewers see. The privacy policy is buried one click deeper, written in language most users will never read. And the actual code does what it does regardless of what either document claims.

This is exactly the kind of threat that web application security testing and attack surface management practices are built to surface before users become victims.

How They Turned Extension Traffic Into Fake Google Search Visits

This is where the operation gets genuinely clever and genuinely damaging.

A subset of 54 extensions built on the tabplugins template did something more sophisticated than just collect data. They manufactured fake organic search traffic and fed it into Google Analytics and ad measurement platforms as if it were real.

Here is exactly how it worked.

On install: The moment you finished installing one of these extensions, the background service worker automatically opened a new browser tab to tabplugins.com. That tab URL included the parameters utm_source=google&utm_medium=organic.

In the world of web analytics, those two parameters tell the tracking platform that a visitor arrived through a natural Google search result. They did not click a paid ad. They found the site organically.

In reality, the extension opened the tab itself. But every analytics platform receiving that UTM data recorded it as a genuine Google organic visit.

On uninstall: This is where it got technically sophisticated. When you removed the extension, it fired one final network request using Chrome's setUninstallURL function. That request was not to tabplugins.com directly. It used a google.com/url wrapper that reproduced Google's signed VED and USG redirect tokens, making the outbound ping appear to analytics as a human clicking a legitimate Google search result.

To any analytics system observing that traffic, including Google's own attribution tools, that uninstall ping was indistinguishable from a real person who had just found the site by searching on Google and clicking a search result.

What this does to the advertising ecosystem is significant. This mechanism launders purely software-generated traffic into what appears to be earned organic demand exactly the signal that advertisers, ad networks, and affiliate programs pay premium rates for.

Organic search traffic is valued higher than paid traffic. It signals real interest, real discovery, real intent. When advertisers and affiliate programs see a site driving strong organic search numbers, they pay more for placements, they extend partnership terms, and they treat the traffic as credible.

All of that trust, and all of that money, was being built on visits that a browser extension silently generated in the background.

At 105,000 installs, even if only a fraction of users triggered these events, the volume of falsified attribution adds up fast. And because the data fed into Google's own analytics infrastructure, it was not just the operator's numbers that were polluted. It contaminated the measurement data that advertisers and ad networks use to make real spending decisions.

The tabplugins cluster served a live Prebid header-bidding stack via avads[.]live, wired to Google Ad Manager, AppNexus/Xandr, PixFuture, and SmileWanted, including full-screen interstitial slots. This is not a side operation. It is a real monetization pipeline generating real revenue from fabricated traffic signals.

Understanding and defending against this kind of threat requires ongoing cyber threat intelligence and vulnerability management practices that track how extensions behave after installation, not just at the point of review.

The Anti-Forensic Routine That Reveals Something Darker

Every single extension in this family of 152 shipped with an identical routine buried in the background service worker. Every time the service worker started up, it called indexedDB.databases() and then ran a loop that deleted every IndexedDB database it could find within scope.

For anyone not familiar with browser forensics: IndexedDB is a client-side storage mechanism that browsers use to hold persistent data. It is the kind of storage that a security researcher or browser audit tool might examine when trying to understand what an extension has been doing.

In current builds, the extension stores its own state in localStorage rather than IndexedDB, so the wipe destroys nothing. However, its family-wide presence shipped verbatim to all 141 analyzed members makes it the most reliable fingerprint of the operation. It represents an undisclosed, indiscriminate state-reset capability with no legitimate purpose in a wallpaper application.

That last point is worth sitting with. A live wallpaper extension has absolutely no reason to wipe IndexedDB databases on startup. None. There is no user feature this serves. There is no performance benefit. There is no legitimate technical explanation.

The only reason to include this code is to erase evidence. The fact that it currently erases nothing is not reassuring; it means the routine was written in preparation for a version where it would erase something meaningful. The infrastructure is already there, already deployed across all 152 extensions, waiting to be used when the operator decides to start storing data in IndexedDB instead of localStorage.

This is the kind of behavior that digital forensic investigation and incident response teams look for as a signal of premeditated, evolving threat operations rather than opportunistic fraud.

The Network Was Built to Survive Takedowns

One of the more professionally designed aspects of this campaign was its resilience to removal.

The operation spread one identical PUP template across 38 distinct Chrome Web Store publisher accounts — a deliberate takedown-resistance tactic, since removing any single account leaves the rest of the network intact. The two infrastructure clusters resolve to separate Cloudflare accounts and hosting providers, suggesting at least two coordinated teams running the same template and monetization scheme.

This is not the work of a single developer who made poor choices. This is an operation with infrastructure planning. When one publisher account gets flagged and removed, the other 37 accounts keep running. The extensions under those accounts stay live. Users who had already installed them continue to be tracked.

The use of two separate infrastructure clusters also provides redundancy. If one hosting environment gets blocked or blacklisted, the second continues operating independently.

This distributed structure is what makes campaigns like this so hard to fully shut down and why online threat exposure monitoring and takedown and disruption services are increasingly important for brands whose traffic data and analytics are being polluted by operations like this.

What the Indicators of Compromise Tell Security Teams

Socket's analysis produced a clean set of indicators that security and operations teams can use to detect this campaign across their environments.

IOC Type	Value	Significance
Domain	tabplugins[.]com	Primary brand backend; source of forged Google attribution
Domain	yowgames[.]com	Second brand backend; undisclosed telemetry routing
Domain	chromewallpaper[.]com	Third brand; HTTP 301 redirect to owhit[.]com
Domain	owhit[.]com	Final destination; AdSense-monetized landing page
IP Address	147[.]79[.]120[.]202	tabplugins[.]com origin server on Hostinger
IP Address	92[.]112[.]198[.]22	Secondary tabplugins[.]com server on Hostinger
URL Pattern	utm_source=google&utm_medium=organic	Forged organic attribution in install ping
URL Pattern	google.com/url?...ved=...usg=... pointing to tabplugins.com	Cloaked uninstall redirect mimicking real search click
Code Pattern	indexedDB.databases() loop with deleteDatabase()	Anti-forensic state wipe on every service worker start
Code Pattern	setUninstallURL with google.com/url wrapper	Forged uninstall attribution ping

Security operations teams should look for the IndexedDB enumerate-and-delete loop and the setUninstallURL functions pointing at Google URL wrappers as behavioral fingerprints of this campaign. Relying on extension IDs alone is not reliable because the operator can rotate them quickly across new publisher accounts.

This is exactly where extended detection and response (XDR) capabilities help catch the behavioral pattern rather than just the identifier.

Why Chrome's Review Process Did Not Catch This

This question matters more than it might seem at first, because 152 extensions across 38 accounts is not a small slip through the cracks. That is a sustained operation.

Research in 2025 demonstrated that malicious extensions can still be developed, published, and executed within the Chrome Web Store, highlighting persisting weaknesses in the browser's vetting process and security framework.

The fundamental problem is structural. Chrome's review process focuses heavily on what an extension declares it does, not on a continuous audit of what it actually does over time. An extension can pass initial review because its declared permissions look reasonable and its store listing says all the right things. But once it is live and installed on 100,000 browsers, the background behavior that happens at runtime is far harder to catch at scale.

The privacy disclosure mismatch between the store listing and the linked privacy policy is exactly the kind of thing that a more rigorous review process would catch immediately. But that comparison requires reading both documents, noticing the contradiction, and flagging it as a non-trivial task given the volume of extensions Chrome reviews.

The broader pattern here where extensions use popular themes to drive installs, spread across multiple publisher accounts to resist removal, and build their real behavior on undisclosed telemetry is becoming a repeating template. This campaign followed it precisely.

Organizations that rely on security compliance frameworks and regular gap assessments as part of their browser and endpoint policies are better positioned to catch this before extensions reach thousands of users.

What You Should Do Right Now

If you use Chrome and you have installed any wallpaper or new-tab extension in the past year, here are concrete steps to take today.

Check your installed extensions. Open Chrome and go to chrome://extensions. Look at everything you have installed. If you see any extension you don't regularly use or that you don't remember installing, remove it.

Cross-reference the brand domains. If any extension you have installed was published by an account associated with tabplugins.com, yowgames.com, or chromewallpaper.com (which redirects to owhit.com), remove it immediately.

Verify your default search engine. Go to Chrome Settings and check that your default search engine has not been changed. Some extensions in campaigns like this quietly adjust browser settings.

Check your Google Analytics or tag data if you run a website. If your analytics show unexplained spikes in organic traffic that do not correspond to actual search visibility improvements, that could be a sign that bot or extension-generated traffic is polluting your attribution.

Read privacy policies before installing extensions. Not the Chrome Web Store disclosure tab, but the actual linked privacy policy. If they contradict each other, that is a serious red flag.

Prefer extensions from developers with a verifiable public track record. A publisher with five extensions, no website, and no public presence is harder to hold accountable than one with a named organization behind it.

Organizations managing fleets of devices should consider endpoint security protection policies that control which extensions can be installed and mobile security and threat defense capabilities that extend visibility beyond the desktop browser.

Ad fraud is getting more sophisticated

This campaign represents a specific evolution in ad fraud. Previous adware extensions were relatively blunt; they injected ads directly into pages, changed your homepage, or hijacked search results. Users noticed. Browsers caught them.

This operation is subtler. It does not touch your browsing experience in any way you would notice. No injected ads. No redirected searches. No obvious changes to how Chrome feels. Everything looks normal.

What it does instead is manipulate the data layer, the analytics, the attribution, and the traffic signals that the advertising industry uses to make decisions about where to spend money. By forging organic search signals, it inflates the apparent value of the operator's properties to advertisers and affiliate networks. Those parties pay more for placements they believe are reaching people who found the site naturally.

This is the same underlying logic as click fraud, but applied upstream at the attribution level rather than the click level. And because it exploits the trusted format of Google's own URL redirect structure, it is much harder for ad platforms to detect than a simple bot click.

For brands, advertisers, and anyone relying on analytics to make business decisions, this kind of pollution is a genuine threat. Brand intelligence monitoring and cyber resilience assessments that include analytics integrity as a component are worth considering, especially for organizations with affiliate programs or performance-based advertising budgets.

Teams looking to proactively test their exposure to this class of threat through AI-driven automated red teaming or structured penetration testing will find that browser extension behavior is an increasingly important surface to include in scope.

Official References

Research credit: Socket Threat Research Team

Malicious Chrome Extensions Caught Faking Google Search Traffic