A Chrome extension can redirect searches through the browser default search provider without asking for access to your pages. Socket’s October 29 investigation identified 264 more search-hijacking extensions, bringing its total to 319 with roughly 13.4 million users across a decade. For people managing browsers, the immediate exposure is a search query passing through an extension operator’s server before reaching familiar results.
The extensions often masquerade as manual finders, PDF tools or safe-search utilities. Socket found that many are unlisted in Chrome Web Store search and are promoted through paid ads. An unlisted listing remains installable by someone with its link; a store search alone will miss it.
An override with no permissions
Chrome extensions can specify a default search provider in their manifest under chrome_settings_overrides and search_provider. Socket showed an example whose manifest supplies the search and suggestion URLs and whose only other files are icons. It has no content script, background worker or requested permissions. On installation, Chrome prompts the user about the search change, while the destination the queries take can be easy to miss. Socket put it plainly: “There is no utility in the extension outside of changing the default search provider.”
After installation, the browser sends searches to the provider URL chosen by the extension. In the cases Socket studied, that URL leads first to an operator-controlled proxy. The proxy receives the query, then redirects it toward Yahoo or Bing with syndication partner parameters such as Yahoo’s hspart= and hsimp=, or Bing’s PC= and PTAG=. The operator gets referral revenue and a point where it can observe queries. A permission-only extension review misses this route because the browser itself performs the search-provider override.
One query, four destinations
Socket repeated the same search six times through the proxy used by Predator Search, extension ID odkcfoohjiicbelloepgcomekdknchjh. It saw four destinations: Yahoo results with partner tags, a separate landing page, another results domain reached through an extra hop before Yahoo, and a Cloudflare error page. The extension stayed the same; the server chose a route for each request. Another set of repeated queries reached Google’s homepage while other searches still went to Bing.
Those observations show server-side routing and query exposure. Socket observed changing destinations and describes phishing or malware lures as possible future uses. Treat the proxy as a place where searches can be captured and rerouted now. Search terms typed into a work browser can include internal names, incident details or customer information; the proxy sees the terms before the user sees the results page.
Paid ads feed hidden listings
Socket traced promotions to paid placements and landing pages that present the extensions as handy search tools. The publisher can keep a Chrome Web Store listing unlisted from store search while an ad supplies the specific installation link. Across the full set, Socket grouped 200 extensions and roughly 5.68 million users under identified operators, and 119 extensions and roughly 7.76 million users under unknown operators. Those user estimates span years and publishers; they are a scoping signal for administrators, not a current managed-fleet inventory.
Some operators use separate landing domains and publisher identities for similar extensions. Socket reports that Intango LTD published about 111 extensions with roughly 2.2 million users across about 279 domains. Different landing domains and publisher identities call for checking search-provider URLs across managed profiles.
Find the proxy in managed Chrome
Start with installed extension IDs and the configured default search provider on managed browsers. Include extensions with no requested permissions and compare the search URL behind plausible PDF, manual and search tools with your approved provider. Use Socket’s Predator Search ID as one specific inventory pivot, then review other search-provider-changing extensions by behavior rather than treating that ID as a complete list.
Google’s Windows managed-Chrome policy guidance describes ExtensionSettings for controlling installation by extension ID, including an installation_mode of blocked; it applies to Windows users signed in to a managed Chrome account. Block an identified unwanted extension through that policy and remove it from affected browser profiles. Set the intended search provider again so the proxy URL is no longer the browser’s default.
Restore the intended search route
From a managed test profile, run an ordinary search and inspect the first request and redirect chain in browser network telemetry or an authorized web proxy. The expected path starts at the approved provider and reaches its results without an operator search proxy in between. Confirm the extension ID is absent after policy refresh and the browser’s effective default-search setting matches your approved value. On a managed ChromeOS device, Google says to check chrome://policy for an ExtensionSettings status of OK and its applied value. For Windows, check the deployed policy in your management console and test the effective search route. Repeat the route check where policy or profile configuration differs. This test checks the current route; review retained proxy or browser logs separately if you need to scope queries already sent.